3 ms·
In my last job I worked in a code base like this for a large AAA game with an idtech legacy. It was even more extreme than orthodox C++ in that it was basically
by Impossible 10y ago
In my last job I worked in a code base like this for a large AAA game with an idtech legacy. It was even more extreme than orthodox C++ in that it was basically C in runtime code (tools code used some late 90s style C++ with STL vectors, maps and classes) with a few C++ features sprinkled in for convenience or performance. We could use non-allocating STL algorithms stuff, for example I used std::sort pretty heavily, but classes were rare and memory management was carefully controlled. Way more restrictively than a simple STL container ban, everything was statically allocated or allocated at load time with memory requirements determined at (asset\level) compile time. Modern console development makes it impossible (or at least really hard) to not allocate some memory at runtime or avoid certain modern C++ idioms. There were VMs for scripted gameplay and UI code, which allocated memory and ran GC but those operated in their own, limited, sand-boxed arenas.
In some ways this style was limiting, but in other ways it was refreshing coming from previous jobs where I was working with C++ loving developers, including just myself in an indie code base I'd written that was too C++-y for its own good. Sometimes, keeping the rules of the language in my head, writing "proper C++" and dealing with random gotchas was a big cognitive load. Writing simpler, almost C style code and focusing on data layout and transformation instead of class hierarchies and C++ syntax made me a better, more productive developer.
I also completely bombed an interview after working at this job for 4 years when I had a typo in assignment operator syntax (very embarrassing) and couldn't remember modern C++ syntax which I had read about but never used in a production environment (move semantics, didn't know shared_ptr needed a default delete for char[]), so I guess you win some and you lose some.
- HelloNurse 10y agoMost recent C++ changes either facilitate extermination of "random gotchas" (for example simplifying constructors and initializers) or are innocuous additions; what are the harmful "modern C++ idioms" you struggled with? How could "almost C style code" be simpler than taking advantage of a richer syntax backed, at last, by nice semantics?
- Impossible 10y agoI think modern C++ features are great and pushed to incorporate many of the features you're talking about as console compilers (slightly behind versions of clang, gcc and msvc) were upgraded to support them.
- munchbunny 10y agoThe restrictive style can be very liberating because the convention minimizes unintended side effects. C++ has a ton of unintended side effects that come from interactions between language features. Copy and move semantics combined with heap allocations and STL container copy/move behaviors can get you into weird places and behaviors if you use them too liberally.
- qwertyuiop924 10y ago>for a large AAA game with an idtech legacy. Yep. That would explain it. From your description, sounds like an idtech 3 lineage (CoD, perhaps? I'd keep guessing, but idtech 3 was so heavily licensed that it honestly could be anything). It certainly wasn't idtech 4, which I think used a bit more C++ than you describe inside the engine itself.
- shinymark 10y agoCoD seems highly likely. I can't think of any other idtech 3 engine descendant that is still going in year 2010+.
- Impossible 10y agoIt was a version of the COD engine.
- jandrese 10y agoIMHO, one of the costs we don't think enough about is maintenance on these software projects. If you have taken the time to learn all of these great frameworks and techniques, that's great, but it increases the cost of the person who comes after you and has to also learn all of those technologies before they can maintain your code. There is a wisdom that you should never re-implement something that a library exists for, but IMHO a strict interpretation of that view leads to horrendously bloated projects that are nearly impossible to build and maintain. I see this sometimes in node projects where the developers will pull in half a dozen dependencies before they even consider writing a for loop.