[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
- [patch] typename tweaks,
John W. Eaton <=