On 30/05/2013 10:46 PM, Francois Labreque wrote:

>>> A raw pointer is a basic type and thus will likewise not be implicitly
>>> initialized.
>>
>> So it points to random memory?
>
> Yes. C++ still allows you to shout yourself in the foot.

Oh, I wasn't disputing that. Just checking.

Today I discovered that some of the code I copy-pasted actually had some 
memory allocation in it, and I hadn't explicitly deallocated it again.

To be clear... I only need to do explicit deallocation if I've done 
explicit allocation in the first place, right?

   unsigned char foo[512];

vs

   unsigned char * foo = new[512];

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> To be clear... I only need to do explicit deallocation if I've done 
> explicit allocation in the first place, right?

Every 'new' must have a correspondent 'delete'. If you don't write 'new'
then you don't have to worry about any deletes either.

Of course the exception to this is if you are using a smart pointer like
std::shared_ptr or std::unique_ptr, in which case you do write 'new',
but let the smart pointer do the 'delete' for you.

If you really need to explicitly allocate memory, then it's usually a
good idea to use such a smart pointer, because they will make sure that
they will delete the object when the last smart pointer to it dies, and
delete it only once.

The thing is, even if you have written one 'new' and one 'delete' in your
code, the object might be being deleted more than once. This is because of
the wonderful thing in C++ that is copying and assigning of classes.

-- 
                                                          - Warp

Post a reply to this message

On 31/05/2013 09:41 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> To be clear... I only need to do explicit deallocation if I've done
>> explicit allocation in the first place, right?
>
> Every 'new' must have a correspondent 'delete'. If you don't write 'new'
> then you don't have to worry about any deletes either.
>
> Of course the exception to this is if you are using a smart pointer like
> std::shared_ptr or std::unique_ptr, in which case you do write 'new',
> but let the smart pointer do the 'delete' for you.
>
> If you really need to explicitly allocate memory, then it's usually a
> good idea to use such a smart pointer, because they will make sure that
> they will delete the object when the last smart pointer to it dies, and
> delete it only once.
>
> The thing is, even if you have written one 'new' and one 'delete' in your
> code, the object might be being deleted more than once. This is because of
> the wonderful thing in C++ that is copying and assigning of classes.

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...

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...)

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

Post a reply to this message

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

On 5/24/2013 12:00 PM, Warp wrote:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> This would be acceptable if VC offered some how to find out WHAT
>> TEMPLATE it was attempting to expand when the error occurred. But no, it
>> just shows you the source code for the STL (or Boost or whatever) and
>> points at the line on which the problem was actually detected. There
>> seems to be no way that I can discover what line of which file resulting
>> in this template being invoked in the first place - and THAT is surely
>> where the problem is, not in STL itself.
>
> All compilers I know if will give you the full chain of calls that
> ended up in the erroneous line. (And usually looking at the first error
> message that refers to your code will immediately reveal the problem.)
>
> I would be quite surprised if VC didn't do this.

The version of VS C++ I use at work does not give a reference chain for 
any error.  In a number of cases I am unable to discern what caused the 
cited file to be invoked.

Regards,
John

Post a reply to this message