Forem: Jonah Goldsmith

Don't Be Scared of Ternary Operators

Jonah Goldsmith — Thu, 12 Jan 2023 02:35:39 +0000

Sometimes when looking through a C/C++ codebase you may see these weird symbols littered through code that you do not understand. For example:

    z = (x < y) ? 10 : 0;

When I first started coding these operations scared me because I had no idea what was going on at all, but it is more simple than I thought!

The above statement is the same as:

if(x < y)
    z = 10;
else
    z = 0;

But using the ternary operator cuts the number of lines needed from 4 to 1! Not only does it cut down on the number of lines but it can also increase the readability of a program. Instead of having to look through 4 lines of code (or more if there are more if-else blocks), we can look at one single line with ternary operators. Here is another example:

int sum;
int x = 5;
int y = 0;

sum = (x == 5 ? (y == 0 ? 10 : 5) : 0);

In this case, we are doing a nested ternary operation. The integer sum will be equal to 10 when evaluated. These operations may not look useful but when implementing things like a stretchy buffer (dynamic array in C) these operations help make extremely powerful macros for dealing with dynamic arrays. In my next post, I will go over a super simple dynamic array class in C created with macros, ternary operators, and good ol' pointer arithmetic.

Temporary Allocations in C/C++

Jonah Goldsmith — Wed, 11 Jan 2023 03:13:16 +0000

Memory management is a very important part of programming in low-level languages. But you don't always need memory to last forever. Sometimes you might need memory only for a short amount of time, maybe to format a string or to load temporary data into a buffer so it can be written to disk and then discarded. If you allocate and deallocate memory for all these short allocations you will slow down your application by a lot!

Efficient Allocation Strategies

So how can we deal with these small allocations efficiently? The easiest way to do this is to create a bump allocator. Also known as a linear allocator, stack allocator, arena allocator, etc. The idea is very simple:

struct linear_allocator
{
    size_t total_size;
    size_t offset;
    void* start_ptr;
}

void create_linear_allocator(linear_allocator* allocator, size_t size)
{
    allocator->total_size = size;
    allocator->start_ptr = malloc(size);
    allocator->offset = 0;
}

All the linear allocator contains is a pointer to the memory buffer, an offset, and the total size of the buffer (which may not ever be used). Now, whenever we want memory we just use the offset to find the location of the buffer we can use for the allocation. Here is what that looks like:

void* linear_alloc(linear_allocator* allocator, size_t size)
{
    size_t cur_address = (size_t)a->start_ptr + a->offset;
    size_t next_address = cur_address;
    a->offset += size;
    return (void*)next_address;
}

//Now use it
int main()
{

    linear_allocator alloc = NULL;
    create_linear_allocator(&alloc, 12*1024) //12KB

    char* name = linear_alloc(&alloc, 3);
    name[0] = 'b';
    name[1] = 'o';
    name[2] = 'b';

    puts(name); //This will display - bob - to the console!

}

Using the linear allocator is very simple and now as long as our allocations fit into the size of the linear allocator we will only actually allocate memory once! Now this is already useful but now let's make our allocator reset every frame so that all allocations in the frame are "temporary"

void linear_allocator_reset(linear_allocator* alloc)
{
        alloc->offset = 0;
}

int main()
{

    linear_allocator alloc = NULL;
    create_linear_allocator(&alloc, 12*1024) //12KB

    while(true)
    {
        char* name = linear_alloc(&alloc, 3);
        name[0] = 'b';
        name[1] = 'o';
        name[2] = 'b';

        puts(name); //This will display - bob - to the console!

        //This "erases" all memory we allocated this frame
        linear_allocator_reset(&allocator); 
    }
}

Now we call can allocate memory every frame without actually calling "malloc".

This simple allocator is extremely powerful and can provide a crazy speed boost to your projects. But... we can do better.

Stack and Heap Teamwork

I'm warning you, get ready for code examples...

Something I have started to do is allow the creation of a temporary allocator with a local stack buffer as storage, and if we need more memory than the stack buffer provided then we can use the linear allocator to get the memory.

First, we will take a look at only using the stack for allocation. Yay pointer arithmetic!

int main()
{
    char buffer[1024];
    char* name = buffer + 3;
    name[0] = 'b';
    name[1] = 'o';
    name[2] = 'b';

    puts(name); //This will display - bob - to the console!
    //But this time no memory was allocated on the heap!
}

If you did not know. You can use char buffers as backing "memory" for other objects. One of the best features of C/C++ in my opinion. Let's expand on this and create an allocator that first uses a char buffer as backing memory but then switches to a linear allocator when it runs out.

//Our Temporary Buffer
typedef struct temp_allocator_buffer
{
    char buffer[1024];
}temp_allocator_buffer;

//Our Temp Allocator Structure
typedef struct temp_allocator
{
    struct temp_allocator_o* inst;
    void* (*realloc)(struct temp_allocator_o* data, void* ptr, size_t old_size, size_t new_size);
}temp_allocator;

//Represents the current allocation 
struct temp_allocator_item
{
    size_t size;
    size_t used;
};

//The internal data of our allocator
typedef struct temp_allocator_o
{
    char* buffer;
    struct linear_allocator* backing;
    struct temp_allocator_item* item;
}temp_allocator_o;

Here are the structure definitions we will need. Nothing too crazy.

void* temp_realloc(struct temp_allocator_o* data, void* ptr, size_t old_size, size_t new_size)
{
    struct temp_allocator_item* item = (struct temp_allocator_item *) data->item;
    //Since temp allocations cannot free we do nothing...
    if (new_size == 0)
        return NULL;
    //Does it fit in our static buffer?
    if (item && item->size - item->used >= new_size) {
        void *new = (char *)item + item->used;
        item->last_used = item->used;
        item->used += new_size;
        if(!ptr)
        {
            return new;
        }
        if (new != ptr && old_size && new_size)
            memcpy(res, ptr, old_size < new_size ? old_size : new_size); 
        return new;
    }else if(ptr && new_size) {
        void *new = linear_alloc(data->backing, new_size);
        memcpy(new, ptr, old_size);
        return new;
    }else
        return linear_alloc(data->backing, new_size);

}

We will work through the code one snippet at a time. This is our allocation function. My style is to have a single realloc function that takes care of malloc, realloc, and free. I also require the user of my allocators to pass the old size of allocations because then I do not have to store it in my allocator object.

First, we retrieve the item from our instance data pointer. Then, we check to see if no new size was given (meaning it is a free operation) if so, we do nothing. Next, we deal with our static buffer. We check to see if our "item" (basically the total size of our buffer and how much we used so far) has space for our new allocation. If it does we bump the pointer up to account for the new allocation. If the user passed a ptr into the function it means we are doing a realloc so we memcpy the old data into the new pointer. Doing this is not really necessary because bumping the pointer doesn't discard old data but I left it here for visualization purposes of what's going on.

Now if we do not have enough space in our static buffer we use the linear allocator we will pass to the create_temp_allocator function to allocate data and we memcpy any existing data into this new pointer. The last else statement is if the first allocation was greater than our static buffer size. Now let's see the other functions.

temp_allocator* create_temp_allocator_with_buffer(void* buffer, size_t size, linear_allocator* alloc)
{
    temp_allocator *ta = (temp_allocator *)buffer;
    *ta = (temp_allocator){
            .inst = (struct temp_allocator_o *)buffer+ sizeof(temp_allocator),
            .realloc = temp_realloc,
    };
    ta->inst->buffer = buffer + sizeof(temp_allocator)+sizeof(temp_allocator_o);
    ta->inst->backing = alloc;
    ta->inst->first = (struct temp_allocator_item *)(ta->inst->buffer);
    ta->inst->first->size = size;
    ta->inst->first->last_used = sizeof(struct temp_allocator_item);
    ta->inst->first->used = sizeof(struct temp_allocator_item) + sizeof(temp_allocator) + sizeof(temp_allocator_o);
    return ta;

}

This function creates our temporary allocator and returns it to the user. First, we use the static buffer as memory for our allocator. Then we bump the pointer and allocate the data for our instance data. We also point the realloc function pointer to our temp_realloc function. Next, we set our instance data buffer pointer to be the location in the static buffer after the allocator and the allocator data. Lastly, we pass the backing allocator (our linear allocator) to our instance data and create our "temp item" to hold the size and usage. These are the only two functions we need! It is that simple! Here is a usage example:

int main()
{

    linear_allocator alloc = NULL;
    create_linear_allocator(&alloc, 12*1024); //12KB
    while(true) 
    {
        temp_allocator_buffer b;
        temp_allocator* temp = create_temp_allocator_with_buffer(b, 1024, &alloc);    

    //Lets display bob again...
        char* name = temp->realloc(temp->inst, 0, 0, 3);
    //We allocate a size of 3, old size of 0, and no current ptr
        name[0] = 'b';
        name[1] = 'o';
        name[2] = 'b';
        puts(name);

    //So far we only used static memory...
    //Now lets make our temp allocator use the linear allocator
    //We will ask for 2KB of space for our new_name 
        char* new_name = temp->realloc(temp->inst, name, 3, 2*1024);

    //this still works because we copied the data over
        puts(new_name);

    //but now we are using the linear allocators memory.

    //reset the allocator and start the loop over!
        linear_allocator_reset(&alloc);
    }
}

This tiny example does not show the true power of this allocator but hopefully, it has inspired you or taught you a thing or two about pointers. I have started using this allocation strategy in my game engine and it is working nicely. My next idea is to have a separate linear allocator per thread in thread local storage so that I do not need any synchronization primitives to use a temp allocator in my game loop!

In my next post, I will talk about a simple dynamic array implementation and a version that uses this temporary allocator for fast temporary dynamic arrays!

Project Design in C/C++

Jonah Goldsmith — Mon, 09 Jan 2023 17:02:43 +0000

Design

What do I mean by project design? What I mean is the rules that you follow while developing your projects. This could be syntax rules, header include rules, directory structure rules, and anything else that you want to keep consistent while developing. When projects start to get bigger it can get harder to keep a code base clean. Today I am going to give some example rules that I follow to solve this issue.

Header Files

One rule that I always follow is that header files should not include other header files! I know this sounds like an impossible task... but it is fairly easy and comes with amazing benefits! First here is an example of breaking the rule:

#pragma once

#incude <stdint.h>
#include "my_graphics.h"
#include "my_math.h"
#include "my_huge_header.h"

So in this example, I have a header file that includes 4 other files. When this header gets included in any other file it will bring these 4 files with it. This may not sound like a huge problem but what if "my_huge_header.h" contained every single header file in the C standard library? Now every file is including that even if it doesn't need it. Not allowing headers to include other headers solves this issue and speeds up compile times drastically in big projects.

Here is an example of what I do instead:

#pragma once

struct object_i_need;

void create_object(object_i_need* p_obj);

Here I have a header file that includes no other header files and forward declares a struct that I will need to use in my function. In the implementation file, I will include the header file with the definition of this struct. Another benefit that comes with this structure is that it is very easy to see what this header file is doing. All forward declarations of needed objects come first, then function prototypes.

Namespaces, and API Interfaces

Another rule I follow is keeping the majority of my functions in structs holding function pointers. This gives me a kind of "namespace" in C and allows me to keep the global namespace very light, and allows easy creation of things like a plugin system.

Here is an example:

#pragma once

struct object_i_need;

struct object_creation_api
{
    void (*create_object)(object_i_need* obj);
};

//Can use conditional compilation so projects can easily reference this api!
//Or let users extern the structs themselves.

#ifdef LINKS_TO_ME
extern struct object_creation_api* obj_api;
#endif

In my implementation file I could do something like this:

#include "obj_creation.h"
#include "obj_i_need.h"

void internal_create_object(struct obj_i_need* obj)
{
    //Create the object
};

//Create the static instance holding the function pointers
struct object_creation_api api = {
    .create_object = internal_create_object
};

struct object_creation_api* obj_api = &api;

Now any file that externs the struct "obj_api" can use its interface!

Recap and Rule Breaks

Header files cannot include other header files
Most functions inside of structs that hold function pointers
I break the first rule only for macros, platform detection, and whatever I know the whole project will need.

So these are just a few things I do to keep my codebase clean and efficient while it grows. In the next few blogs I will be going over my memory tracking strategies and my plugin system :). Thanks for reading! NOW GO CODE!

A Beginner Dive into CMake

Jonah Goldsmith — Fri, 28 Oct 2022 13:00:45 +0000

If you are a C/C++ developer you already know that the ecosystem has a few problems compared to higher-level languages. The biggest one is the lack of a concrete build system. Languages like Rust and Java have native build systems that take care of creating your libraries and executables but all C++ has is a compiler and a lot of separate build system projects maintained by other people. I choose to work with CMake. Although I know everyone has mixed feelings about CMake I enjoy the workflow. Today I will run through a quick CMake project that contains a Static Library Project and an Executable Project.

In the image above I am showing what a basic CMake projects structure looks like. Let's break it down. In a folder, we have the top-level CMakeLists script. Which by the way is how we use CMake. By making a lot... and I mean a lot, of CMake scripts. Next, we have a "Lib" folder which will hold our Static Library project and an "Exec" folder which will hold our Executable Project. Let's take a look at what our top-level script looks like:

cmake_minimum_required(VERSION 3.2)

project(Blog)

add_subdirectory(Lib)

add_subdirectory(Exec)

This is by far the most simple CMake script you will ever see! The only thing we do in this script tells CMake which version is required, name the top-level project, and then tell the script to look for more scripts in the sub-folders Lib and Exec. Now let's see what our Static Library's script looks like:

cmake_minimum_required(VERSION 3.2)

project(Lib LANGUAGES CXX)

add_library(Lib lib.h lib.cpp)

target_include_directories(Lib 
PUBLIC
$<INSTALL_INTERFACE:include>
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/>
PRIVATE
)

Not much has changed with this script but let's go over what has! To start we are now telling CMake what languages this library will consist of. We do this in the project() function by saying 'LANGUAGES" followed by the languages we want to use. Next, we use the add_library() function to create our library. The first parameter is the name of the compiled library and the next parameter are all the files to be compiled. Now for the more complex-looking part!

The target_include_directories() function is a very important one.
Not only can this be used to include other libraries' headers into our project it can also be used to "Install" our headers into a project linking with us using CMake!

This is the beauty of CMake, being able to effortlessly build multiple projects; link them all together and find the headers. To create the include interface we add

$<INSTALL_INTERFACE:include> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/>

to the include directories function. The First line simply states which type of interface we are installing into our library and the second line says where our "include" files are. For this example, I set it to the current directory this script is in (God Bless the CMake macros!). That's all for the Static Library now we can move to our executable. Spoiler alert, IT IS SO SIMPLE.

cmake_minimum_required(VERSION 3.2)

project(Exec LANGUAGES CXX)

add_executable(Exec main.cpp)

target_include_directories(Exec 
PUBLIC
Lib
PRIVATE
)

target_link_libraries(Exec 
PUBLIC
Lib
PRIVATE
)

As you can see it is very similar to the library! Here are the differences:

We Call add_executable instead of add_library
Instead of building an Include Interface we just Include the "Lib" library
And we add a call to target_link_libraries() to link to the "Lib" library! And with that, we now have the scaffolding for our very own Cross Platform C++ Project!

Custom Memory Allocation With C++ Objects

Jonah Goldsmith — Fri, 28 Oct 2022 02:18:09 +0000

So, recently as I have gotten more and more obsessed with creating a game engine I have been battling with myself over something. C or C++? Besides the fact that I hate OOP or object-oriented programming and the fact that modern C++ is complicated and scary, there was another HUGE reason I did not want to make my codebase C++ focused. Memory management of Classes/Objects! While creating my projects in C, I have always created a sort of memory subsystem that controls how I allocate memory. But whenever I venture into C++ I get stuck! How am I supposed to control memory allocation if my objects need to call their constructor with the "new" operator/keyword? Well, after doing more research and learning more about C++ I learned it is not so hard after all. All we need is everyone's favorite thing... Template Metaprogramming! If you can't tell, I am not a fan of templates. But maybe they do come in handy for a few things. Let's jump into some code:

template <typename T, typename... Args>
T* memcreate(Args... arg)
{
    void* memory = malloc(sizeof(T));
    T* mem = new(memory)T(arg...);
    return mem;
}

struct testing
    {
    public:
        testing(int num, const char* word) {x = num; name = (char*)word;}
        ~testing() = default;
        int x;
        char* name;
    };

//USAGE:
testing* test = memcreate<testing>(10, "charles");

And would you look at that! Now we can use malloc(or better yet a custom allocator) and instantiate C++ objects without the new keyword! If you look closely you will see that we still use the "new" keyword in the template function. This version of the keyword is called "placement new" and is used to "place" the memory we allocate from one object onto another while also "instantiating" the object and calling its constructor. I am sure there is a more technical way to explain it but that's what I am going with! Oh and if you are wondering our delete function would look like this:

template <typename T>
void memdelete(T* ptr)
{
    ptr->~T();
    free(ptr);
}

Very, very, simple. Next Post I will try to go into more detail about why this is useful and how I can track memory allocations, and use things like custom allocators to have more performant allocations! Thanks for reading! Go Code!