This is my blog. I do it with github gist because I hate everything web related and I wanted a blog easy and fast. I hope this will work.
| typedef struct rf_sizef | |
| { | |
| float width, height; | |
| } rf_sizef; | |
| RF_API rf_sizef rf_measure_text_rec(rf_font font, const char* text, int text_len, rf_rec rec, float font_size, float extra_spacing, bool wrap) | |
| { | |
| rf_sizef result = {0}; | |
| if (font.valid) |
| #include "terminal_colors.h" | |
| #ifdef WIN32 | |
| #include "windows.h" | |
| /* | |
| Sources: | |
| https://github.com/microsoft/WSL/issues/1173#issuecomment-254250445 | |
| https://github.com/microsoft/WSL/issues/1173 |
| #pragma once | |
| #include "type_traits" | |
| #define rf_generate_enum_class_math_operations(rf__enum_type__) \ | |
| /* + += - -= * *= / /= % %= */ \ | |
| inline rf__enum_type__ operator+(rf__enum_type__ lhs, rf__enum_type__ rhs) \ | |
| { \ | |
| using rf__underlying_enum_type = std::underlying_type_t<rf__enum_type__>; \ | |
| rf__enum_type__ rf__enum_math_op_result = static_cast<rf__enum_type__>(static_cast<rf__underlying_enum_type>(lhs) + static_cast<rf__underlying_enum_type>(rhs)); \ |
In this article we are going to explore patterns regarding centralizing and minimizing allocations. We will start with a brief cover of how memory management evolved and why RAII became the culturally dominant way of managing memory in C++ and other low level systems programming languages, followed by a presentation of core ideas and strategies related to Centralized Memory Management.
Programs are fundamentally about transforming data. Even our basic model of computing, the Von Neumann Machine, has 3 core components, an input device, a processing unit, and an output device. Even tasks, like rendering graphics or sending data over a network, are fundamentally just about manipulating data.
Transforming the data however is not free. We have certain limitations and that is partially where the problem that we are trying to solve as developer comes from, as we have to balance those limitations in order to achieve our goal. Data
There are multiple styles you can write modern C in and thus multiple ways to reason and deal with NULL. You have to on some level reason about your use case, patterns and audience.
How you write this might be affected for example by whether you are writing the code just for yourself, a team of a certain size with a certain level of shared understanding, or a public library targetting a certain audience.
Documentation wise, I think going with the assumption that a pointer is not nullable by default is a good strategy, so if you are writing a function that takes optional pointers you should probably document that, even if it's by something simple like a naming convetion (eg: a prefix like opt_ or optional_).
| #define SDL_MAIN_USE_CALLBACKS 1 | |
| #include <SDL3/SDL_main.h> | |
| #include <SDL3/SDL.h> | |
| #include <EGL/egl.h> | |
| #include <EGL/eglext.h> | |
| #include <GLES2/gl2.h> | |
| #include <GLES3/gl3.h> | |
| struct AppState |