I’m not sure why C++ is dismissed in the start. I’d definitely use it for this kind of thing instead of C. It gives you everything C does, plus unique or reference-counted pointers (your trie is probably simpler with std::unique_ptr than in C), destructors, and some acceptable out-of-the-box data structures. std::vector and std::unordered_map alone save a huge amount of time when prototyping relative to C, and if you use them with a using directive then it’s trivial to turn them into another data structure when you move beyond the prototype stage. For this kind of use, iterators and range-based for loops are far less error prone than C pointer arithmetic. Even if you don’t want to use std::string (you may want to have more control over memory allocation), using range-based for loops over std::string_view will give you much more maintainable code than loops over C strings.
For the same reason that Rust, Go, or “Something on the JVM” was dismissed.
The choice was between C, with which the author has plenty of professional experience, and Something Else, which has memory safety and other modern goodies. The author concluded that, in this particular situation, C was a better choice.
If Something Else had been a better choice, presumably Rust would have been chosen. If you have no other constraints, would you choose C++ over Rust for a new project?
[Update: I just re-read that last sentence and realised it sounds a bit combative. It was meant to be a genuine question!]
If Something Else had been a better choice, presumably Rust would have been chosen. If you have no other constraints, would you choose C++ over Rust for a new project?
Rust constrains your data structure design a lot more than C++. You can often just transliterate Python to modern C++ and use exactly the same algorithms, just with a factor of 10+ speedup. There’s also far less of a mature ecosystem of Rust libraries than C++ ones. Both of these make it less useful for prototyping.
Most of us who have used C++ have a love/hate relationship with it. Namely, we love to hate it, and we hate to love it.
That said, I’d still grab C++ over Rust for prototyping work, mainly because I know it better. The exception would be when I want to learn something new about Rust, in which case I’d be choosing to trade off the immediacy of productivity for some other benefit (and the possibility of longer term productivity).
I’m not sure why C++ is dismissed in the start. I’d definitely use it for this kind of thing instead of C. It gives you everything C does, plus unique or reference-counted pointers (your trie is probably simpler with
std::unique_ptrthan in C), destructors, and some acceptable out-of-the-box data structures.std::vectorandstd::unordered_mapalone save a huge amount of time when prototyping relative to C, and if you use them with ausingdirective then it’s trivial to turn them into another data structure when you move beyond the prototype stage. For this kind of use, iterators and range-based for loops are far less error prone than C pointer arithmetic. Even if you don’t want to usestd::string(you may want to have more control over memory allocation), using range-based for loops overstd::string_viewwill give you much more maintainable code than loops over C strings.For the same reason that Rust, Go, or “Something on the JVM” was dismissed.
The choice was between C, with which the author has plenty of professional experience, and Something Else, which has memory safety and other modern goodies. The author concluded that, in this particular situation, C was a better choice.
If Something Else had been a better choice, presumably Rust would have been chosen. If you have no other constraints, would you choose C++ over Rust for a new project?
[Update: I just re-read that last sentence and realised it sounds a bit combative. It was meant to be a genuine question!]
Rust constrains your data structure design a lot more than C++. You can often just transliterate Python to modern C++ and use exactly the same algorithms, just with a factor of 10+ speedup. There’s also far less of a mature ecosystem of Rust libraries than C++ ones. Both of these make it less useful for prototyping.
That’s very true. I remember when C++11 came out with
autoand lambdas: there were loads of blog posts showing Python and the new C++ side-by-side.Most of us who have used C++ have a love/hate relationship with it. Namely, we love to hate it, and we hate to love it.
That said, I’d still grab C++ over Rust for prototyping work, mainly because I know it better. The exception would be when I want to learn something new about Rust, in which case I’d be choosing to trade off the immediacy of productivity for some other benefit (and the possibility of longer term productivity).
If you put the browser up to your ear you can hear the little tiny CVEs mewing in their crib.
Do you get CVEs for prototypes?
Definitely not, because prototypes never ever end up accidentally in production.
I mean, there’s a whole paragraph in the blog post about that.
This basically says “I am working in C because I happen to already know C and not much else.”
Prototype in Python, move critical parts to Python C extension.