Hacker Newsnew | past | comments | ask | show | jobs | submit | more sharedptr's commentslogin

I use C at work and in the past for hobby projects C++ (11) to do some modifications to Quake 3.

Is C++20 support in compilers already? MSVC/GCC/Clang


MSVC has a good amount of C++20 support now https://en.cppreference.com/w/cpp/compiler_support#cpp20.


Not fully, but the important pieces yes. Clang and GCC in particular, not sure about MSVC as I don't use it.


I mostly use C when I need to speed up some bits in our codebase; and I have no chance to ask people really working in C++/Rust which can give help me decide; the people I know use C++ for games or QT. The ones I know that touched Rust gave up after 1.5 weeks.

As you say I wanted to know how's the scene at the moment; I am very disconnected from how they have both evolved and their future (mostly because what I see is hate to C++)


I learnt it at university back then, but I had already toyed with C++11 so I always made puns and called what they were teaching C--. Essentially they were teaching a very old version and the evaluation machines ignored all the "modern" bits back then.

My idea is to either C++20 (not sure if there is a resource to learn directly from C++20 or if there are compilers supporting it) or Rust, personally I would go for C++ seeing as there's a wider ecosystem and tools out there, lots of libraries (which are a bit of a pain to use sometimes) and it is almost anywhere.

But to be fair, I am out of the loop of C++/Rust and what I see in my internet circles is Rust > C++ mostly because of the memory safety; which makes me wonder if it is worth or not; also lots of C++ hate which reminds me of PHP.

I just have a hard time making decisions.


By the end of the day your employer will decide which language/version is to be used on a project, so you should check with your employer. That said, even C++98/03 is well an alive; as a consultant I still see a lot of industry projects using C++98/03, some with a few elements of C++11; I rarely see C++17 and never see Rust projects.


Honestly my main short-time goal is to write performant applications, I have some processes in mind that would work way better if I could manage memory instead.

At the moment I just write bits in C whenever I need it but when it scales in a decent size I would just write the whole thing in C++/Rust


With C++ realistically memory management is so hard that if you want to go solo, and you don't want to debug segfaults all the time, Rust is definitely the way to go. It teaches you manual memory management like nothing else.


Unless you're manually implementing data structures or something similar you basically never need to manage your memory manually in modern C++. std::vector takes care of most your needs and smart pointers exist for the few cases where it doesn't. There's not really a lot of difference to Rust there except that OOB access is a panic in Rust and (most likely) a segfault in C++ but you can trivially enable that checking by putting the STL in debug mode.

C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.


It's entirely possible to invoke memory unsafety in modern C++.

    std::vector<int> v {1, 2, 3};
    int& x = something(v);
    something_else(std::move(v));
    x = 42;
Is this UB? Impossible to tell without examining the code of the functions involved!


Nobody said it's impossible, it's just generally not an issue if you write normal code (read: stop treating C++ as C, they are completely different languages). There's only very little difference in how much you need to think about lifetimes and stuff between Rust and modern C++, it's far from being "hard". Sure Rust holds your hands a bit more in those regards but you can also just turn on address sanitizer and friends and then you have a very similar experience.


I took an Earley parser library written in Java and ported it to C++ with just using smart pointers everywhere for memory management and it Just Works™. Like magic really as I can’t recall having to hunt down any segfaults and I spent a bunch of time debugging that thing because porting from Java wasn’t really a copy paste operation especially since I never mess with Java so don’t know the standard library stuff.


> With C++ realistically memory management is so hard

Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?


Problems with memory management are a fading memory when coding modern C++.

All the things Rust advocates insist cannot be done safely in C++ are now trivial. Use-after-free, leaks, buffer overruns, what-have-you, no longer need any attention to avoid if you stick to modern C++. Some people insist on coding as if it were C, and bring along all of C's failings. Leave them behind.


Unfortunely, only when working solo, or with a team that really embraces security.

Those people that insist on coding as if it were C are still a very big group across the industry.


The problem is that it's too late to add linear typing to C++ at this point and get rid of all other types. So I would say yes.


Is there something like this for C/C++?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: