[v3] default to --disable-long-long, ctype fixes

[Levente Farkas]

Benjamin Kosnik wrote:
> 
> > Please reconsider this.  Would it be possible to put something in one of
> > the libstdc++ headers like this:
> >
> > #ifdef _STDLIB_H
> > #ifndef _GNU_SOURCE
> > #error "Must add -D_GNU_SOURCE, or suitable system-dependent macro, to
> > compile this program."
> > #endif
> > #endif
> 
> No. First of all, this is linux-centric, and all linux bits have to go in
> os_defines.h.
> 
> Second of all, long long is not part of the standard. Sorry.

hash_map either:-)

> > Turning off --enable-long-long is a really serious hardship for those
> > who need it on.  It means we have to recompile libstdc++-v3, right?  Or
> > since the compiler's now merged in, we would have to recompile both,
> > right?  I would seriously prefer to use the binaries as shipped with the
> > distribution(s), rather than having to recompile all this.
> 
> Keeping it on by default is a serious hardship for those who don't care
> or want a standards compliant library without gobbly gook. See the
> original post.
> 
> People who want it on can still use it, they just have to configure for
> it and plan on using it. I don't see evidence that this is a real hardship.
> 
> > After all, long long will be required eventually.
> 
> At that point, we'll reconsider. See the "at this point" part of the
> original announcement.

the problem with --disable is that most (and most means almost every)
user (and eg linux distro) of the stdc++ use it as compiled it with the
default settings. IMHO gcc 3.0 will be the standard gcc (after it'll
release) for many years and if it contains a stdc++ which doesn't contain
long long support than it's better if you don't use this feature for
years since it won't supported on many system. but if you turn in on,
than it may be broken on a few system, but you can compile at least
your code (if you read the docs, eg, define _GNU_SOURCE..) WITHOUT
recompile stdc++ which a system library (in my point of view).

it's a same question like "do we use the libio or stdio?" libio is
broken with dlopen from java, tcl.., but has many nice feature while
stdio working from java. I'd vote to be the libio the default (even
I'd need the loadlibrary from java) since it's possible to fixed
libio in the long run.

this just my subjective 2c:-)

 -- Levente                        http://petition.eurolinux.org/index_html
 "The only thing worse than not knowing the truth is
  ruining the bliss of ignorance."