Creating "classes" in C, on the stack vs the heap?

Question

Whenever I see a C "class" (any struct that is meant to be used by accessing functions that take a pointer to it as the first argument) I see them implemented like this:

typedef struct
{
    int member_a;
    float member_b;
} CClass;

CClass* CClass_create();
void CClass_destroy(CClass *self);
void CClass_someFunction(CClass *self, ...);
...

And in this case CClass_create always mallocs it's memory and returns a pointer to that.

Whenever I see new come up in C++ unnecessarily, it usually seems to drive C++ programmers crazy, but this practice seems acceptable in C. What gives? Is there some reason behind why heap-allocated struct "classes" are so common?

Answer 1

There are several reasons for this.

1. Using "opaque" pointers
2. Lack of destructors
3. Embedded systems (stack overflow problem)
4. Containers
5. Inertia
6. "Laziness"

Let's discuss them briefly.

For opaque pointers, it enables you to do something like:

struct CClass_;
typedef struct CClass_ CClass;
// the rest as in your example

So, the user doesn't see the definition of struct CClass_, insulating her from the changes to it and enabling other interesting stuff, like implementing the class differently for different platforms.

Of course, this prohibits using stack variables of CClass. But, OTOH, one can see that this doesn't prohibit allocating CClass objects statically (from some pool) - returned by CClass_create or maybe another function like CClass_create_static.

Lack of destructors - since C compiler will not automatically destruct your CClass stack objects, you need to do it yourself (manually calling the destructor function). So, the only benefit left is the fact that stack allocation is, in general, faster than heap allocation. OTOH, you don't have to use the heap - you can allocate from a pool, or an arena, or some such thing, and that may be almost as fast as stack allocation, without the potential problems of stack allocation discussed below.

Embedded systems - Stack is not an "infinite" resource, you know. Sure, for most applications on today's "Regular" OSes (POSIX, Windows...), it almost is. But, on embedded systems, stack may be as low as a few KBs. That's extreme, but even "big" embedded systems have stack that are in MBs. So, it will run out if over-used. When it does, mostly there is no guarantee what will happen - AFAIK, in both C and C++ that's "Undefined behaviour". OTOH, CClass_create() can return NULL pointer when you're out of memory, and you can handle that.

Containers - C++ users like stack allocation, but, if you create a std::vector on stack, its contents will be heap allocated. You can tweak that, of course, but that is the default behaviour, and it makes ones life much easier to say "all members of a container are heap-allocated" rather than trying to figure out how to handle if they are not.

Inertia - well, the OO came from SmallTalk. Everything is dynamic there, so, the "natural" translation to C is the "put everything on the heap" way. So, the first examples were like that and they inspired others for many years.

"Laziness" - if you know you only want stack objects, you need something like:

CClass CClass_make();
void CClass_deinit(CClass *me);

But, if you want to allow both stack and heap, you need to add:

CClass *CClass_create();
void CClass_destroy(CClass *me);

This is more work to do for the implementer, but is also confusing to the user. One can make slightly different interfaces, but it doesn't change the fact that you need two sets of functions.

Of course, the "containers" reason is also partially a "laziness" reason.

Answer 2

Assuming, as in your question, CClass_create and CClass_destroy use malloc/free, then for me doing following is bad practice:

void Myfunc()
{
  CClass* myinstance = CClass_create();
  ...

  CClass_destroy(myinstance);
}

because we could avoid a malloc and a free easily:

void Myfunc()
{
  CClass myinstance;        // no malloc needed here, myinstance is on the stack
  CClass_Initialize(&myinstance);
  ...

  CClass_Uninitialize(&myinstance);
                            // no free needed here because myinstance is on the stack
}

with

CClass* CClass_create()
{
   CClass *self= malloc(sizeof(CClass));
   CClass_Initialize(self);
   return self;
}

void CClass_destroy(CClass *self);
{
   CClass_Uninitialize(self);
   free(self);
}

void CClass_Initialize(CClass *self)
{
   // initialize stuff
   ...
}

void CClass_Uninitialize(CClass *self);
{
   // uninitialize stuff
   ...
}

In C++ we'd also rather do this:

void Myfunc()
{
  CClass myinstance;
  ...

}

than this:

void Myfunc()
{
  CClass* myinstance = new CCLass;
  ...

  delete myinstance;
}

In order to avoid an unnecessary new/delete.

Answer 3

In C, when some component provides a "create" function, the component implementer is also in control over how the component is initialised. So it not only emulates C++' operator new but also the class constructor.

Giving up on this control over initialisation means a lot more error checking on the inputs, so keeping control makes it easier to provide consistent and predictable behaviour.

I also take exception to malloc always being used to allocate memory. This may often be the case, but not always. For instance, in some embedded systems, you'll find that malloc/free is not used at all. The X_create functions can allocate in other ways, e.g. from an array whose size is fixed at compile-time.

Answer 4

This spawns a lot of answers because it is somewhat opinion-based. Still I want to explain why I personally prefer to have my "C Objects" allocated on the heap. The reason is to have my fields all hidden (speak: private) from consuming code. This is called an opaque pointer. In practice, it means your header file doesn't define the struct in use, it only declares it. As a direct consequence, consuming code can't know the size of the struct and therefore stack allocation becomes impossible.

The benefit is: consuming code can never ever depend on the definition of the struct, that means it's impossible that you somehow render the contents of the struct inconsistent from the outside and you avoid unnecessary recompilation of consuming code when the struct changes.

The first issue is addressed in c++ by declaring fields to be private. But the definition of your class is still imported in all compilation units that use it, making it necessary to recompile them, even when only your private members change. The solution often used in c++ is the pimpl pattern: have all private members in a second struct (or: class) that is only defined in the implementation file. Of course, this requires your pimpl to be allocated on the heap.

Adding to that: modern OOP languages (like e.g. java or c#) have means to allocate objects (and typically decide whether it's stack or heap internally) without the calling code knowing about their definition.

Answer 5

In general, the fact that you see a * does not mean it has been malloc'd. You could have got a pointer to static global variable, for instance; in your case, indeed, CClass_destroy() does not take any parameter which supposes it already knows some information about the object being destroyed.

Moreover, pointers, whether or not malloc'd, are the only way that allow you to modify the object.

I don't see particular reasons for using the heap instead of the stack: you don't get less memory used. What's needed, though, to initialize such "classes" are init/destroy functions because the underlying data structure may actually need to contain dynamic data, therefore the use of pointers.

Answer 6

I would change the "constructor" to a void CClass_create(CClass*);

It won't return an instance/reference of the struct, but be called on one.

As of whether it is allocated on the "stack" or dynamically, it depends entirely on your usage scenario requirements. However you allocate it, you just call CClass_create() passing the allocated struct as a parameter.

{
    CClass stk;
    CClass_create(&stk);

    CClass *dyn = malloc(sizeof(CClass));
    CClass_create(dyn);

    CClass_destroy(&stk); // the local object lifetime ends here, dyn lives on
}

// and later, assuming you kept track of dyn
CClass_destroy(dyn); // destructed
free(dyn); // deleted

Just be careful not to return a reference to a local (allocated on the stack), because that's UB.

However you allocate it, you will need to call void CClass_destroy(CClass*); in the right spot (the end of that object's lifetime that is), and if dynamically allocated, also free that memory.

Distinguish between allocation/deallocation and construction/destruction, those are not the same (even if in C++ they might be automatically coupled together).

Answer 7

C lacks certain things that C++ programmers take for granted viz.

1. public and private specifiers
2. constructors and destructors

The big advantage of this approach is that you can hide the struct in your C file and force the correct construction and destruction with your create and destroy functions.

If you expose the struct in your .h file, this will means users can access the members directly which breaks encapsulation. Also not forcing the create allows incorrect construction of your object.

Answer 8

Because a function can only return a stack allocated struct if it contains no pointers to other allocated structs. If it only contain simple objects (int, bool, floats, chars and arrays of them but no pointer) you can allocate it on stack. But you must know that if you return it, it will be copied. If you want to allow pointers to other structs, or want to avoid the copy then use heap.

But if you can create the struct in a top level unit and only use it in called functions and never return it, then stack is appropriate

Answer 9

If the maximum number of objects of some type that will need to exist simultaneously is fixed, the system will need to be able to do something with every "live" instance, and the items in question don't consume too much money, the best approach is generally neither heap allocation nor stack allocation, but rather a statically-allocated array, along with "create" and "destroy" methods. Using an array will avoid the need to maintain a linked list of objects, and will make it possible to handle the case where an object can't be destroyed immediately because it's "busy" [e.g. if data is arriving on a channel via interrupt or DMA when user code decides it's no longer interested in the channel and disposes of it, the user code can set a "dispose when done" flag and return without having to worry about having a pending interrupt or DMA overwrite storage which is no longer allocated to it].

Using a fixed-sized pool of fixed-sized objects makes allocation and de-allocation much more predictable than taking storage from a mixed-sized heap. The approach isn't great in cases where demand is variable and the objects take up a lot of space (individually or collectively), but when demand is mostly consistent (e.g. an application needs 12 objects all the time, and sometimes needs up to 3 more) it can work out much better than alternative approaches. The one weakness is that any setup must either be performed at the place where the static buffer is declared, or must be performed by executable code in the clients. There's no way to use variable-initialization syntax at a client site.

Incidentally, when using this approach there's no need to have client code receive pointers to anything. Instead, one can identify the resources using whatever size integer is convenient. Additionally, if the number of resources will never have to exceed the number of bits in an int, it may be helpful to have some status variables use one bit per resource. For example, one could have variables timer_notifications (written only via interrupt handler) and timer_acks (written only via mainline code) and specify that bit N of (timer_notifications ^ timer_acks) will be set whenever timer N wants service. Using such an approach, code need only read two variables to determine whether any timer needs service, rather than having to read one variable for each timer.

Answer 10

Is your question "why in C it's normal to allocate memory dynamically and in C++ it's not"?

C++ has a lot of constructs in place that make new redundant. copy, move and normal constructors, destructors, the standard library, allocators.

But in C you cannot get around it.

Answer 11

Its actually a backlash to C++ making "new" too easy.

In theory, using this class construction pattern in C is identical to using "new" in C++, so there should be no difference. However, the way people tend to think about the languages is different, so the way people react to the code is different.

In C it is very common to think about the exact operations the computer will have to do to accomplish your goals. It's not universal, but it is a very common mindset. It is assumed that you have taken the time to do the cost/benefit analysis of the malloc/free.

In C++, it has gotten much easier to write lines of code which do a great deal for you, without you even realizing it. It is quite common for someone to write a line of code, and not even realize that it happened to call for 100 or 200 new/deletes! This has caused a backlash, where C++ developer will fanatically nitpick at news and deletes, out of fear that they are being called accidentally all over the place.

These are, of course, generalizations. In no way do the entire C and C++ communities fit these molds. However, if you are getting flack over using new instead of putting things on the heap, this may be the root cause.

Answer 12

It is rather strange that you see it so often. You must have been looking as some "lazy" code.

In C the technique that you describe is typically reserved to "opaque" library types, i.e. struct types whose definitions are intentionally made invisible to the client's code. Since the client cannot declare such objects, the idiom has to really on dynamic allocation in the "hidden" library code.

When hiding the definition of the struct is not required, a typical C idiom usually looks as follows

typedef struct CClass
{
    int member_a;
    float member_b;
} CClass;

CClass* CClass_init(CClass* cclass);
void CClass_release(CClass* cclass);

Function CClass_init initializes the *cclass object and returns the same pointer as result. I.e. the burden of allocating memory for the object is placed on the caller and the caller can allocate it in any way it sees fit

CClass cclass;
CClass_init(&cclass);
...
CClass_release(&cclass);

A classic example of this idiom would be pthread_mutex_t with pthread_mutex_init and pthread_mutex_destroy.

Meanwhile, using the former technique for non-opaque types (as in your original code) is generally a questionable practice. It is exactly questionable as gratuitous use of dynamic memory in C++. It works, but again, using dynamic memory when it is not required is as frowned upon in C as it is in C++.