This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Version number misery


On Thu, May 17, 2001 at 03:57:35AM +0200, Carlo Wood wrote:
>  -    basic_filebuf(int __fd, const char* /*__name*/, ios_base::openmode __mode)
>  +    basic_filebuf(__c_file_type* __f, ios_base::openmode __mode)
[...]
>  -    basic_filebuf(__c_file_type* __f, ios_base::openmode __mode)
>  +    basic_filebuf(__c_file_type* __f, bool __s, ios_base::openmode __mode)
[...]
>  -    basic_filebuf(__c_file_type* __f, bool __s, ios_base::openmode __mode)
>  +    basic_filebuf(__c_file_type* __f, ios_base::openmode __mode, int_type __s)
[...]
> How can I make sure that using any snapshot my application will
> use the correct signature?

That's the nonstandard extension ctor, remember, not a Standard one.
It'll change as often as it needs to change in order to get all the I/O
issues correct.  Depending on implementation details is a Bad Thing.
That's just life.  (And I keep forgetting to update the documentation on
the "extensions" web page.)

If there were a clean and easy way to specify that "this ctor can only be
called by other classes in the library itself," we'd've done it, to avoid
this exact problem.

I'll guess that whatever its form is when 3.0 is actually released, will
probably stay around for a while.  At least until 3.1.  It'll still be an
implementation detail, though.  (If you want to petition the ISO committee
to add another ctor, they're talking about C++0x in comp.std.c++ right now.
It's a very busy discussion.)


> Hopefully __GLIBCPP__ will *always* be a date?  Then I can use
> #if __GLIBCPP__ > 20010417   etc.

See c++config, where this is defined:

    // The current version of the C++ library in compressed ISO date format.
    #define __GLIBCPP__ 20010417


> PS #define _GLIBCPP_VERSION "2.91"
>    Doesn't look correct either.  I suppose this comes from
>    libstdc++-v3/acinclude.m4:
>    AM_INIT_AUTOMAKE(libstdc++, 2.91)
>    But then why was there a cvs tag libstdc++_2_92 added
>    a month(!) ago?

The AM_ function probably just got overlooked.  It (or rather, its effects)
don't get used anywhere in the build/install process, so it's easy to
forget about.  I for one forget it was there.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]