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]
Other format: [Raw text]

Re: [C++0x] nullptr


On 05/30/2010 02:37 PM, Alisdair Meredith wrote:
> Yes - this is definitely the more practical approach, and the one I
> have followed myself.
Good, good.
> The question is interesting as I am considering making a
> 'super-strict' library that really does give only  the minimum
> requirements of the standard and nothing more.  Not a particularly
> productive environment, but handy in test environments if you want to
> guarantee you code is 'portable' and conforming.  Of course, true
> portability is a measure of how well you accommodate differing
> platforms bugs as well, so a strictly conforming library is mainly an
> academic exercise ;~)
Interesting indeed. I'll have to think more about this too... and of
course when you will be ready to share some code... ;-)
> BTW, while running my test drivers over the GCC lib (always handy to
> verify my driver when I am confused ;~) I noticed the GCC basic_string
> does not yet provide front and back, unless I have to throw a special
> switch to get the C++0x version of the library?  I am passing
> -std=c++0x on the command line, but that is all.
Can certainly be, thanks for pointing it out. I'm probably going to add
those for 4.6.0. In general, we used to be quite careful with
basic_string, because the c++0x version will break the ABI and we have
to roll in something completely different anyway. But then, lately we
decided to add simple user-visible things to basic_string too, even if
that means exporting more symbols from the .so. And for sure I'm going
to add front and back to ext/vstring.

Thanks,
Paolo.


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