heap allocating classes

If a class has no constructor/destructor, is not part of an
inheritance heirarchy, is not a template, and only contains members of
integral types, then is it okay to allocate it off the heap? Is this
bad style?

For example:

class myClass {
public:
int myInt;
}
class myClass * pMyClass;

pMyClass = new myClass();
// --OR (in Win32)--
pMyClass = (class myClass *) HeapAlloc(hProcessHeap,
HEAP_ZERO_MEMORY, sizeof(class myClass));

re: heap allocating classes

"Shailesh Humbad" <s@mailpass.com> wrote in message
news:vbSlc.64334$Vp5.50939@fe2.columbus.rr.com...[color=blue]
> If a class has no constructor/destructor, is not part of an
> inheritance heirarchy, is not a template, and only contains members of
> integral types, then is it okay to allocate it off the heap? Is this
> bad style?[/color]

The "goodness/badness" of 'style' really depends upon
your application design.
[color=blue]
>
> For example:
>
> class myClass {
> public:
> int myInt;
> }
> class myClass * pMyClass;
>
> pMyClass = new myClass();[/color]

This is essentially the same as:

pMyClass = new myClass;

But you'll need to remember to delete the object when you're
done with it. Unless you have a compelling reason to dynamically
allocate, I recommend simply defining the object at the necessary
scope, whereupon it will be automatically destroyed without need
for your intervention:

MyClass x;
[color=blue]
> // --OR (in Win32)--
> pMyClass = (class myClass *) HeapAlloc(hProcessHeap,
> HEAP_ZERO_MEMORY, sizeof(class myClass));[/color]

We don't do Windows (or any other nonstandard code) here.

-Mike

re: heap allocating classes

On Tue, 04 May 2004 19:30:35 GMT, Shailesh Humbad <s@mailpass.com> wrote:
[color=blue]
>If a class has no constructor/destructor, is not part of an
>inheritance heirarchy, is not a template, and only contains members of
>integral types, then is it okay to allocate it off the heap? Is this
>bad style?[/color]

Where would you have gotten the impression that it is bad style to allocate
objects on the heap based on the structure of the objects? The choice of
storage class (statically allocated, automatic or from the heap/free store)
has, IMO, little to do with the nature of the object, but everything to do
with what you intend to /do/ with the object(s). For example, prior
knowledge (or lack thereof) of how many objects you'll need might sway the
choice of storage mechanism to use.
[color=blue]
>
>For example:
>
>class myClass {
> public:
> int myInt;
>}
>class myClass * pMyClass;[/color]
[color=blue]
>
>pMyClass = new myClass();[/color]

Okay, let's stick with the above, and not get into any Windoze nastiness.
What you've shown is perfectly OK, although (a) I'd use a struct in that
case, and (b) I prefer the paren-free syntax:

pMyClass = new myClass;

in order to maintain consistency with the non-dynamic syntax:

MyClass mc; // OK
MyClass mc(); // Bzzzt, C++ pothole of major proportions

-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

re: heap allocating classes

Leor Zolman wrote:[color=blue][color=green]
>>If a class has no constructor/destructor, is not part of an
>>inheritance heirarchy, is not a template, and only contains members of
>>integral types, then is it okay to allocate it off the heap? Is this
>>bad style?[/color]
>
>
> Where would you have gotten the impression that it is bad style to allocate
> objects on the heap based on the structure of the objects? The choice of
> storage class (statically allocated, automatic or from the heap/free store)
> has, IMO, little to do with the nature of the object, but everything to do
> with what you intend to /do/ with the object(s). For example, prior
> knowledge (or lack thereof) of how many objects you'll need might sway the
> choice of storage mechanism to use.
>
>[/color]
Thanks for your reply. My question really has to do with the
difference between an allocation function like malloc, HeapAlloc, etc.
and the new operator. Both allocate space for the class object off
the free store or heap. The new operator additionally calls any
constructor defined for the class (and any in the inheritance chain).
That's the only difference I can think of until I read this article,

http://www.codeproject.com/tips/newa...asp?print=true

, which explains that new throws an exception on failure rather than
returning an error code (NULL), and that it's not possible to realloc
space allocated by new. The new operator has always been a little
mysterious to me. There's nothing else going on right?

I would have used a struct, but the members of my class are only to be
accessible by two other classes and nothing else.

re: heap allocating classes

On Tue, 04 May 2004 22:52:07 GMT, Shailesh Humbad <s@mailpass.com> wrote:
[color=blue]
>Leor Zolman wrote:[color=green][color=darkred]
>>>If a class has no constructor/destructor, is not part of an
>>>inheritance heirarchy, is not a template, and only contains members of
>>>integral types, then is it okay to allocate it off the heap? Is this
>>>bad style?[/color]
>>
>>
>> Where would you have gotten the impression that it is bad style to allocate
>> objects on the heap based on the structure of the objects? The choice of
>> storage class (statically allocated, automatic or from the heap/free store)
>> has, IMO, little to do with the nature of the object, but everything to do
>> with what you intend to /do/ with the object(s). For example, prior
>> knowledge (or lack thereof) of how many objects you'll need might sway the
>> choice of storage mechanism to use.
>>
>>[/color]
>Thanks for your reply. My question really has to do with the
>difference between an allocation function like malloc, HeapAlloc, etc.
>and the new operator.[/color]

Your next question, you mean? That doesn't sound much like the first one...
[color=blue]
>Both allocate space for the class object off
>the free store or heap.[/color]

Right, and the default behavior of new may very well be to use malloc
internally, but code would be non-conformant if it actually assumed that
and attempted to do something that relied upon it (such as free() the
memory.)
[color=blue]
> The new operator additionally calls any
>constructor defined for the class (and any in the inheritance chain).[/color]

Well, just think of it as calling "the" constructor for the object being
instantiated (or objects in an array). The fact that the constructor may
call others is somewhat tangential.
[color=blue]
> That's the only difference I can think of until I read this article,
>
>http://www.codeproject.com/tips/newa...asp?print=true
>
>, which explains that new throws an exception on failure rather than
>returning an error code (NULL),[/color]

True, but that is an "exceptional" condition; i.e., how out-of-memory is
handled doesn't significantly affect normal performance of the allocation
mechanism, and ought only be an issue with respect to choosing the most
appropriate way in your program for dealing with the possibility of running
out of memory. You can even tell new not to throw an exception (but just
return NULL) using the nothrow syntax, eliminating that as a difference, if
you so desire.
[color=blue]
> and that it's not possible to realloc
>space allocated by new.[/color]

Yes, well, realloc is rather quirky in its own right, so no great loss
there.
[color=blue]
> The new operator has always been a little
>mysterious to me. There's nothing else going on right?[/color]

I don't know how deep you want to go with that question (not that I know
much more about it than what's already been said), but I'd suggest that
when using C++ in general, you stick with new/delete unless you have some
/very/ good reason to use the *alloc/free instead.
[color=blue]
>
>I would have used a struct, but the members of my class are only to be
>accessible by two other classes and nothing else.[/color]

And you've declared them public? :-)
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html