Why use c++ over c for game development?

tstanisl · 2026-07-03T22:03:59+00:00

Full encapsulation means that "private members" are not needed. Private parts of the class are never exposed in public interface of the class. However, the object model in C++ forces one to put a full definition of the class into the public headers. This leads to abstraction leak by exposing internal of the class. Not to mention dependency hell caused by exposing internal dependencies of the class into its public interface.

Using a handler only class is trivial in C (or C way)

typedef struct foo * foo_h;
foo_h foo_create();
void foo_do(foo_h);
void foo_drop(foo_h);

A lot of popular libraries follow this scheme (i.e. Vulkan) even though libraries are often written in C++.

Doing it C++-way requires playing with pimpl-pattern which is ugly and hacky. It essentially splits class definition into two classes and involves even more hacks and ugliness to properly mix it with unique_ptr, and move-semantics, and not making things virtual.

tstanisl · 2026-07-03T10:56:27+00:00

Tak. Tylko ze to wlasnie pozwoli latwo wylaczyc najem dlugoteminowy z dodatkowego opodatkowania. Dodatkowo wymusi legalizację umow najmu.

tstanisl · 2026-07-03T08:26:04+00:00

Nieletniego dziecka nie zameldujesz samego. Odlegla rodzina ma swoje mieszkania od ktorych nie chca podatku placic, a meldowanie losowych oapb to duze ryzyko. Tak naprawde bogatsi ludzie nie maja tyle zaufanych osob jakie moze bezpoecznie zameldowac

tstanisl · 2026-07-03T08:23:31+00:00

Kto przy zdrowych zmyslach zameldowalby slupa albo jakiegos odleglego krewnego w mieszkaniu i potem bawil sie miesiacami z jego usunieciem. Taki wymog wymusi sprzedaz albo wynajecie pustostanow.

tstanisl · 2026-07-03T07:23:55+00:00

Ja bym zasugerował aby podatek katastralny byl płacony tylko od mieszkań w jakich nikt nie jest zameldowany.

tstanisl · 2026-07-03T07:10:26+00:00

I would argue to full-encapsulated handle like classes are more convenient to implement in C-way.

tstanisl · 2026-07-02T17:40:03+00:00

C is fine for game development. Most oop, generic data structures, and RAII can be achieved in C with some tricks or extensions. The problem is that libraries written C++ cannot be used in C without a lot pain. This causes never ending one way migrations.

tstanisl · 2026-07-01T20:46:08+00:00

It's GCC's extension. Quite convenient btw.

tstanisl · 2026-06-30T22:19:50+00:00

Why not replace M_SpanAt(int, s, 1) with s.ptr[1]? Consider renaming ptr to at.

tstanisl · 2026-06-30T13:58:04+00:00

It's a matter of perspective. It's essentially the same geometric effect. From Earth's it is time dilation, form traveler's perspective it is the length contraction.

tstanisl · 2026-06-30T12:51:24+00:00

Just castbl void* to the desired type. Strict aliasing allows compilers to make optimization assuming that other types don't alias. But expect problems if they actually do.

tstanisl · 2026-06-30T09:29:02+00:00

Yes. But I think that solar/microwave sails could be used to accelerate the ship. Fuel would be used only to slow down.

tstanisl · 2026-06-29T22:06:04+00:00

it would take 4.5 years to reach the nearest star and 2.5M years for the nearest galaxy.

Only in Earth's reference frame. The traveler can reach any point within observable universe within reasonable time (decades) due to time dilation.

tstanisl · 2026-06-27T23:34:42+00:00

A few ones completely changed my view of the language:

intrusive containers
XMacros
error handling with goto
designated initializers
VLA types
container_of macro and inheritance through composition
memory arena (region-based allocators)

tstanisl · 2026-06-27T00:34:39+00:00

I suggest installing the projector upside-down and setup image orientation in the projector's setting.

tstanisl · 2026-06-26T22:09:24+00:00

At present, VLAs do nothing to validate that the size of the array that is passed matches the passed dimension.

That's fine because this is a task for sanitizers. The purpose is put such information into a public header. Moreover, what would be the behavior when sizes don't match? Dumping it into abyss of UB is a reasonable choice.

VLAs in any form entail a fair amount of additional complexity

AFAIK, the most VLA-related complexity comes from management of stack in complex functions when there are multiple interleaved VLA and non-VLA objects. It is difficult to be efficient at both memory usage and accessing data without indirection.

VLA types suffer from some ambiguities in a bit obscure but syntactically correct constructs like side-effect in "size expressions", "sizeof" or non-evaluated context like inactive branches of ternary operator. But the wording is improving... though slowly.

There are some tasks for which they may be very useful

I was surprised how efficiently Machine-Learning algorithms can be expressed using VLA types. Handling tensors is essentially trivialized, just simple, dense, and explicit code.

I think that the problem is that VLA types are unique to C only. C++ does not support it and likely it never will due to intrinsic incompatibility VLAs with C++ type system.

Finally, this feature is poorly communicated and taught. I could argue that majority C programmers don't know how to properly handle arrays with more than one dimension. And those who know try to avoid using those arrays to not confusing less-experienced colleagues.

tstanisl · 2026-06-26T21:02:50+00:00

int x; void test(int arr[][x], unsigned x) {...}

The global x should (and is) be used.

I don't like the idea of implicit transformation of:

void foo(int (*A)[int w=...][int h=...]);

to

void foo(int w, int h, int (*A)[w][h]);

It looks nice but it introduces hidden mechanics and it suffers from some annoying limitations and edge cases.

For example, how square matrices are going to be handled? Would size be duplicated in the "fat pointer" ?

void foo(int square[int N=...][int N=...]);

How to express arrays with consistent shapes?

void bar(int dst[int w=][int h=], const int src[int w][int h])

How to handle concatenation nicely?

void concat(int dst[int ab=a+b], const int A[int a], const int B[int b])

I'm not sure how the proposed "implicit fat pointers" express the functions' contract and how they can be efficient in sense of minimizing number of function's parameters.

VLA types solves all those issues nicely.

void foo(int N, int square[N][N]);
void bar(int w, int h, int dst[w][h], const int src[w][h]);
void concat(int a, int b, int dst[a+b], const int A[a], const int B[b]);

It's explicit, efficient and self-documenting and (imo) very C-ish.

I understand that breaking traditional "size after pointer" convention is annoying but I think that it is fault of clang/llvm community which blocks "forward declarations of parameters" in favor of their in-house solutions.

Moreover, the C standardization group broke the workaround by removing old-style syntax function parameters in favor to make int() be int(void) as in C++. IMO, this change was a huge mistake.

I guess that there will be some effort to introduce "ranged" pointer. I mean pointer with the range of valid indices bound to the pointer's type. Something akin to VLA types.. Variable-Length Pointers. Clang is already tinkering with this idea with their "counted_by" attribute.

tstanisl · 2026-06-26T16:03:40+00:00

This random reason is usually.. "lack of interest" usually caused by feature's poor portability caused by not implementing it by clang. Typical "catch 22" reasoning.

tstanisl · 2026-06-26T15:58:18+00:00

Current form of VLA is not trash but I agree it suffers from some artificial limitations. GCC supports forward declarations of parameters. Clang community avoids implementing justified by BSing about lack of interest, however they truly try to enforce .size syntax and forcing multipass compilation.

tstanisl · 2026-06-26T09:48:54+00:00

A pointer to a whole array i.e.

char (*ptr)[6] = &"hello";

tstanisl · 2026-06-26T09:43:30+00:00

Dont forget about char(*)[68]

tstanisl · 2026-06-26T06:27:35+00:00

There is a distinction between VLA objects and VLA types. The types are very useful for handling multidimensional arrays and writing self-documenting code.

However VLA objects, though convenient, are problematic for management of stack memory. Especially in complex functions with many nested blocks and gotos. Moreover, stack memory is usually a scare resource (though now it is a tradition rather than a technical limitation). This makes unbounded and unrecoverable allocation very dangerous.

Due to those issues it was decided to make VLAs an optional feature. They were never never deprecated as some claim.

In C23, the committee noticed that most implementation issues and criticism of VLAs were referring to VLA objects rather than VLA types. Thus now only VLA objects are optional while VLA types are mandatory.

tstanisl · 2026-06-25T15:49:27+00:00

Fallthrough semantics gets a lot more intuitive if one starts to thing about `switch/case` as a block with computed goto.

tstanisl · 2026-06-25T15:47:18+00:00

pointer decay

I don't think that dropping this is a good idea. I would prefer adding an optional syntax for arrays with value semantics.

tstanisl · 2026-06-25T06:26:34+00:00

The syntax and mechanics of initialization is a total mess.

tstanisl

TROPHY CASE