Mail Archives: djgpp-workers/2001/11/23/03:43:39
> > From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> > Date: Fri, 23 Nov 2001 01:18:28 +0100
> >
> > If using -ansi breaks, say,
> > valarray (which is ANSI C++ IIRC) because one of the
> template functions
> > uses a non-ANSI function, that is a problem.
>
> Is this really the case?
Yes. A quick shows that bits/stl_algo.h has
// Return a random number in the range [0, __n). This function
encapsulates
// whether we're using rand (part of the standard C library) or lrand48
// (not standard, but a much better choice whenever it's available).
template <class _Distance>
inline _Distance __random_number(_Distance __n) {
#ifdef _GLIBCPP_HAVE_DRAND48
return lrand48() % __n;
#else
return rand() % __n;
#endif
}
> How can ANSI C++ do that without polluting the namespace?
It can't. They made the mistake to think that 'detect once, use always'
is valid in C++. Either this should be changed to check both
_GLIBCPP_HAVE_DRAND48 and !__STRICT_ANSI__, or we need to conditionally
add a define for _STL_NO_DRAND48 to bits/stl_config.h.
> Anyway, if that's the problem, we should solve it like we do with all
> non-ANSI functions that are required by ANSI functions: rename the
> real function to have two leading underscores, and make a stub for the
> old name. Then #define the old name somewhere (in _G_config.h?) so
> that C++ headers are happy.
Not sure if that is wise - as far as we're concerned, libstdc++-v3 is a
user-space thing, so I think we should fix libstdc++-v3 instead of
providing workarounds for it. Besides, it's only fair that if the user
asks for -ansi, she actually gets only ANSI functions where possible.
Since in this case at least the library can handle both cases, I think
we should let it.
Now if libstdc++-v3 also uses some non-ANSI function without an
alternative, THEN I'd consider adding a stub for that.
- Raw text -