[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