Orchid Win7 v1 <voi### [at] devnull> wrote:
> Without revealing too many details about the product I'm working on, it 
> deals with byte-level processing of binary protocol data. So there's A 
> LOT of char* variables floating around the place. In short, it's just 
> the sort of code where a tiny bug will make the program output gibberish 
> or crash spectacularly. It makes me feel twitchy inside...

If a program needs to use lots of raw pointers to dynamically allocated
memory, it requires quite a lot of experience and following certain design
principles in order for the code to be safe. (There are situations where
smart pointers just can't be used. For example a smart pointer won't help
you a bit if you need a pointer that points to some element of a
dynamically allocated array.)

I freely admit this is just an evil that one has to live with if one is
programming with a language of the C family. However, having to actually
write that kind of code is a lot less frequent than one might think,
especially if you are writing the entire program and you get to design it
properly from the very start.

In most cases one should avoid allocating arrays directly with 'new',
and use std::vector instead. Then, if possible, one should avoid having
raw pointers pointing to the elements of the vector, except in very simple
situations (where it's trivial to see that no such pointer will get
invalidated or be used after the vector has been destroyed.) Prefer
indexing the vector object directly, if possible. (Or use vector iterators.
Many compilers can add checks to them in debug mode, which can help quite
a lot.)

Sure, there are situations where std::vector won't cut it, or where such
pointers just have to be used, but these situations are not all that
common in practice.

> The other fun thing is that sometimes one function calls another 
> function, and the other function returns a char*. So "you" didn't 
> allocate anything, but the function you called did, and you need to 
> remember to deallocate it. (Arguably that's poor design, but hey, I 
> didn't write the code...)

That's extremely poor design, and is one of the big no-no's in C++
programming. It's asking for trouble.

> PS. What black magic is it that makes delete[] work correctly?

It depends on the compiler and the runtime library, but most probably
there's metadata at the beginning of an allocated block of memory that
says how many elements there are in said block. 'delete[]' probably just
blindly takes that value (which is probably located at the pointer's
position minus some fixed offset) and assumes there are that many elements
in the array. (Obviously it will break horribly if you try to delete[]
a pointer that's not pointing to the first element of a dynamically
allocated array.)

-- 
                                                          - Warp

Post a reply to this message