Re: GCC include files conundrum.

David Gilbert <dgilbert_at_dclg.ca> writes:

> >>>>> "Daniel" == Daniel Lang <langd-freebsd-hackers_at_leo.org> writes:
> 
> Daniel> Hi, David Gilbert wrote on Sun, Mar 14, 2004 at 08:55:24PM
> Daniel> -0500: [..]
> >> I'll ignore the condescending tone for a momment.  It's worth
> >> noting that everything works by simply having a copy of strstream.h
> >> in the backward directory.  Maybe the right path to take here is to
> >> include that file much as we include old versions of shared
> >> libraries.
> 
> Daniel> I disagree. Valid standards should be enforced. Providing
> Daniel> compatibilty just keeps more and more non-compliant pieces of
> Daniel> code around. The earlier authors and maintainers are forced to
> Daniel> update their software to be standard-compliant the better.
> Daniel> Even if it's painful and apparently unnecessary work for the
> Daniel> moment. It is beneficial in the long run.
> 
> Daniel> This is just my general opinion on such things.
> 
> Well... there's a time and a place for this.  To be mainstream, we
> need to consider that compatibility is what attracts most people.
> In this case, it appears that someone was coding to an earlier
> standard

There never was an earlier C++ standard - only tradition, and
    pre-standard implementations which interpreted tradition
    differently. There was the C++ ARM, but every C++ compiler I ever
    used was nearly as different from the arm as the C++ ARM is from
    ISO C++1998. It's true that the 1998 standard did not try hard
    enough to minimize code breakage, but in my experience, porting
    large C++ projects to match the 1998 standard is easier than
    porting them to a different pre-standard compiler.

It's worth pointing out that gcc didn't provide <sstream> until 3.0
    . So the authors of tclmidi have had only about 2.5 years to fix
    their code, and not the 5 years it might otherwise appear. (The
    appropriate namespace directives/declarations/qualifiers such as
    'using namespace std', and 'std::istream' would have been accepted
    by gcc 295, though it did not require them.) 

As far as 'being compatible' goes, there is a gcc 2.95.3 port
    (/usr/ports/lang/gcc295), and if it is still being maintained, I
    would suggest any port which doesn't build with gcc 3.3.x be
    modified to be use and require that port, after emiting a warning
    of some kind, saying that gcc 2.95 won't be around forever, and
    the port will have to be fixed soon. I just checked, and on my
    5.2p2 box, gcc295 still builds. But surely someone already thought
    of this, and decided that making ports build with gcc 3.3.3 was
    better than making them use and require the gcc295 port, which,
    after all, will only become harder to maintain over time.

> ... not just hacking something together.  The _real_ problem
> here is incompatible langauge changes ... leading me to loose yet more
> faith in C++ as a whole.

Fortunately, the incompatible langauge changes have been over since
    1997 (when the 1998 standard was finalized). The ISO committee
    has learned a lesson from its failure to be less incompatible
    with existing implementations (it would have been impossible to be
    compatible with more than one implementation), and is now largely
    hostile to even tiny incompatibilities. The minor bugfixes that
    make up the 2003 standard are all backward compatible, and
    unlikely to break any program.

However - unfortunately, gcc, like most C++ compilers, is slow to
    catch up with the C++ standard (which is after all quite difficult to
    implement correctly, and arguably less important than C (since
    there are more C users of gcc than C++ users)), and there is one
    more incompatible difference between what the 1998 standard
    specifies, and what gcc 3.3.3 implements coming down the pike -
    two-phase lookup, which will be in 3.4 . Fortunately, it won't
    break much - it only affects programs which make unusual uses of
    templates, and the majority of such programs are only written by
    people aware of two-phase lookup and what it might break.