4
points
SuperV1234
Joined 160 karma
- 2 points
- Note that taking a 'const' by-value parameter is very sensible in some cases, so it is not something that could be detected as a typo by the C++ compiler in general.
- This is not proof. What you said is not incorrect, but it doesn't prove that your software is fast because you applied small optimizations everywhere.
- Level 4: switching to C++
- But do you have actual proof for your first claim? Isn't it possible that the "constant vigilance" is optimizing that ~10% that doesn't really matter in the end?
- > Is it because I made hundreds decisions like that? Yes.
Proof needed. Perhaps your overall program is designed to be fast and avoid silly bottlenecks, and these "hundred decisions" didn't really matter at all.
- This is just not true. There's nothing that makes C++ inherently slow to compile.
PImpl doesn't need to have a performance hit as you can implement it with a local fixed-sized buffer that's not heap-allocated.
You can also design your C++ codebase exactly as you would in C, so there's literally no reason why you'll need to recompile more in one language compared to the other.
- Location: Messina, Italy
Remote: Yes
Willing to relocate: No
Technologies: Modern C++ (C++11/14/17/20/23), and the usual hodgepodge of languages/tools every senior engineer has encountered in ~15 years of real world projects
Résumé/CV: https://romeo.training
Email: mail (at) vittorioromeo.com
---
Hello!
I'm Vittorio, a passionate C++ expert with over a decade of professional and personal experience. My expertise covers library development, high-performance financial backends, game development, open-source contributions, and active participation in ISO C++ standardization.
As the coauthor of "Embracing Modern C++ Safely" and a speaker at over 25 international conferences, I bring real-world insights to empower you fully utilize C++ to its advantage.
I offer specialized training, mentoring, and consulting services to help companies & individuals leverage the full potential of C++.
I am also open to fully remote C++ development/teaching positions.
- This is pretty cool! Could you compare your approach to the one taken in Majsdown?
- Great marketing strategy (that's all it is).
- C++ is not slow to compile. The Standard Library is.
- Most of these features have been used by countless C++ developers for the past decades -- I really don't see the point in adopting a language that's mostly C++ but without some of the warts. Either pick C++ or something like Rust.
- 2 points
- What language are you using? For a small number of objects, it should be completely insignificant to performance to recompute the whole A* algorithm every frame without any form of caching. I'm surprised...
- Why? It's already there and the API doesn't look complicated.
Hi, I'm Vittorio Romeo — a passionate C++ specialist with extensive experience in technical training, high-performance development, game programming, and financial systems.Location: Sicily Remote: Yes Willing to relocate: No Technologies: C++ Résumé/CV: https://romeo.training/ Email: mail (at) vittorioromeo (dot) comI offer one-on-one mentoring, tailored training courses, and consulting services. Visit [romeo.training](https://romeo.training/) for more details.
Currently, I'm dedicating most of my time to a regular client, but my schedule will open up significantly starting in September. I am also available on weekends and outside of regular working hours (Italian time zone).
I'm primarily looking for remote opportunities, so feel free to get in touch if that works for you!
- What you want is 'yield' and generator coroutines. We have them in C++20, but their codegen is very poor compared to a manual implementation.
- I've recently added autobatching to my SFML fork (https://github.com/vittorioromeo/VRSFML/tree/bubble_idle). Drawing multiple objects that use the same RenderStates will now be automatically coalesced into a single draw call, for example:
for (int i = 0; i < 10000; ++i) renderWindow.draw(sf::Sprite{/* ... */});
Upstream SFML: - 10000 draw calls (!) - My fork: 1 draw call
This (opinionated) fork of SFML also supports many other changes:
- Modern OpenGL and first-class support for Emscripten - Batching system to render 500k+ objects in one draw call - New audio API supporting multiple simultaneous devices - Enhanced API safety at compile-time - Flexible design approach over strict OOP principles - Built-in SFML::ImGui module - Lightning fast compilation time - Minimal run-time debug mode overhead - Uses SDL3 instead of bespoke platform-dependent code
It is temporarily named VRSFML (https://github.com/vittorioromeo/VRSFML) until I officially release it.
You can read about the library and its design principles in this article: https://www.vittorioromeo.com/index/blog/vrsfml.html
You can read about the batching system in this article: https://www.vittorioromeo.com/index/blog/vrsfml2.html
You can find the source code here: https://github.com/vittorioromeo/VRSFML
You can try out the interactive demos online in your browser here: https://vittorioromeo.github.io/VRSFML_HTML5_Examples/
The target audience is mostly developers familiar with SFML who are looking for a library very similar in style but offering more power and flexibility. Upstream SFML remains more suitable for complete beginners.
I have used this fork to create and release my second commercial game, BubbleByte. It's open-source (https://github.com/vittorioromeo/VRSFML/tree/bubble_idle) and available now on Steam: https://store.steampowered.com/app/3499760/BubbleByte/
BubbleByte is a laid-back incremental game that mixes clicker, idle, automation, and a hint of tower defense, all inspired by my cat Byte’s fascination with soap bubbles.
A trailer is available here: https://www.youtube.com/watch?v=Db_zp66OHIU
- CMake also needs this, badly...
- Sorry, but I stuggle to see the point or the fun in this.
Having strangers pick a binary choice with zero explanation or chance to provide context doesn't sound useful nor fun for neither the questioner nor the "jury".
You also have no way of ensuring diversity and goodwill of the people answering.
It seems like jumping on the trend of oversimplification for the sake of it. Do we really need to turn forums/Reddit intova Tinder-like yes/no experience?
- This is a great PEP. Very similar to what I wanted to achieve with my P1819 for C++, back in 2019: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...
- 2 points
- 2 points
- 2 points
- 2 points
- > You don't call 'struct_free(obj)' (there isn't even such a function), instead you call 'arena_reset(arena)' once. Stop thinking about individual object lifetimes, start thinking about arenas as 'lifetime buckets' :)
Yes, so you can use RAII for the arena if needed. The problem is not RAII itself, is where it is applied.
And having a manual "arena_reset" function instead of a RAII-based "Arena" abstraction is objectively inferior as anyone could forget to call "arena_reset" while RAII would enforce the clean-up.
- > RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies)
That's not what RAII is at all. You're projecting an extreme use case on the whole feature.
You can use RAII to clean-up the arena at once without forgetting to do so. To manage the lifetime of a socket or mutex. No one is forcing you to go full-OOP individual-allocation design when RAII is available, that's just terrible programming in general.
And this is coming from someone that dislikes exceptions.