Instantiating and deleting objects versus the malloc family

[sterretje]

I did not want to hijack Temporary store variable

@econjack

read about calloc(), malloc(), and free().

@RayLivingston

Please, do NOT use malloc() et al. That is the stone age way of doing things, and is risky if not done exactly right. Define one or more object classes to contain the information. When you need it, use new to create an instance of the needed class(es). When you're done with it, use delete to discard the instance(s). That is the RIGHT way to do it.

@RayLivingston, can you please explain? Is the use of instantiating an object and deleting it not the same as the use of the malloc family etc. and free? And has the same risks?

[RayLivingston]

Sure, you can abuse new and delete. But the vast majority of "newbies" and a shocking number of alleged "experts" routinely write code using malloc() and free() that are recipes for disaster, by failing to check the return value of malloc(), failing to ever call free(), and others. With c++, there really is no reason to resort to such archaic, low level methods. It CAN be done safely using malloc and free, but why not simply learn the better, modern ways instead. And it will force you to learn classes, structs and other object methods, which are absolutely worth learning, as, used properly, you will create better, more reliable, more maintainable code.

[gfvalvo]

'new' allocates the memory and builds the object using the class's constructor. It also returns a pointer of the proper type. 'malloc()' only allocates the memory, and it's return value must be cast to the appropriate type.

new / delete is also used by smart pointers that reduce the chance of memory leaks by de-allocating the memory when their lifetime ends.

[sterretje]

Thanks for the replies

@RayLivingston

Sure, you can abuse new and delete. But the vast majority of "newbies" and a shocking number of alleged "experts" routinely write code using malloc() and free() that are recipes for disaster, by failing to check the return value of malloc(), failing to ever call free(), and others.

I'm not sure what a constructor will return if one runs out of memory, I assume NULL in which case that should be tested anyway. And calling delete can be forgotten as easily calling free. The only advantage might be that the destructor is automatically called if the object goes out of scope (as indicated by @gfvalvo).

@gfvalvo

It also returns a pointer of the proper type. 'malloc()' only allocates the memory, and it's return value must be cast to the appropriate type.

That's a fair point. But I have lived with that for many years

[sherzaad]

@gfvalvo

would it be possible to have a good arduino example of how to use those if you know any?

been using 'malloc' occationally but not really familiar with how to use 'new' and 'delete' correctly!

you never too old to learn something new!

[gfvalvo]

@sterretje, @sherzaad:
First, it's absolutely just as easy to forget to invoke 'delete' as it is free(). The recommended defense against that is to handle with raw pointers inside a class so that you can put the call to 'delete' in the class's destructor.

I suppose you could do that with malloc() / free() also. So, it could be argued that the only real advantages of new / delete are (decreasing importance, IMO):

• Invokes the class's constructor.

• Returns pointer of correct type.

• It's the correct, "C++ Way" to do it.

An extension of the "handle raw pointers in a class" idea is the smart pointer concept. Here's A Tutorial

As a further aside:

@sterretje

The only advantage might be that the destructor is automatically called if the object goes out of scope (as indicated by @gfvalvo).

I intentionally used the term "lifetime" rather than "scope" as there's an important difference:

void Function1() {
  uint32_t localVariable;

  // localVariable is IN SCOPE here
  Function2(); // <----- call Function2
  // localVariable is IN SCOPE here
  
} // localVariable's LIFETIME ends here

void Function2(){
  // localVariable is still "alive", but is OUT OF SCOPE here
}

[sterretje]

@gfvalvo

I intentionally used the term "lifetime" rather than "scope" as there's an important difference:

Your example made it clear, thanks for that.

[Coding_Badly]

@sterretje

I'm not sure what a constructor will return if one runs out of memory, I assume NULL in which case that should be tested anyway.

Normally that would be an exception. The AVR core changes the behaviour to return NULL.

[sterretje]

I suspected that, thanks.

@Coding_Badly

The AVR core changes the behaviour to return NULL.