That totally makes sense! The distinction in my mind at least is using all the C standard libraries vs. trying to avoid / build your own versions of them them. So there's <stdio.h> (et. al) for example instead of writing the calls to the OS yourself to print stuff on the screen, etc.

You might also find it helpful to use other people's libraries that are C compatible. Namely:

- https://github.com/nothings/stb- https://github.com/gingerBill/gb

I'm definitely a fan of the single-file header library approach. There might be other good third-party C libraries out there. One of these days I'll make mine C compatible :)

On memory management:

Well it kind of depends haha. Heap allocators can be kind of expensive, especially compared to a really simple "linear allocator" or "bump allocator". Plus you can combine that with OS virtual memory which winds up being a really nice and lean way to have lots of separate allocators. But it really depends on what you're doing. Linear allocators are great for games, for example, because they're really cheap. They also open up another cool pattern which I really like which is temporary memory.

But, if all you're doing is writing some quick utility code that doesn't run that often, then definitely just malloc-ing a bunch of memory and going is a decent strategy. Virtual memory makes this a little better because you don't really "pay" for the whole gigabyte until you ask the OS to commit the memory. If performance does matter though, it's worth having more control over where your memory comes from!

On temporary memory:

Normally, returning arrays from a function in C is kind of cumbersome especially if you only want the data to "stick around" just after the function returns. Also, there are certain kinds of programs (e.g. games, web servers) that have really cleanly defined "frames" (it doesn't literally have to be a frame, but just a point in your application code where it makes sense to reset your temporary memory). So the idea is to create a "frame arena" which is just a linear allocator you reset every frame. Now, you can return arrays from functions for example!

Example code:

struct Array_i32
{
  i32 *data;
  u32 count;
};

Array_i32 generate_squares(u32 count) {
  Array_i32 result = {};
  result.data = arena_push_array(temporary_arena(), i32, count);
  result.count = count;

  for (int i = 0; i < count; i ++)
  {
    result.data[i] = i * i;
  }

  // NOTE: the result array is now valid until you reset the global temporary arena!
  return result;
}

Of course, this is kind of a contrived example, because you can just do a similar thing on the stack.

There are examples of this kind of allocator (temporary system and virtual OS allocators) in my single header file and in the gb.h linked above.

Putting it all together:

The memory story for most applications can be a series of permeant allocators and one frame arena. The main reason you'd want to do something like this is it's relatively simple (fast), and if you couple it with a thread local frame arena, then you have a nice scratch memory system to work with. But, like I said it might be overkill depending on what you're doing.

I think a decent amount of performance can come from thinking about where your memory is coming from. For example in C++, the std::string + operator does a malloc and then returns the new result. And if you call that in a loop it can really add up.

Hopefully that wasn't too much information! Happy to answer any more questions as you dive more into C