octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[patch] typename tweaks


From: John W. Eaton
Subject: [patch] typename tweaks
Date: Sat, 17 Aug 2002 20:22:38 -0500

On  5-Jun-2002, Mumit Khan <address@hidden> wrote:

| Get rid of those annoying ``implicit typename'' warnings. All these years
| of C++, and I still can't get these right. Argh. GCC-3.1 seems to think
| that some of the typenames in Array.h can be omitted, but I don't believe
| that's correct (sorry, can't quote chapter and verse right now).
| 
| Checked against gcc-3.1, someone should definitely check against 2.95.x
| to make sure these changes are ok.
| 
| liboctave/ChangeLog:
| 
| 2002-06-05  Mumit Khan  <address@hidden>
| 
|       * Array-idx.h, Array.cc, Array.h, Array2-idx.h, Array2.cc, Array3.cc,
|       ArrayN.cc, DiagArray2.cc: Add typename where appropriate.

Thanks.

I made these changes today.  Unfortunately, because I haven't been
very good at keeping up with bug reports, I had to rediscover this all
on my own when someone reported some new warnings with gcc 3.2.

Then when I did a quick search for "new typename" to see if that would
be valid syntax, I found your message.  This was just before I was
going to send you mail and ask for your advice.  And so it happens
that you had already answered the question that I was about to ask.
:-)

BTW, it looks like g++ 3.2 also causes code like

  std::ostrstream buf;
  buf << "put some stuff in buf" << std::ends;
  char *s = buf.str ();
  do_something_with (s);
  delete [] s;

to fail.  It's the delete that causes trouble.  Apparently this was
never guaranteed to work, even though I never saw anything but this
idiom a few years ago.  Now you are supposed to write

  buf.freeze (false);

to tell the ostrstream that it is once again responsible for freeing
the memory.  I don't remember ever seeing this method recommended in
any C++ book, but then I may have missed a few pages.

Anyway, I've added a check for <sstream> in configure.in and also the
new header file liboctave/lo-sstream.h:

  #if !defined (octave_liboctave_sstream_h)
  #define octave_liboctave_sstream_h 1

  #ifdef HAVE_SSTREAM

  #include <sstream>

  #define STRINGSTREAMBUF std::stringbuf

  #define ISSTREAM std::istringstream

  #define OSSTREAM std::ostringstream
  #define OSSTREAM_STR(os) (os).str ()
  #define OSSTREAM_C_STR(os) (os).str () . c_str ()
  #define OSSTREAM_ENDS ""
  #define OSSTREAM_FREEZE(os) do { } while (0)

  #else

  #include <strstream>

  #define STRINGSTREAMBUF std::strstreambuf

  #define ISSTREAM std::istrstream

  #define OSSTREAM std::ostrstream
  #define OSSTREAM_STR(os) std::string ((os).str ())
  #define OSSTREAM_C_STR(os) (os).str ()
  #define OSSTREAM_ENDS std::ends
  #define OSSTREAM_FREEZE(os) do { (os).freeze (false); } while (0)

  #endif

  #endif

With this, I've also changed the code to use the lo-sstream.h header
instead of <strstream> and to use the macros instead of manipulating
strstreams or stringstreams directly.  It seems to work.

Note that istrstreams and strstreambufs are not used much, so I think
what is shown above is sufficient for Octave.  There is one additional
#ifdef HAVE_SSTREAM conditional in the source.

Someday, we can delete all of this.  But since gcc 2.95 (without
sstream) is still commonly used, I don't think we should do it quite
yet.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]