muttley hates software: gcc 3 and the iostream debacle

• From: Simon Wistow
  Date: 10:31 on 31 Aug 2005
  Subject: gcc 3 and the iostream debacle
  
  There may be plenty more of this coming so beware.
  
  I need to recompile a bunch of Maya 6.0 plugins for Maya 7.0. Maya 6.0 
  was compield with gcc3.3.2 and 7.0 was compiled with 3.3.4
  
  We irregulalrly have to compile against stuff for 2.9.6 as well and it 
  is never a starightforward recompile, esepcially when it comes to 
  iostream.
  
  Is it 
  
      #include <iostream>
  
  or
  
      #include <iostream.h>
  
  the iostream.h is supposed to be a backwards compatability shim but
  sometimes give deprecation warnings and sometimes does. Sometimes I have
  to compile with -DAW_IOSTREAM_NEW and sometimes _BACKWARD_IOSTREAM_H. I
  found a new one today which was -DREQUIRE_IOSTREAM. 
  
  Maybe I have to put
  
      using namespace std;
  
  But then again, maybe not. Sometimes i just have to prefix every cout
  and cerr with std::. Although not always.
  
  To solve a problem I've been getting with these kinds of errors
  
  /software/gcc/3.3.4/linux.fedora1.i386/include/c++/3.3.4/backward/iostream.h:34: 
  error: `
     iostream' is already declared in this scope
  /software/gcc/3.3.4/linux.fedora1.i386/include/c++/3.3.4/backward/iostream.h:34: 
  error: using
     declaration `iostream' introduced ambiguous type `iostream'
  
  
  I had to copy backward/iostream.h to ./ although shoving a 
  
  -I/software/gcc/3.3.4/linux.fedora1.i386/include/c++/3.3.4/backward/
  
  caused even more errors.
  
  Sure, there's probably something fundamentally broken with the Makefiles 
  but I'll *guarantee* that the brokeness is the result of a hack put in 
  there to work around the last incompatible change. 
  
  It's a fricking compiler FFS - take C code, spit out object code. Since
  this retarded family of languages makes me care about header files
  anyway why make everything else so fucking difficult. And what is it
  about the ADHD malcontents who produce 90% of software that means that
  given a relatively conceptually simple task (read mail, display a web
  page, compile a .c(pp) file) that they feel the need to strap on
  complications and gotchas like a vengeful dominatrix strapping on a
  veiny beknobbed dildo in order to punitively claim your manginity for
  crimes unspecified and unspeakable.
  
  I shall dig out a .sig from that last time I went through this flavour
  of rigaramole. Aaaah, there it is.
  
  Simon
  
  
  

• From: peter (Peter da Silva)
  Date: 14:17 on 31 Aug 2005
  Subject: Re: gcc 3 and the iostream debacle
  
  >     #include <iostream>
  >     #include <iostream.h>
  
  VAXC sometimes wanted things like
  
  	#include stdio
  
  No quotes, no brackets, no extension.
  
  This obviously made portable code a challenge. Particularly when
  TOPS-20 had a compiler that tokenized everything in the preprocessor
  so you couldn't ifdef it out.
  
  Oh, and "$" and "@" were legal characters in identifiers.
  
  I forget how I got around this. Maybe I didn't.
  
  Anyway, there's reasons I hate extensions to C. Let alone derived
  pseudo-object-oriented languages based on a design that had to work
  as a C preprocessor. I've modified C, adding new features, but only
  in play. Shipping code that implements or uses them is vile.
  
  C++ is dead to me.
  
  
  

• From: Geoff Richards
  Date: 18:49 on 31 Aug 2005
  Subject: Re: gcc 3 and the iostream debacle
  
  On Wed, Aug 31, 2005 at 08:17:41AM -0500, Peter da Silva wrote:
  > >     #include <iostream>
  > >     #include <iostream.h>
  > 
  > VAXC sometimes wanted things like
  > 
  > 	#include stdio
  > 
  > No quotes, no brackets, no extension.
  
  You can do this, at least in GCC 4.0.2:
  
      #define stdio <stdio.h>
      ...
  
      #include stdio
  
  Ugly.  The FreeType library uses this feature/hack to get the right
  include files included, which is the only reason I discovered that it
  was possible.  You do this sort of thing:
  
      #include <ft2build.h>
      #include FT_FREETYPE_H
      #include FT_GLYPH_H
      #include FT_OUTLINE_H
      #include FT_BBOX_H
  
  I don't think I ever found out why you'd want to do it that way, but
  there you are.
  
  > This obviously made portable code a challenge. Particularly when
  > TOPS-20 had a compiler that tokenized everything in the preprocessor
  > so you couldn't ifdef it out.
  > 
  > Oh, and "$" and "@" were legal characters in identifiers.
  > 
  > I forget how I got around this. Maybe I didn't.
  
  Nice.  So you could do tasteful things like this, at least if they
  were allowed at the start of an identifier:
  
      int sum (int *@numbers, int $size)
      {
          int $total = 0;
          int $i;
  
          for ($i = 0; $i < $size; ++$i) {
              $total += @numbers[$i];
          }
  
          return $total;
      }
  
  > Anyway, there's reasons I hate extensions to C. Let alone derived
  > pseudo-object-oriented languages based on a design that had to work
  > as a C preprocessor. I've modified C, adding new features, but only
  > in play. Shipping code that implements or uses them is vile.
  > 
  > C++ is dead to me.
  
  C++ was stillborn.
  
  
  

• From: peter (Peter da Silva)
  Date: 19:10 on 31 Aug 2005
  Subject: Re: gcc 3 and the iostream debacle
  
  >     #define stdio <stdio.h>
  >     ...
  > 
  >     #include stdio
  
  In DEC's case "#include stdio" meant pulling it out of an archive in
  some place like "SYS$INCLUDE:PRECOMPILED.LIB" (name pulled out of
  thin air).
  
  > Nice.  So you could do tasteful things like this, at least if they
  > were allowed at the start of an identifier:
  
  Well, it was so you could have structures and symbols like SYS$SYSTEM and
  IO%RPR.
  
  
  

Generated at 10:27 on 16 Apr 2008 by mariachi