Re: GCC include files conundrum.

On Sun, Mar 14, 2004 at 07:55:18PM -0500, David Gilbert wrote:
> I attempted to argue that audio/tclmidi wasn't broken... and the ports
> maintainer fired back with
> 
> http://bento.freebsd.org/errorlogs/i386-5-latest/tclmidi-3.1.log
> 
> Now... I started investigating this and found that this was all due to
> some differences in C++ over the years.
> 
> The error on bento comes down to bento not having strstream.h.  I have
> that file as:
> 
> /usr/include/c++/3.3/backward/strstream.h
> /usr/include/g++/backward/strstream.h
> 
> on my -CURRENT (as of a week or two ago) laptop.
> 
> bento does appear to have /usr/include/c++/3.3/backward/iostream.h
> ... but not strstream.h.  Why?

FreeBSD stopped installing `strstream.h' in January.  See rev 1.48 of
src/gnu/lib/libstdc++/Makefile.  The commit log indicates it was removed
in (some release of) GCC 3.3.  I wonder if this is correct though---
compiler messages seem to contradict this.

> I realize that my source upgrading may have left around a few old
> files, but I don't see a replacement strstream.h.
>
> The C++ FAQ referred to by iostream (not iostream.h) seems to imply
> that you should use iostream and sstream (no .h)... but including
> those files imposes a very different standard that this port is not
> ready to accept.  It appears that (among other things that I havn't
> found yet) all 'istream' must be written 'std::istream' ... etc.
> 
> So what's the solution?

`strstream.h' was never a standard C++ header, but rather a part of SGI
STL (I think) that is now obsolete.  `strstream' is defined in ISO/IEC
14822:1998 and 2003, but is deprecated.  (``This clause describes
features of the C++ Standard that are specified for compatibility
with existing implementations. These are deprecated features,
where deprecated is defined as: Normative for the current edition
of the Standard, but not guaranteed to be part of the Standard in
future revisions.'')

It looks to me like tclmidi uses only class ostrstream.  The easiest
solution to your problem would be to add a file named `strstream.h' with
the following contents:

  #include <strstream>
  using std::ostrstream;

The longer term solution is to kill the port, or to port it to Standard
C++.  Porting it to Standard C++ would probably entail rewriting uses of
<strstream.h> and `ostrstream' to <sstream> and `ostringstream'; and
rewriting uses of other C++ `.h' headers to the standard form without
.h;  and adding `using namespace std;' liberally.

Cheers,
-- 
Jacques Vidrine / nectar_at_celabo.org / jvidrine_at_verio.net / nectar_at_freebsd.org