Date: 15 Mar 2004 11:02:18 -0700 From: llewelly@xmission.com To: David Gilbert <dgilbert@dclg.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: GCC include files conundrum. Message-ID: <s3rr7vuhtud.fsf@xmission.xmission.com> In-Reply-To: <16469.46609.293027.840180@canoe.dclg.ca> References: <16468.65270.123954.862565@canoe.dclg.ca> <20040315013817.GA68381@crodrigues.org> <16469.3340.625290.632134@canoe.dclg.ca> <20040315102516.GH15687@atrbg11.informatik.tu-muenchen.de> <16469.46609.293027.840180@canoe.dclg.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
David Gilbert <dgilbert@dclg.ca> writes:
> >>>>> "Daniel" == Daniel Lang <langd-freebsd-hackers@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s3rr7vuhtud.fsf>