Intrinsic Is A Promising, Open-Source, Cross-Platform Vulkan Game Engine

[Xelix]

Using C can help keep a consistent DOP approach. Some of the abstractions that C++ provides are sometimes a really bad thing when considering something like cache misses. The results are usually better than most people anticipate since most don't even give a thought to optimizing to architecture.

A simple optimization to a loop here or there just to stay within a cache line can be the difference in night and day in some cases. C++ just makes this more difficult when you have so many things going on behind the scenes. That's my two cents anyways.

Do you have anything backing this up? Or is it just really your two cents?

C++ gives you a lot of control over the layout of your objects in memory

[tajjada]

IMO it is much better to use C-style C++ rather than C, because C++ has useful features that have absolutely no performance overhead (such as 'auto' type inference, reference types, etc), which could make code more elegant. Just avoid using the expensive C++ features (templates, exceptions, heavily-object-oriented code with lots of inheritance and virtual functions, signals/slots from Boost/Qt, etc) in performance-critical code, and you should be even better off than if you had been writing in C. Nothing wrong with using those features elsewhere in your program to make your life easier. Usually, ~95% of the run time is spent in ~5% of the code, so profile and optimise accordingly. C++ does not force you to use all the features of the language, so adapt your coding style to your use case.

This is the main reason why C++ is my favourite language, personally. It gives you convenience while also allowing you to have fine-grained control over exactly what is happening if you want to. Higher-level languages like Java/Python/Ruby only give you the convenience without the fine control, and C/assembly only give you the fine control without the convenience. C++ is best of both worlds.

[hansg]

Just avoid using the expensive C++ features (templates, exceptions, heavily-object-oriented code with lots of inheritance and virtual functions, signals/slots from Boost/Qt, etc)

Templates have no runtime cost associated with them. They are simply a way to generate code on the fly, much like you do with #defines in C except better integrated with the type system and considerably more powerful. Inheritance also has no runtime cost - you just extend the length of your object in memory. Virtual functions have a small cost overhead, but no larger than the C-equivalent, which is using function pointers.

[tajjada]

Templates have no runtime cost associated with them. They are simply a way to generate code on the fly, much like you do with #defines in C except better integrated with the type system and considerably more powerful. Inheritance also has no runtime cost - you just extend the length of your object in memory. Virtual functions have a small cost overhead, but no larger than the C-equivalent, which is using function pointers.

I understand all of that. I meant that these C++ features make it hard to understand exactly how much code will be generated and what exactly your program will do, which is important if you want to do micro-optimizations for performance. For example, if you create an object in a function, do various operations on it, and then return it to a calling function, it can be quite tedious to determine exactly how many constructors will be called (possibly a lot, because of inheritance, etc), how many copies of the object will be done (which would, again, involve constructor and destructor calls), etc. You need deep knowledge of C++ to understand even seemingly-simple code at this level. Similarly, with templates: it can be difficult to judge how much code will be generated and how it will fit into your program without carefully analysing the code of the template.

So yeah, I probably did not explain myself clearly enough in my previous post. I did not mean to say that simply using these features causes a lot of performance overhead. I meant that they hide a lot of information from you (that information would be more explicit and obvious in C), making it difficult to understand what exactly would happen behind the scenes with each line of code you write, and to judge how exactly the performance would be affected. Again, this is great if you want to simplify your life (you don't have to deal with the gory details, as the language handles it automatically for you behind the scenes), but it is *bad* if you want to micro-optimize performance-critical code, which is what I was talking about. If you are willing to spend the mental effort to analyse exactly how many copies will be done for each object, how many constructors/destructors will be called, what code would be generated by a template, etc ... go ahead.

[Zan Lynx]

C++ is much better than C for writing anything. C++ with good design lets you create solid invariants. Guarantees that you know are true. This lets you avoid confusion about who owns a pointer or if an object is in a usable state or not. And templates are amazingly useful. Their syntax is a bit nasty, but they are still great.

In C to get the same effects you'd need to write some truly ugly preprocessor code. Which people have done, and if you think debugging templates are bad wait until you try debugging a three level nested macro expansion.

Rust is even better than C++.

[groharpon42]

C++ is much better than C for writing anything.
...
Rust is even better than C++.

Ah ok.
And what is the best color ?

[Zan Lynx]

And what is the best color ?

Green with a light touch of blue. Duh.

[ynsta]

The developer moved the license to Apache 2.0:

https://github.com/begla/Intrinsic/commit/53879c0b8cfd7d5d25c0ec9482fefc3f55b1e0b3