For me, it was when I discovered how dynamic linking (.dll, .so) works, and why a linker is needed to run even a simple "Hello world!".

I've spent a lot of time messing around with C, having struggled with object-oriented programming (due to not really knowing how best to structure things, not knowing when to apply certain design patterns).

When writing C code, I'd write OOP-esque code (pass around a struct to routines to do things with it) and enjoyed just making things happen without having to think too much about the overall design. But then I'd crave being able to use namespaces, and think about how the code would be tidier if I used exceptions instead of having every routine return an error code...

Working with Python and Node over the past couple of years has allowed me to easily get into OOP (no separate declaration/definition, loose typing etc.) and from that I've made some fairly good design decisions. I'd implemented a few design patterns without even realising which patterns they were - later reading up on them and thinking "hey, that's what I used earlier!"

I've also had a bit of an obsession with small executable files - using templates and other features of C++ add some bloat (on Windows at least) compared to C. There were other gripes I had with C++, mostly to do with making things modular (dynamic linking etc.) but really it's irrelevant/unreasonable.

And yes, for someone who doesn't like code bloat, working with Node is somewhat ironic... (hello, node_modules...)

So today I decided to revisit C++ and dust off my old copy of C++ in a Nutshell, and try to see if I could write some code to do things that I struggled with before. One nice thing is that this book was printed in 2003, yet all of its content is still relevant. Of course, there are newer C++ standards, but I can happily just hack away and avoid using anything that has been deprecated.

One thing I've always avoided is dynamic_cast because every time I read about it, I read that "it's slow". So I just tried to work around it when really if it's the right tool for the job, I might as well use it... It's really useful!

Anyway, now I've typed all this positivity about C++ I will probably find a little later on that I hit a wall with what I'm doing and give up again... :p

@12bitfloat Serious debate on Rust vs C here are my arguments; C has :

1. Better Syntax
2. Betetr Performance (Compile and runtime)
3. Direct Hardware Access (No strict rules)
4. Lots of codebases use `unsafe` in rs
5. No Borrow Checker Frustrations
6. Established Ecosystem
7. More Control Over Memory
8. Easier to Port & Embed
9. No Heavy Standard Library
10. EASY Manual memory management (that's a pro)
11. Optimal inline assembly
12. Memory-mapped I/O (simpler pointer math)
13. No fat pointers ( slices)
14. Better control over ABI
15. Lighter executables
16. Simple linking (no cargo)
17. Cargo forces u to use GitHub
18. More compiler choices (GCC, Clang, TinyCC, MSVC, ICC, etc)
19. More debugging tools (GDB, Valgrind)
20. Cross-compilation is easier (and there's Zig support)
21. Easier to distribute AND RUN ON WINDOWS
22. Better for baremetal (Rust needs a custom runtime for truly bare-metal execution)
23. Compatible with legacy systems (Rust is too heavy to support some old architectures)
24. Better for microcontroller (no_std/std)
25. Supports every OS(sunOS, solaris, obscure BSDs)
26. No forced updates (cargo updates takes a year and installs I36579+E package)
27. Less strict versioning (new standard broke my old code)
28. Less restrictive aliasing
29. Flexible pointer types (ever heard of Box<T>)
30. No unwarranted type safety (Sometimes you just need a void*)
31. C99 flexible arrays
32. Anonymous structs/unions (less boilerplate than enums)
33. C macros are simpler (please help me rusts' require a mini language at this point)
34. No strict mutability rules
35. Better for hacking/debugging (poke around memory)
36. Better C++ interop (C++ sucks)
37. More lib-friendly (almosts every lib has C bindings)
38. Can use void pointers (void*)
39. Better for writing shared libraries (Rust’s dynamic linking is more complex)
40. No automatic drop semantics (Rust’s Drop trait can introduce performance issues)
41. No forced monomorphization that causes binary bloat
42. Better for real-time applications (No automatic memory management surprises)

MENTION : I'm not clashing or anything, not against the person I'd like to debate with, @12bitfloat, but against the argument (RUST>C)
It's not a war

Statically linking to qt5 is quickly driving me fucking insane.

I've a list of unresolved dependencies during linking longer than a really long fucking list. Ugh.

Cmake, why can't you save me?

Think I'll just go back to dynamic and build on each needed system.

it puts the binding redirect in the app.config
or else it gets the FileNotFoundException again

Linking problems are really fun... Like using gdb in the dark on incompatible exec or without debug symbols:
You change the order of the libraries or switch to dynamic linking for one of them and suddenly it works