[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] typename tweaks
From: |
Mumit Khan |
Subject: |
Re: [patch] typename tweaks |
Date: |
Sun, 18 Aug 2002 12:12:44 -0500 (CDT) |
On Sat, 17 Aug 2002, John W. Eaton wrote:
> 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.
> :-)
I had forgotten all about it, thanks for getting to it.
> 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;
Odd. The .str() method implicitly implies .freeze(true), so that it's
the user's responsibility to free the character buffer, so I can't
see where the problem is. Then again, I haven't used ostrstream in
years, so have conveniently the subtle nuances.
> 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.
Isn't that double free'ing here? Let me take a look at the specs for
strstream and see if I understand what's going on.
> Anyway, I've added a check for <sstream> in configure.in and also the
> new header file liboctave/lo-sstream.h:
Excellent.
> 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.
Well, the other choice is to include a version of sstream (eg., the
one from Dietmar Kuehl) with Octave that switch on and off depending
on the runtime library.
Mumit