octave-maintainers
[Top][All Lists]
Advanced

[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




reply via email to

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