This is the mail archive of the libstdc++@sources.redhat.com 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: [v3] default to --disable-long-long, ctype fixes


Gabriel Dos Reis wrote:
> 
> george@moberg.com writes:
> 
> [...]
> 
> | I realize that, to quote Gabriel Dos Reis, "The World is not GNU
> | Based.", but isn't this library a part of the GNU Compiler Collection?
> 
> Certainly.  But GCC doesn't come with its own <stdlib.h>.  So what?
> Any kind of hacks which assumes that system headers come from GNU
> sources is fundamentally broken and unacceptable.

OK...my hack was bad.  I retract it.  ;^)




> [...]
> 
> | (Mr. Dos Reis, does this clarify?)
> 
> It does; but largely ignored the concerns I exposed in my previous
> message.

The major concern that I gathered from your message is that you do not
approve of a resource tradeoff where --enable-long-long would get in the
way of standard features.  I'm wondering _how_much_ of a tradeoff there
really is, or is everyone getting jumpy because the release is near?

After all, I don't want to delay the library for 8 months, or cripple
it, to get --enable-long-long in there.  However, I wouldn't complain
about a delay of 3 days or a week.




> | I'm not worried about introducing binary incompatibility with the
> | current CVS.  I'm worried about the inevitable binary incompatibility
> | between programs and libraries compiled with --disable-long-long and
> | --enable-long-long versions of libstdc++-v3.
> 
> If I understand you correctly, just because the compiler happens to
> have thousands of options, the library should be built by default by
> all possible compbinaison of those options.

No.  This is not what I'm saying.  What I'm saying is that libstdc++-v3
has to look forward to the real world.  People are regularly using files
larger than 2GB, and processors with direct 64-bit integer support are
on the cusp of being quite popular  (I'm thinking of the 64-bit Sparcs
and the 64-bit Intel chips).

Also, the most common underlying C library that GCC runs on (glibc)
supports 64-bits now, with the proper #define. (_ISOC99_SOURCE)

What's the lifespan of GCC 3.0 w.r.t. a future release that has
--enable-long-long as the default?  How long would users have to wait? 
How many troubles with binary incompatibility do you really want to make
for yourself?  I thought that the ABI for C++ was supposed to be
solidified with the release of GCC 3.0.  If you don't nail down this
feature right now, then you will not have achieved the desired ABI
stability that you're going for, because the next release of the
compiler will break binary compatibility when you rev the library to
support --enable-long-long.




> It is unreasonable that people who happen to build their programs
> against non-standard features built in their owns libraries require
> the standard library to sweep after them.

64-bit integers are not such an esoteric feature that we should need to
hide behind the facade of pedantic standards compliance.  They are a
basic data type.  I'm not asking for a bizarre compatibility hack here. 
I'm asking that the library support a basic data type--a basic data type
that is necessary to properly utilize hardware and operating systems
that are common _now_.

--enable-long-long is the "right thing" to do, especially if it's as
simple a thing as having the compiler define _ISOC99_SOURCE when
compiling C++ source files.





> | Considering that I bitched about a more trivial issue (hash_map with C++
> | string class as a key), I hope you don't dismiss my response to this
> | issue out of hand.
> 
> I'm not dismissing your response.  As I said in my earlier message, we
> have finite resource and deadline.  The standard library needs to be
> implemented in order to be shipped with GCC-3.0.  I find it quite
> unreasonable to spend the limited resource on non-standard features
> whereas more pressing standard features are waiting to be sorted out.

I understand that.  However I disagree with your ranking of the
importance of 64-bit integers as an implementation target.  How much
time have you spent so far to add 64-bit support to this library?  3
man-months, 4 man-months, something like that?  Your going to trash that
effort because it requires another week?

Please reconsider.  As a user of this library, I can tell you at least
one person (;^) will use the feature _immediately_ upon release.
--
George T. Talbot
<george at moberg dot com>

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