Earlier quoted context omitted.
Why would RAII be especially attractive if disabling exceptions?
Probably because exceptions are the biggest source of pain with RAII.
How do you deal with constructors that might fail?
Show HN: Crown – A flexible game engine written from scratch in C++
51–60 of 179 posts
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#52While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp. The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C…
> why isn't there a strict "sane C++" or "orthodox C++" subset available as a custom language or compiler option yet?
Probably because sanity is (1) subjective, (2) in this case doesn't really come from disabling features (restricting language). He is still using most of the C++ features (overloads, operator overloading, templates) but only in semantic context that is obvious for them (i.e. templates for collections, overloaded operators for vectors and matrices). Therefore it might be a little bit hard to create a compiler front end that would understand which class acts as a collection or whether given structure is implementation of well known mathematical concept.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#53Earlier quoted context omitted.
Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to…
> dynamic strings would be isolated to their own pool to avoid fragmenting the heap Strings have arbitrary sizes. How does pooling them together reduce fragmentation? Do they always come and go in groups?
I think it reduces fragmentation in the other pools, not the string pool.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#54Interesting! I'd be interested in better understanding the motivation behind Orthodox C++. In particular, you seem to dump most of the C++ standard library: "Don't use anything from STL that allocates memory, unless you don't care about memory management." I now mostly avoid templatization in my own code unless there's a really good reason. But the standard library often lets me avoid explicit memory allocation. Woul…
I do not use STL because I want consistent implementation across all supported platforms. Also, you have to care about memory management when you need performance or when working with memory constrained devices. The way STL deals with custom allocators makes no sense to me, hence my own implementation. You can find demos in the `samples` folder. :)
Show me a man who thinks STL allocators make complete sense, and I'll show you a man with some serious cognitive issues.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#55If you come to finance, most of the developers love premature templatization, it makes them feel like they know something. Not sure it that can be attributed to their insecurity about C++ coding skills, but it gets really ridiculous at times.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#56Earlier quoted context omitted.
If you disable exceptions hoe do you handle failures in constructors?
Instead of using a constructor you can use a constructor method e.g.: class Foo { public: static std::optional create(); private: Foo(); };
In general if you're not using exceptions, you're not going to be using features that haven't actually been published in a formal standard (optional).
This now means that you can't use any constructors, so how do you have Containers of foo?
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#57Interesting! I'd be interested in better understanding the motivation behind Orthodox C++. In particular, you seem to dump most of the C++ standard library: "Don't use anything from STL that allocates memory, unless you don't care about memory management." I now mostly avoid templatization in my own code unless there's a really good reason. But the standard library often lets me avoid explicit memory allocation. Woul…
Yeah, I'd like to know why you'd still use C++ at all if you find Orthodox C++ appealing. It would seem easier to just write C. Unless I'm missing something (I probably am; don't write enough of either one to have an informed opinion, which is why I'd love to hear more about this).
Sensible usage of templates, operator overloading and namespaces is ok.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#58If you come to finance, most of the developers love premature templatization, it makes them feel like they know something. Not sure it that can be attributed to their insecurity about C++ coding skills, but it gets really ridiculous at times.
I guess they start over each time the requirements change? :)
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#59Earlier quoted context omitted.
Go is a bad choice for game with its unavoidable GC. And Rust is simply too complicated for a person wanting sane C++. D or Nim (or even C!) would make more sense.
> Go is a bad choice for game with its unavoidable GC. Better let the Unreal guys know about it then.
The important difference is that not everything in Unreal is GC'd, only UObjects. Internally the rendering, animation, networking and other high-performance subsystems don't use GC because they can't afford the overhead. Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#60Props for the coding discipline. I couldn't even tell how long it has been since I saw C++ as readable as this.