22 Dec
2006
22 Dec
'06
10:43 a.m.
On 22 Dec 2006 at 9:07, Michael B. Brutman wrote:
Well, here you have a basic misunderstanding of how
C++ works.
Constructors and destructors require a little more tracking, but it does
not require a memory manager. A constructor runs when an object is
created, and the destructor runs when it goes out of scope. If you are
working with objects on the stack then additional memory management is
not needed - the compiler generates extra code to call the destructor as
appropriate.
I know that--but it's the temptation to use new() and delete() that
can get you into trouble. If you never explicitly destroy an object,
then you're fine, as you've said--unless you were supposed to (e.g.
creating global instances and then forgetting to delete them).
Memory leaks can be some of the most frustrating things to debug--and
plenty of production code has been released with them. For whatever
reason, they seem to be more common in C++ than in C.
Heaven only knows, had I been more enlightened, I might have well
saved a bunch of deveopment time by devising classes and methods for
all of that nasty Windows NT kernel-mode stuff--or maybe not.
Debugging a device driver can be a pretty miserable job and the less
syntactic "noise" in the way, the better for me. But that's the way
my mind works.
OTOH, I've written application code in C++ and have been pleasantly
surpised at ease at which the application went together and the
resulting executable size.
That doesn't mean that I'm anti-OOP; that would be just silly. But I
can write a typedef for a struct that includes data, pointers and
pointers to functions perfectly well in C.
So, if I'm writing a little utility that requires two pieces--say, a
device driver and the application code that invokes it, I'l still
write the driver in C (or assembly, whichever is appropriate) and the
application in C++.
It's just the way I think.
Cheers,
Chuck