Discussion in 'OT Technology' started by Peyomp, Mar 13, 2006.
only reading the section about c++, he sounds like a n00b. Bitching and complaining about handling memory?
Now YOU sound like a n00b thats hasn't spent enough time chasing memory leaks.
Page 3 says this e-book was published in 1994. C++ has changed considerably since then. The STL has been added, which includes built-in garbage collection mechanisms such as smart pointers.
All I had to do was read the forward section to know this guy is either a bullshit artist, or somebody paid by MS to write bullshit. Not to mention it's far out of date.
well we all know there are never any memory leaks with windows programs.
reading....with a grain of salt
Has Unix really changed since 1984? How?
Uhhh I still code in c++ almost daily. You, however, obviously don't, hence should not argue. There have been MANY improvements since 84. Like samm said with the development torward GC. Even the new .NET extensions as of late are miles ahead of the earlier versions of c++.
are you talking basic command line syntax? Because even Bash has significantly change since 84.
Great, and yet how much time is spent today, chasing memory leaks? I'm so tired of hearing C++ programmers say "Memory leaks? Not ME!"
not much time at all. Like i said, take a look into today's GC techniques. When it comes down to it, just don't be a lazy programmer. What language, do you suggest people use instead of C++? I would argue there is not a good replacement when you look at the applications that use it
there are even memory leak trackers out there.
If a problem is big enough for an entire subset of software to exist in order to deal with the problem...
Its like herpes. An enormous problem that nobody personally admits to... and yet you keep seeing those Celebrex ads.
is sounds like you're calling the memory leaks an inherit problem of the language. Managing your own memory is a FEATURE of c++ and other programming languages. If you don't use it right, then it will bite you.
It seems like every C++ programmer says that its not their problem, its those OTHER C++ guys who have the memory leaks.
welcome to the world of development. It's always the OTHER guy's fault. You could make this arguement for anything IT related.
I'll pass. Thanks.
I love Unix. But its a good read. Its hardly a windows loving thing as has been suggested. Dennis Ritchie wrote the foreword for fuck's sake.
if there is a programming language, there is a set of tools to track down problems related to development.
You will experience memory leaks if your C++ code has new and delete operations, and pointer arithmetic all over the place. I avoid memory leaks by using smart pointers and RAII idioms in my code. For developers who cannot use such methods to avoid resource leaks (old code, third party library, etc.) I suggest using a memory leak detector such as valgrind or BSD leaks, or a garbage collector module.
In summary, the amount of time spent on chasing leaks in a C++ project is proportional to the skill of the developer in my opinion.
Its just that I've never met a C++ guy that admitted to having consistent memory leak problems. Its always someone else. Kinda like I've never met a Java guy that admits to performance problems. Sure people shirk responsibility... but there's an underlying problem in both cases.
You have many pointers to manage, and if you forget to properly manage one, you have a bug that can be a motherfucker to find.
Stroustroup (or however you speel it) has stated that C++ will include some garbage collection as an option, as part of the specification in a future version.
Anyway I'm not a C++ guy. I just hate it when C++ gets used where a language featuring garbage collection should be used and I get to test it. As to the original book, its funny.
As I said previously, manipulating pointers directly is asking for trouble. Using objects to manage resources is a much easier approach.
The proposed transparent GC module for the C++0x standard was still under consideration during last month's C++ standards committee meeting:
It's a good read in my opinion, and I look forward to its inclusion in the standard as an alternative to using smart pointers or the managed pointers in C#.