51–60 of 266 posts
Moderm C++ has a giant lot of features, slowly approaching to eclipsing the number of such in Java.
I don't know how fast they work, how optimisable they are, and how much memory they eat.
Speed is the main quality of a computer program.
Earlier quoted context omitted.
boost::optional was designed to mimic pointers. Before boost::optional, some programmers would return a T* as a caveman's optional . Boost wanted to preserve the syntax of *, ->, and operator bool. Dereferencing a null ptr is UB, so operator* for optional was the same. I agree it would be nice if you could get an assert in operator*. But you can already fire up a debugger or sanitize build and get a nice error messag…
> it would be nice if you could get an assert in operator* If, as you wrote, operator* for an optional that doesn’t contain a value is UB, it can do whatever it wants, including assert. I think the problem is that there’s an implicit requirement that operator* optionals that do contain a value is as fast as a pointer dereference. (Aside: reading https://en.cppreference.com/w/cpp/utility/optional , I wonder how one ca…
I care about speed. Moderm C++ has a giant lot of features, slowly approaching to eclipsing the number of such in Java. I don't know how fast they work, how optimisable they are, and how much memory they eat. Speed is the main quality of a computer program.
I used to write a lot of C++ (like 14 years ago at this point). I haven't really paid any attention to it in that time. I am looking at the code examples and what I see is a language trying to adopt features from Java, Rust and others - but where in those other respective languages there's like just 1 thing going on in a single line of code. In these C++ examples you have the namespacing stuff, templates/generics, im…
What is missed by the authors of all articles of this kind is that, while all of the errors cited are possible, none are tempting.
For example, while it is easy enough to overindex an std::vector, the language provides a "for" statement that exactly walks the vector with no possibility of overrun.
Using an empty std::optional may seem like a danger, but nobody uses one unaware that it might be empty; it needs different syntax to look into than a regular value.
std::string_view and span, similarly, may seem foolishly risky, but they are always safe when passed down a call chain. One does not find them returned from functions in a responsibly designed codebase.
C++ is a box of sharp tools that a responsible engineer can use to make fine, reliable software. We have, today, many, many times more responsible engineers writing good C++ code than we have Rust coders in total.
Work making C++ code safe and reliable thus has a much bigger impact on the world than anything ever done with Rust. That will be true for a long time to come. That is not a reason to avoid Rust, but it is a reason to remain respectful in interaction with those engineers.
UB-invoking dereference in std::optional is such a baffling design choice. The whole point of an optional type is to prevent accidental unchecked access to the value. Sure, sometimes it's useful for performance to skip the check when it's already known-safe from the context, but such dangerous optimization should have been behind a method like `beware_of_the_nasal_demons()`, not an innocent-looking convenience syntax…
Earlier quoted context omitted.
It's funny because I also remembered it as cross-function analysis, but when I went back to grab a link I saw this and thought maybe I'm mistaken somewhere, so I just used this definition. Oh well. Main thing I was just trying to convey was that it's technical terminology.
Yeah that's so bizarre. Is this Alex's slide deck? Did a TA write it? Could it be tremendously old? Weird.
Also, I don't think they're alone in this terminology either... see here: https://www.csd.uwo.ca/~mmorenom/CS447/Lectures/CodeOptimiza...
Those C++ bad, complex, unsafe etc. etc articles are starting to get boring. If one wants to shoot him/herself in a foot it is fine. C++ offers countless possibilities. It (and plethora of libraries) also offers quick way to write sophisticated and performant applications without much fuss. Make your choice. I personally use C++ to great advantage and find it very productive and safe. And while being good programmer…
But if people want to use it and it doesn't affect me, there's a limit to how much energy I'm willing to spend trying to talk them out of it... especially if they are a potential competitor, in which case I might nod encouragingly when I hear they're using it.
Earlier quoted context omitted.
Mission critical software projects, by their nature are started rarely and make very conservative language choices. By its nature, much of it is old, so it's in C++. There's also a fair amount of it in C# and Java, too.
Wasn’t a lot of Facebook’s initial implementation php? I seem to recall they moved off it, or wrote a specialized compiler to speed it up.
My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…
> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…
I'd like to hear Casey's comments on TDD.
*RAII style is lumped together with try/catch, smart pointers, tons of malloc/free new/delete
Earlier quoted context omitted.
> Ideally that should be zero-overhead Optionals are not zero-overhead in any other language. If you aren't going to bother checking the optional, why not just return any old pointer type? The type system should be used to enforce a contract and bypassing checks on that feels like you are just spitting in the fact of the type checker.
> Optionals are not zero-overhead in any other language. That's been true for so many other features in C++ too. > If you aren't going to bother checking the optional, why not just return any old pointer type? Pointers require something to point to. Optionals can embed the value. > The type system should be used to enforce a contract and bypassing checks on that feels like you are just spitting in the fact of the typ…
Plenty of C++ features are zero-cost, not necessarily zero-overhead. To me having an optional without bounds checking is like obtaining a shared_ptr without incrementing it's use_count. It's like arguing that I should increment use_count manually so that copies are "zero-overhead". Sure it's "faster" but the design is still broken and will lead to all sorts of issues.
>Pointers require something to point to. Optionals can embed the value.
So? Just because it embeds a value rather than a pointer doesn't make your program any more correct. If the API designer returned an empty optional and you access it anyways you are still dealing with garbage data.
>And I mean, you could use this logic for everything else. Iterators, arrays, etc. should all have bounds checking too, right? If you want that, there's C#...
Ok? Then lets remove all overhead from the language. Why does shared_ptr increment it's refcount behind my back? No more shared_ptr. This kind of argument without nuance gets you nowhere. Likewise, unlike bounds checks, nothing about std::optional is forced or baked into the language. If you don't want to do null checking, then just don't use std::optional - the fast option is still there and unlike Rust, the fast option is the default.
Optionals are a great tool to eliminate null pointers from a codebase. It's a big enough problem that I would expect an optional type, designed in 2018 to get it right. Allowing automatic dereferencing is an oversight.