Hi. I was wondering when to declare class member fields as static or dynamic variables? If I have everything I need to know as soon as I enter the constructor, it may as well be static right? Is this true all the time?

c++.

I mean dynamically allocated, as in pointers and new().

class a
{
a(){//do nothing}
field f
}

class b
{
b(){f = new f();}
field *f
}

If you are just calling the default constructor for f always, it may as well be allocated statically right? Provided you dont want to pass it round like a pointer or anything..

Is there any performance difference in deallocation of a class between these methods?

Is there ANYTHING different? (other than you can use the field f as a pointer...)

Quote:class member fields as static or dynamic variables?

In C++:
"static" - auto-allocated, usually allocated on stack, cleaned up by compiler when no longer accessible
"dynamic" - free-store allocated, usually allocated on heap

The word static itself means something completely and entirely different.

Quote:I've heard new and especially delete are CPU intensitive...

Irrelevant statement.

If you need to allocate data dynamically, you need to use new/malloc/custom-allocator. If you can use stack, then you can use auto-allocation.

Freestore vs. auto-allocation is a matter of design, not performance. And while it's perfectly viable and possible to write a pure stack-based application, it tends to be too restrictive.

Quote:Is there any performance difference in deallocation of a class between these methods?

Yes. When accessing free-store, it's almost always necessary to dereference a pointer. When accessing auto-allocated object, it usually isn't necessary, since compiler can hard-code the offsets into code. YMMV. Of course, it also matters how the enclosing instances is allocated.

Quote:Is there ANYTHING different? (other than you can use the field f as a pointer...)

Yes, it's a whole world of difference. When using raw pointers, you need to properly implement the rule of three (copy constructor, assignment, virtual destructor) and take care of exception safety. Since you mentioned performance, you also need to consider allocation failures, custom allocation, memory alignment, data locality and memory fragmentation.

With auto-allocation, all of these are taken care for you, and unless you need to pass data to some specialized API (graphic cards, SIMD, for example), where you require specific memory layout of your data, you don't need to worry about any of the above, since compiler will automatically handle (almost) all the cases.

As above. Since dynamic allocation and free store management involve overhead in programmer time (i.e., more work for you), prefer non-dynamic allocation until the design warrants it. The simpler your code, the less bugs you are likely to create.