[RFC] exports and linkage for TR1
Paolo Carlini
pcarlini@suse.de
Wed Oct 11 23:13:00 GMT 2006
Benjamin Kosnik wrote:
>> In my opinion the issue isn't particularly urgent. In this sense: as you
>> remind elsewhere, we could as well wait a bit more (probably the erase
>> overloads will change in C++0x) and then add exports for the
>> corresponding, more stable C++0x bits in namespace *std* instead of
>> mixing now tr1 and std facilities.
>>
> Realistically, I think this is at least a year away, most probably two.
>
I think your estimates are too pessimistic. I mean, the new containers
in C++0x are already rather stable, AFAIK: there are those issues with
the erase overloads (which definitely would not be exported) not much
more. Elsewhere, AFAICS there are isn't much code candidate for exporting.
On the other hand, at this stage it's up to us (v3) start taking things
from tr1, adjust bits here and there and add to std. That seem more
meaningful than adding exports for tr1 stuff - more generally tr1
infrastructural work - when *by definition* tr1 is non normative and
experimental, only a step toward C++0x.
In other terms, our users can definitely put to good use the tr1
facilities anyway, and we *want* that, for example in order to make sure
that our algorithms are good (e.g., I spent quite a bit of time on the
random algorithms, knowing that some of the user interfaces will change
in C++0x, because, well, a Poisson generator it's a Poisson generator!),
but I think we should emphasize in our policies and conduct that tr1
it's just a step toward a new standard, not something which we imagine
and hope will be much used a few years from now.
Paolo.
More information about the Libstdc++
mailing list