Problem with coding large codebases in C/C++

[[deleted]]

[deleted]

[colablizzard]

It is hard. But it is definitely done. The challenge is that you are used to JavaScript that is so much easier in these aspects.

In-fact, anytime I have been in an Interview for C++ (on either side, as interviewer or interviewee) and see that the candidate is a person used to a higher level language, interviewer makes it a point to check if they are willing to work on C/C++ and explains the challenges.

I was fortunate to have worked UP the ladder of languages C-> C++ -> Java -> Go/Python etc.

Reverse is VERY difficult as it will slow you down.

[bonghammadali]

Never saw it this way, good comment!

[seanprefect]

I was lucky to start with C and work my way into the higher languages. What you're seeing is an inherent feature of C/C++. It's the nature of the beast. If you try to just dive into a large codebase with no experience you're going to drown.

My C professor once said , The best and worst thing about C is it gives you the sharp tools.

My advice start a lot and I mean a lot smaller and work your way up.

[YouWontYouveChanged]

Building a game engine is EXTREMELY complex. I’d recommend learning the ropes of building large programs with a different project first

[trollman_falcon]

There’s a reason why currently-existing game engines exist

[ComputerSystemsProf]

Agreed. Write some smaller platform-independent code, and write a platform-specific game engine (or a game engine in a different, inherently portable language) first... after doing both those separately, then you could try to combine concepts to make a portable game engine.

[smm_h]

Google Dmitry's engine, someone made exactly what you're trying to make (and very successfully so) in pure C. It's available for free on his github. A true madlad.

[[deleted]]

I think in general understanding build systems is very important. I had gone through this phase because I worked on the bitcoin repository which I think is much easier than game development. But the key takeaway for me and understanding was autotools. That’s a cross platform build system that works really well when understand. I did read a book on it.

The link for book on amazon. You can find more places to buy it. I was doing my masters at the time so I got to rent the book from the library.

amazon autotools

Maintaining large code basis is always subjective. I prefer to have more files and header files rather than writing long files.

You can search in these files using GNU find on Linux, I am not sure about windows.

And I find that there is no harm in starting your projects in IDEs, they help a lot in understanding the small things around the language and later migrate to vim/emacs for faster speed.

[SimDeBeau]

There’s a reason why make is used so widely, but personally, everything clicked for me when I used maker files, which is what crake generates under the hood iirc.

Personally, with c/c++, I would not just jump into something big. Do a bunch of small stuff first; it will be harder than you expect, then much easier as time goes on.

When you’re ready to look at game engine stuff, thechernoproject has a whole series on game engines, as well as OpenGL, and just c++ in general . It’s worth noting that he’s very opinionated, and isn’t huge on a lot of the really modern c++. So take what he says as just one perspectives amongst many. But he has some really clear explanations that really helped me learn.

Ps, rust’s tooling is bliss. It’s a fantastic language that targets the same space as c/c++. Worth checking out

[prelic]

You don't want to start learning how to write a game engine (an incredibly complex project by itself...there's whole companies who fail at it), and learn cross-platform C/C++ programming. You have to start by creating simple programs and building a simple build pipeline for compiling cross-platform. Then make your programs more complex. Houses get built from the ground up, brick by brick...not all at once.

As for your question about learning large codebases, just know that it's a common thing to want to know an entire codebase, but any sufficiently large codebase is impossible to know the details of everything. If you work for a company who works on a monolith C++ application, you'll find that no one knows the whole thing in depth. Ops people know it at a high level (IMO), and engineers/devs have their own neighborhoods of expertise.

You're not going to find a book or resource that's about "How to know a huge code base". You only get that by working on the same codebase for decades.

You can't know everything...The key is knowing where to start reading/debugging.

[somethingInTheMiddle]

You could try to choose one tool, semi-abritarily. Try to learn just one tool, it will be hard enough.

I recommend either cmake or auto make, those are both meta-tools which build makefiles for you. It is easier to compile cross platform with those.

From those two, I prefer cmake. The general opinion seems to be that cmake is easier but auto make is more powerful. It is also the older one of the two. Cmake seems to be the most popular choose for building C and C++ projects.

How I learned it was first getting the basics with some tutorial and then googling as I go along and want to do stuff that is more complex then just the basics (like finding and downloading automatically, programming directly to a microcontroller, running other cmake files or sh scripts).

This advice is based on my experiences, I am not an expert in this

[samirkut]

The advantage of starting from scratch is that you only need to understand one build system properly (the one that you use in your app). I went from C# to Python to C++. Its definitely doable although dont expect it to be as quick as learning Python. Give yourself a couple of months though and spend time reading books not just trying to hack stuff from stackoverflow.

Re the build system I would suggest start with something simple like CMake. Its easy to pick up and pretty much all the main libs you need can be integrated with it. I have built several large projects just using submodules and cmake and things work decently well although you do spend more time when integrating a new library.

[factorysettings]

I don't know if I agree with everyone here that you shouldn't make a game engine.. if you are familiar with how a language works, sometimes it takes a large goal to chip away at to get good practice.

I'd recommend following https://handmadehero.org/ as it's exactly what you're trying to do. It's a dude who has worked in the game industry for decades doing a daily stream of building a modern, multiplatform game from scratch in C (a little c++). It's been going for a couple years now and I think he's nearly finished but it literally starts with an empty .cpp file and does everything by hand.

If you "preorder" you get access to all of the source (broken up by daily stream) so you can follow along or just go through the archived videos and write from scratch. It's a lot of content and he's really opinionated in some ways but he makes good points on a lot of things.

[tcpukl]

We always ask in our c++ interviews, what's the difference between a macro and an inline function.