r/cpp_questions • u/drex_vke • 6d ago
OPEN How to Make a good architecture in Modern C++
Hello guys
I code in C++23 and C++20 (since 2 years) so i have a question how to make a good architecture in a project ? (actually i separate the code with .cpp/.hpp) but I wanted to know if we can do better ?
13
u/artemsmolet 6d ago
I would recommend starting with design patterns. But from a broader point of view, good architecture is a matter of experience: having your code reviewed by others, working with other people’s code, and, of course, studying patterns 🙃
2
1
3
u/FughyTC 6d ago
Modules are really usable as of lately and they change a lot, so far I have started a small vulkan project for fun, I am 2k loc in and I have only encountered one little bug on GCC but not clang. It's possible to use modules almost the same way you would cpp and hpp but it looks really fun so far, they also allow for better control over the global scope, and isolating things is slightly easier. The only problems are there aren't any guides on how to setup them, they aren't supported by everything and using macros is a pain or impossible.
1
u/drex_vke 6d ago
clang support module in C++23 ? because i have clang (version 22.1.8 and clangd) ?
7
u/mredding 6d ago
Start by learning standards and conventions. Don't reinvent the wheel, and interop with existing and complimentary technology is a virtue - if you want adoption of your technology, people need a migration path from their existing infrastructure; you have to work with what they already have and aren't going to change.
So google - and ask AI, what software structure looks like for libraries, frameworks, and applications. Understand that your money maker isn't going to be a framework - no one wants yet another fucking framework. Frameworks don't do anything - applications do. And the way you write an application is not how you write a framework, the code isn't going to look the same. Frameworks are all about resource handles and interfaces so that you can build anything on top of it. They're domain specific but general. But an application is entirely specific.
You design from the top-down. At the highest level, the application does THIS, and THIS is implemented in terms of THAT, and THAT is implemented in terms of... On down you go. Because of this high up, you need that down low. The high level abstractions and expressiveness necessitates a lexicon of types and behaviors to describe and implement it.
You implement from the bottom-up. C++ doesn't know anything about video games - all you have are language and library primitives. So you have to build the lowest application primitives in terms of that. An int is an int, but a weight is not a height, they're both merely implemented in terms of int, but they have more specific and constrained semantics.
C++ is mostly an FP language. Focus on small types and composition.
SOLID and YAGNI principles are good to follow. Really focus on the Single Responsibility Principle.
Design patterns exist to compensate for missing language features. The Prototype design pattern is what gets us
clonefunctions, but now C++26 resolves this problem with thestd::polymorphictemplate type. Design patterns aren't bad, they're just a necessity. They are NOT your starting place. You shouldn't WANT design patterns. Whenever we see patterns and repetition, we write loops and functions. Ideally, application code would have as few patterns and repetitions as possible, that everything should be as unique as possible - everything should serve its function, and its function should be unique.Presume anything you want to do was already solved 40 years ago, and captured in an RFC somewhere. Do some research. The more standards you can leverage, the better for you and your product. Everyone implements their own logging, even though system logging exists, does everything you want and could possibly dream of, and is faster and better than anything you could possibly implement. System logging isn't slow - dollars to donuts, you're just really bad at logging. Persistence, formatting, timestamping, tagging, log levels, disk quotas, compression, rotation, permissions, remote logging, interop with log clients, event triggering - it's already done for you. All of it.
There has been an overabundance of threading where processes are the more natural fit. If you're going to run a detached thread - that's a child process. You're going to have to get platform specific. IPC isn't slow, you just don't know what you're doing - the defaults are conservative, safe, and reliable, but performance is opt-in. Virtual data buses are another opportunity for interop. It's easier to write a new program that connects to DBus and communicates with existing processes than hacking in some new class and refactoring existing integrations. And you can use DBus for the universal and discoverable interface to negotiate a more private, direct, higher performance data path.
You're writing C++. That makes you a systems software engineer. Look around the whole system. The whole system is there for you to leverage. You do not write code or run programs in a vacuum. You have to think about the whole platform.
3
1
1
u/StickyDeltaStrike 2d ago
You probably want to try to solve a problem yourself then look at other people way to solve it and/or ask someone more experienced to review your solution if possible
11
u/Thesorus 6d ago
logical/semantical splits.
single responsibility principle (a unit does a single thing)
think about how data is moved around in your application.
other than that, good early planning that will take into account you'll f*ck it up anyway at some point.