4 ms·
> Let’s try to replace the only STL component we’re still using, std::vector, with a really simple dynamic array - we don’t need resize or push_back in our cod
by entelechy 8y ago
> Let’s try to replace the only STL component we’re still using, std::vector, with a really simple dynamic array - we don’t need resize or push_back in our code, all arrays are initialized with the right size.
Given those requirements, a custom allocator would speed things up. A custom allocator could allocate even on the stack (small buffer optimisation) if possible or use a memory pool.
Embracing C++ features or reading the docs often gives you more than going back to C or reinventing the wheel.
However I think this demonstrates one of the many lurking problems of C++:
It does not enforce the right way of doing things nor makes it easy. Instead it makes the right solution awkward or cumbersome to write.
- jcelerier 8y ago> It does not enforce the right way of doing things nor makes it easy. but what the author is doing here, while being "the right thing" for his own project with specific performance requirements, is absolutely not the right thing to do for the average project that has a few std::vector of 15 widgets, a dozen strings and six and a half pixmaps, or does the occasional web request.
- jblow 8y agoWhy not? How do you know?
- gmueckl 8y agoAs already said, it depends on the type of project. Sometimes performance is key, sometimes implementation time is. It is the old tradeoff between engineering effort spent and the value gained.
- jcelerier 8y agoI know by shipping projects where the -O0 -fsanitize=address performance was enough for the client.
- Asooka 8y agoThat average project would be written in JavaScript, not C++.
- FreezerburnV 8y agoI feel like I've seen people say more than once that you can do things like this to improve the performance of C++ to what you see from this post with the "C with classes" style and reimplementing various bits of the stdlib. However, I don't believe I've ever seen somewhere that demonstrates this capability, and like you said, the "right solution" is not enforced, or is awkward, or hard to discover. What I would legitimately like to see, is something that takes something like what the author was doing, but also uses these features of C++ that seem to be talked about, but harder to find demonstrations of. Especially considering this is a relatively small amount of realistic code, I would love it if someone were to reimplement it using a custom allocator or memory pool or whatever other C++ features are available to get the performance to where it is in what the author wrote (or better?) to act as a kind of tutorial for how to use these things. This is something I'm particularly interested in because I've been learning some C++ again and playing around with writing some stuff with SDL, and would love to be able to incorporate the nice features of C++ into what I'm writing.