[morio]

Browsing over the code I'd say it's solid and seems to have been used in production. Just about the right amount of abstraction for practical use.

Some parts could be replaced by standard C++ library functionality by now. My biggest issue so far: Use of bare pointers, especially in parser code. This should not appear in new code written in 2020. I'm kind of baffled by that as he seems to use stuff like std::move.

This is no replacement for either Unreal or Unity for sure, it's pretty basic in functionality.

[phaedrus]

I think "no bare pointers, ever" is overly dogmatic. Raw pointers still have a place, especially in game programming. The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).

[h0l0cube]

> The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).

They also add a level of indirection, which can manifest as cache misses. If you're iterating through large numbers of objects, memory locality can be a huge gain.

[gpderetta]

> They also add a level of indirection,

neither shared_ptr nor unique_ptr add any additional indirection compared to raw pointers.

Of course if you can you should use inline value types, but that's a different thing. The parent was talking about replacing raw pointers with smart pointers (personally I have no particular issue with non-owning raw pointers).

[uluyol]

This isn't a question of smart vs raw pointers, it's a question of pointer vs value. A std::vector<T> is considered good code in modern C++ and should often be preferred over a std::vector<std::unique_ptr<T>>.

[h0l0cube]

> it's a question of pointer vs value

Yeah, the indirection I was referring to generalises to this.

Edit:

You might be saying that STL data structures could have been used by the author to alleviate the memory locality issue, but as noted in another thread, it's common to use custom STL implementations or use entirely custom memory management in performance critical applications, to reduce on memory allocation frequency, memory usage and/or fragmentation. Or maybe the author is just more 133t than thou.

[jonnypotty]

Yeah but I read a thing somewhere that it's bad so I'm gonna tell everyone not to do it cos I'm clever.

[ebj73]

I think it's interesting to look at his code. I have not worked on games myself, but I've understood that most big game studios write their own versions of STL containers, in order to have close control over each and every CPU cycle spent, and in order not to get burnt by changes in the STL, or by slight, or not so slight, variations in performance between different implementations of the STL.

I see that he does the same, keeping his own lightweight string class implementation, for instance, and also his own lightweight smart pointer implementations (Owned and Borrowed). I suspect that he also uses bare pointers and new for similar reasons.

It would be interesting to know if he thinks it is necessary, or if he could have used std::string, std::unique_ptr and std::make_unique instead in this framework.

[jonnypotty]

How do you tell that code has been used in production by browsing it? Game programmers aren't scared of pointers really are they?

Also as stated its not a game engine so why would it be a replacement for unreal or unity?