Things we need to decide

[Phil Edwards <pedwards at disaster dot jaj dot com>]

There are a few issues that I wanted to get people to start thinking on;
the 3.1 deadline is approaching.  Maybe mull these over a pint in front
of a cozy fireplace, etc.  I just wished to start y'all's subconscious
working on these.

Please change the Subject line if you decide to followup to this message,
for everybody's sanity's sake.  Thanks in advance.

--------------------------------------------------------------------
1)  While running through the pieces that we inherited from SGI, I saw
some things commented as "kludges to work around compilers lacking a
certain feature".  They aren't conditionally compiled or ignored; those
fragments were removed a long time ago.  These are always in place but
might not be used.  Or maybe they are.

Having them in place doesn't hurt in the sense of generating wrong code
(I /think/), but does make reading the code a wee bit more complex.

GCC seems to have all the features those pieces need.  How badly do we
want to remove these kludges?


--------------------------------------------------------------------
2)  GNU extensions to the library (more on this in #3).  Do we enable
them by default?  De we use --enable/--disable at configuration time?
Are they surrounded by #if/#endif markers?

Do we want to allow the user to toggle individual extensions?

    #define A_CERTAIN_EXTENSION      (1L<<1)
    #define A_DIFFERENT_EXTENSION    (1L<<2)
    ....

    #if THE_EXTENSIONS_IN_USE & A_CERTAIN_EXTENSION
    namespace std {
        using __gnu_cxx::extra_goodies;
    }
    #endif

or something like that.  Or is it all or nothing?  I have no opinion, but
there should be /some/ way for a user to request "no extensions at all".
(We may choose to turn off the SGI extensions as well in such a toggle.)


--------------------------------------------------------------------
3)  The file descriptor thing.  We need to do this for 3.1, and it takes
two shapes:

3a)  Exposing the guts of an existing file stream / file buffer.  Offhand I
can see a grid of two choices leading to four possibilities:

- How much guts to expose?  We speak to an underlying FILE* right now,
  both for 3.0 and on the trunk; current normal operations never involve
  a file descriptor directly.  Our choices are returning the FILE*, or
  assume Unix semantics and call fileno() on the FILE*.

- Which layer gets extended?  The filebuf, the fstream, or both?

For the first, I vote exposing the FILE* and not making any further
assumptions.  For the second, I vote the filebuf.

We might also consider what the behavior should be after exposing the guts:
continue to go along and hope the user doesn't do something stupid now
that encapsulation has been weakened/violated, or change the state such
that we no longer do anything at all, or...?

3b)  Taking a file descriptor to use in a new filebuf / fstream.  This
doesn't appeal to me as much as exposing information does.  Speaking only for
myself, I feel such things should be done in a derived class.  Perhaps we
can use one of the fd-wrapping buffers and streams from Nico Josuttis,
and place it in __gnu_cxx, just to name one possibility that Gaby mentioned.

All of this will be affected by #2, of course.



Please change the Subject line if you decide to followup to this message,
for everybody's sanity's sake.  Thanks in advance.

Phil

-- 
"You have to wonder what kind of life you have when your list of personal
rules begins with, '#3:  No drowning in your own mucus,' and '#4:  Don't
ask what happened to rules 1 and 2.'"