Jump to content
  • Advertisement
Sign in to follow this  
rozz666

std::strstream after main (or WinMain)

This topic is 3743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

is it OK to create std::strstream after main or WinMain? E.g:

class Foo {
public:
    ~Foo()
     {
         char tmp[20];
         std::strstream ss(tmp, 20);
         ss << "xxxxx";
          // do something with ss
     }
};

Foo foo;

int main()
{
}
I have a problem with Borland Turbo C++. Windows are destroyed after WinMain and CodeGuard reports accessing freed memory in basic_ios::widen in std::strstream's ctor which is called in window's dtor. Is this a sane behaviour or is it an error in Turbo C++? [Edited by - rozz666 on July 20, 2008 4:43:00 AM]

Share this post


Link to post
Share on other sites
Advertisement
strstreams are deprecated. In my experience using them years ago, I remember having numerous problems with memory leaks. I wound up writing a lot of extra code to work around these issues.

You're better off using stringstreams, instead. Include sstream instead of strstream.h and then use std::stringstream (or istringstream or ostringstream) instead of std::strstream.

Share this post


Link to post
Share on other sites
I use std::strstream to avoid memory allocations. With strstream I can write formatted string directly where I want it.

But it's not the problem stricly with std::strstream, but with locales. They are global and they probably get destroyed before windows.

Share this post


Link to post
Share on other sites
Quote:
Original post by rozz666
I use std::strstream to avoid memory allocations. With strstream I can write formatted string directly where I want it.

But it's not the problem stricly with std::strstream, but with locales. They are global and they probably get destroyed before windows.
They should be destroyed near the end of the static/global cleanup code, so it should be safe. Using a modern compiler that is; isn't Turbo C++ about 15 years old?

Share this post


Link to post
Share on other sites
Quote:
Original post by rozz666
I use std::strstream to avoid memory allocations. With strstream I can write formatted string directly where I want it.

But it's not the problem stricly with std::strstream, but with locales. They are global and they probably get destroyed before windows.


I'm just saying, use stringstream. Why would you want to use a deprecated part of the standard library?

Other than that, you're okay creating objects in destructors as long as you follow two things:

a) Be careful referencing globals.
b) Be aware of exceptions. Destructors should NEVER throw exceptions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by rozz666
I use std::strstream to avoid memory allocations. With strstream I can write formatted string directly where I want it.

But it's not the problem stricly with std::strstream, but with locales. They are global and they probably get destroyed before windows.
They should be destroyed near the end of the static/global cleanup code, so it should be safe. Using a modern compiler that is; isn't Turbo C++ about 15 years old?


No it isn't. http://www.turboexplorer.com/cpp

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Quote:
Original post by rozz666
I use std::strstream to avoid memory allocations. With strstream I can write formatted string directly where I want it.

But it's not the problem stricly with std::strstream, but with locales. They are global and they probably get destroyed before windows.


I'm just saying, use stringstream. Why would you want to use a deprecated part of the standard library?


Because it's still part of the library and it provides exactly what I need.

Quote:


Other than that, you're okay creating objects in destructors as long as you follow two things:

a) Be careful referencing globals.


That's probably the problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by rozz666
Because it's still part of the library and it provides exactly what I need.


Does stringstream not provide what you need? Your logic behind choosing strstream over stringstream doesn't make much sense to me.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Quote:
Original post by rozz666
Because it's still part of the library and it provides exactly what I need.


Does stringstream not provide what you need? Your logic behind choosing strstream over stringstream doesn't make much sense to me.


No, it doesn't. I can't specify an output buffer for stingstream. So for the following code:

std::stringstream os;

os << expr1 << expr2 << std::endl;

return MyStringClass(os.str());


I end up with about 3 allocations (2 in stringstream and 1 in MyStringClass).

Here:

MyStringClass s(expr1.length() + expr2.length());
std::strstream os(s.ptr(), s.length());
os << expr1 << expr2 << '\0';
return s;

return s;

Only 1 allocation (MyStringClass is a reference-counted null-terminated immutable string).

Share this post


Link to post
Share on other sites
But that's not the problem. std::strstream is part of the library and should cause any problems. The real problem is it uses global variables (as well as stringstream and probably many more from SC++L) so the question is is it guaratneed that they are destroyed AFTER my global variables (or Borland's TForms) or is it unspecified?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!