John Plocher wrote:
> Garrett D'Amore wrote:
>> Will the implementation take care to preserve the *existing* functions 
>> so that the above inline (which will now have been compiled into various 
>> applications) will continue to function, regardless of what other 
>> changes may be necessary for the class?
> 
> The materials Stefan has submitted state that the Apache C++StdLib project
> has made the commitment to not muck up these types of implementation details
> in any but one of their major releases.

For the record, we're not going to muck with anything.

Also for the record, we have no plans of tracking every single micro release of 
stdcxx 4. Upgrading to micro releases is TBD, based on what the new rev 
actually 
introduces. The development cycle of stdcxx often uses micro releases to 
address 
bugs specific to a particular compiler/architecture combo. This isn't always 
relevant to Sun Studio/Solaris. If it isn't relevant, why fix it when it ain't 
broken ?

> That is, even though the incompatibly evolving C++ language definitions and
> associated rickety scaffolding may allow one to shoot themselves in the foot,
> and their code could be evolved in ways that would expose such runtime
> binary incompatibilities, they explicitly promise not to do so within a
> certain set of release naming boundaries.
> 
> What more can the ARC ask?  This is exactly what we do with goode olde libc.
> The only difference is that the C++ world allows for (and oddly, seems rather
> comfortable with) incompatible future versions.
> 
> At that point, the Apache Standard C++ Library would need to rev its HNAME
> and .so versioning info, but again, this is exactly what we did with libc.
> 
> My only disconnect here was our left and right hands not talking to each 
> other,
> and now that Stefan and Steve are exchanging email, I'm not even very worried
> about that - though I'm sure someone will let me know if/when I should start
> worrying again :-)

Steve Clamage and myself had reached an agreement on this, a couple of days ago:

1. We [ SFW/KDE ] were going to introduce this library in Nevada/OpenSolaris -- 
it's the easiest integration, and it's the one we care most about, because it 
can be done *now*.
2. They [ DevPro/Tools ] were going to introduce this library with the 
compiler(s), for Solaris 9/10, at some point in the future. I cannot say when 
that will be.

Is this agreement still valid ? Or has it been filibustered ?

--Stefan

-- 
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM


Reply via email to