[deleted]
In Defense of C++
291–300 of 470 posts
Re: In Defense of C++
#292Earlier quoted context omitted.
People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…
These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. Howev…
> we shall not forget that all processors are C VMs
This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect
It makes you think it is close which in some sense is even worse
Re: In Defense of C++
#293This reads the same way as any other 'defense', 'sales pitch', or what have you, but from a Rust evangelist. The author likes to use C++ and now he must explain to the world why his decision is okay/correct/good/etc.. If you like it that much, just use the thing; no one actually cares.
As a bonus:
> You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language.
It is incredibly funny how this argument has been used for literally decades, but in reality, you don't see simple, readable, nor maintainable code, instead, most of the C++ code bases out there are an absolute mess.. This argument reminds me of something...
Re: In Defense of C++
#294Stating that you can also write unsafe code in memory safe languages is like saying that you can also die from a car crash while wearing a safety belt. Of course you can, but it is still a much better idea to wear the safety belt rather than not to.
Yet we don't have safety belts on a bus for example.
Re: In Defense of C++
#295Earlier quoted context omitted.
> This is a strength not a weakness Massive cope, there's no excuse for the lack of decent infrastructure. I mean, the C++ committee for years said explicitly that they don't care about infrastructure and build systems, so it's not really surprising.
The reality is that for any moderately complex C++ application, actually compiling C++ code is only a small part of what the build system does.
Well yeah
We have autoconf/automake checking if you're on a big endian PDP8 or if your compiler has support for cutting edge features like "bool"
Re: In Defense of C++
#296I tried to use C++ on a new project and what finally killed me was the IDE. I wanted to use the newest language version, with modules. Visual Studio's autocompletion and jump-to-definition fell apart with modules. This was demoralizing, because I was under the impression that Visual Studio was the best C++ IDE, and if it can't handle language features 4 years after their release, what does that mean? CLion or Emacs+clangd were also a pain. The editing/IDE experience has been much nicer in Rust.
Re: In Defense of C++
#297> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. You know, not sure I even agree with the memory leaks part. If you define a memory leak very narrowly as forgetting to free a pointer, this is correct. But in my experience working with many languages including C/C++, forgotten pointers are almost never the problem. You're gonna be…
C++'s design encourages that kind of allocation "leak" though. The article suggests using smart pointers, so let's take an example from there and mix make_shared with weak_ptr. Congrats, you've now extended the lifetime of the allocation to whatever the lifetime of your weak pointer is. Rc::Weak does the same thing in Rust, but I rarely see anyone use it.
std::weak_ptr is rarely used in C++ too - "I don't care if this thing goes away but still want to keep a reference to it" is just not good design in most cases.
Re: In Defense of C++
#298Earlier quoted context omitted.
that idea that packages and builds belongs to simple problem, large projects need things like more than one laguage and so end up fighting the language
Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs
no they don't - at least not a good answer. It generally amounts to running a different build system and waiting - this destroys parralism and slows the build down.
Re: In Defense of C++
#299Earlier quoted context omitted.
> It really isn't. There's a lot of little nuanced differences that can bite you. These are mostly inconsequential when using code other people write. It is trivial to mix C and C++ object files, and where the differences (in headers) do matter, they can be ifdefed away. > void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit beh…
> you can and should use char[] in both languages Not for temporaries initialized from a string constant. That would create a new array on the stack which is rarely what you want. And for globals this would preclude the the data backing your string from being shared with other instances of the same string (suffix) unless you use non-standard compiler options, which is again undesirable. In modern C++ you probably wan…
Right, I've checked that char foo = "bar"; is indeed the same as the const char variant (both reference a string literal in rodata), which IMO makes it worse.
About string literals, the C23 standard states:
It is unspecified whether these arrays are distinct provided their elements have the appropriate values. If the program attempts to modify such an array, the behavior is undefined.
I assumed you wanted a mutable array of char initializable from a string literal, which is provided by std::string and char[] (depending on usecase).
> In modern C++ you probably want to convert to a string_view asap (ideally using the sv literal suffix)
I know as much
Re: In Defense of C++
#300Earlier quoted context omitted.
std::optional does have dereference checking, but it's a run-time check: std::optional ::value(). Of course, you'll get an exception if the optional is empty, because there's nothing else for the callee to do.
But the dereference operator invokes UB if there is no value. Which is a recurring theme in C++: the default behavior is unsafe (in order to be faster), and there is a method to do the safe thing. Which is exactly the opposite of what it should be.
No, it's the reason people choose C++.