Re: The patch for PR libstdc++/14097.

["Richard B. Kreckel" <kreckel at ginac dot de>]

Hi Gaby!

On 11 Feb 2004, Gabriel Dos Reis wrote:
[...]
> The point is not ignoring Unix programming.  The whole point is
> whether you have to make an extension under the gun, and if so what
> latitude do you have to change things later when I get a better idea
> than when you were undr the gun.

I have to *strongly* disagree.  There used to be an .fd() on basic_ios<>
or something like that in GCC 2.95 (I don't remember exactly).  That
solved a problem.  There wasn't anything in GCC 3.0.x.  That was a
problem.  Then, at GCC 3.1.0, came the .fd() on the buffer, which makes
some sense.  That solved the problem again.

Now, guess what: All my code using this stuff (a very tiney percentage) is
enclosed in big
#if defined(__GNUC__) && (__GNUC_MINOR__ > 1 )...
blocks, or similar ones anyways.  Now, it turns out that this is even
portable to some degree, as ugly as sin as it is!  Because most commercial
compilers on other flavors of Unix provide something equivalent.  Where it
is non-portable are the compiler versions where *nothing* is provided.

This makes it apparent that there still is enough latitude to change
things later when somebody comes up with a better idea than when we were
under the gun.

I am totally aware of the fact that my patch is ugly.  Very ugly, indeed.
I am not proud of it.  I have done better things.  Don't put my name in
the Changelog, please...  :)  But including some support *now* and maybe
changing it at any time later is still better than providing nothing at
all!

> I can't argue with arguments saying that Unix programming has been
> around for long time. However, I disagree with the line of reasoning
> building on that and saying the C++ style ought to use the same
> abstractions as C.  I know what the problems are, but I also believe
> that if you've been using the C abstractions for a while, then you can
> just continue to use them without requiri ng mucking around with the C
> abstractions

Sorry, I am not exactly sure how to parse that.

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel@GiNaC.DE>
<http://www.ginac.de/~kreckel/>