Mail Archives: djgpp-workers/2001/02/13/07:03:44
Eli Zaretskii wrote:
> On Mon, 12 Feb 2001, Stephen Silver wrote:
>
> > The c_std option doesn't put the standard functions (or anything else)
> > in namespace std if the user includes <*.h> instead of <c*>. It was
> > this sort of incorrect behaviour that I was trying to avoid.
>
> Can we have the cake and eat it, too? That is, can we leave the <c*>
> headers up to libstdc++ (after all, they are theirs to begin with) and
> fix only the <*.h> headers which come with DJGPP?
The "c_std" option is incompatible with any .h fix I can think of.
If we want the .h headers to work correctly, we either have to use
the "c" option and fix the .h headers as I have been doing, or we
have to use the "c_shadow" option and fix the .h headers so that
they treat non-standard functions sensibly. The latter option gives
the best standard compliance, but is also more problematic.
> Is that what your latest suggestion based on looking into libstdc++
> was trying to do?
No, not really. That suggestion was designed to allow the two
above-mentioned choices to co-exist to some extent. That is, the
.h headers would work with either the "c" or the "c_shadow" options
(although without necessarily attempting to fix the problems that
"c_shadow" introduces).
> > If the ultimate aim is to use the c_shadow headers, then there is
> > not much point is using my namespace std patches
>
> Please explain why. Are these two goals somehow incompatible, even
> if we leave the <c*> headers alone?
They require putting different sets of 'using' declarations at the end
of the DJGPP headers. They are not actually incompatible, because the
choice can be made according to whether _IN_C_LEGACY_ is defined or not.
But having two sets of 'using' declarations at the end of each header
seems like a lot of clutter if one of these sets is not going to be
used in the long run.
Stephen
- Raw text -