Does anyone know of an example where C-style cast causes a problem with non-pointer/non-reference types? All of the intentional problems I've tried to cause result in compile-time errors.
Looks like you got ignored, Nypyren.
(split thread) c-style casts
I never use non C-Style casts, the only difference that I know is that C-style casts doesn't respect public/private inheritance, but who cares ^_^ They are much easier to type and read.
const_cast<T*> == (const T*)Is that for reals!?!?!
I have one good reason for favouring C++ style casts. They're way easier to find.
Want to find all the casts in your code base? Search "_cast<". Now tell me how to do that with c style casts.
And quite frankly, anyone who uses "because they're quicker to type" should never be allowed program again.
In a magically "perfect" codebase, you probably wouldn't need to cast. But the real world is messy and imperfect, so of course it happens.
Const allows optimization in some handful of cases, too.
I've only recently found out that this is not really the case, e.g. const methods apparently have no utility to the optimizer. See this talk from Chandler Carruth who's the technical lead of Google's internal C++ team and also leads Google's LLVM team:
For those of you who can't watch the video:
- There isn't a compiler that does aggressive optimization based on const, as there isn't a whole lot that can be done
- There are two cases that can be optimized effectively, but it's very hard to optimize on and the benefits are not what you would expect
- Const methods have no utility to the optimizer
- Const parameters have no utility to the optimizer as they can be const cast away
Re: const. const is not really meant as an aide to the compiler, but to the programmer.
Some have argued that variables should be const by default, and mutability should be explicitly declared.
Yep, I'd be one of those.
static_cast, reinterpret_cast, and const_cast only do what C-style casts do, but require more typing. The extra verbosity is pointless if your variables have sensible names. They aren't exact enough to eliminate the need for a comment where code is doing something really weird. They don't really add any type safety. I honestly can't understand why anybody recommends them over C-style casting.
Oh boy
Const is super handy as a programmer for helping me parse what the heck an API is likely to do.
void Foo(Bar& bar) and void Foo(const Bar& bar), it becomes immediately obvious that the second function, bar is an 'in' parameter, while the first one is both an input and output. And void Foo(Bar& bar) const, tells me that that the method won't modify the original class, so it's most definitely all about modifying bar.
Const allows optimization in some handful of cases, too.
I've only recently found out that this is not really the case, e.g. const methods apparently have no utility to the optimizer. See this talk from Chandler Carruth who's the technical lead of Google's internal C++ team and also leads Google's LLVM team:
For those of you who can't watch the video:
- There isn't a compiler that does aggressive optimization based on const, as there isn't a whole lot that can be done
- There are two cases that can be optimized effectively, but it's very hard to optimize on and the benefits are not what you would expect
- Const methods have no utility to the optimizer
- Const parameters have no utility to the optimizer as they can be const cast away
The only one I know for sure is this:
primitive-typed variables in global (or class/function static) scope -- as long as these variable's values can be known at compile time, they can be treated as if they were literals, enabling optimization of their use. Doesn't apply when they're passed as non-inline function parameters, etc.
The only one I know for sure is this:
primitive-typed variables in global (or class/function static) scope -- as long as these variable's values can be known at compile time, they can be treated as if they were literals, enabling optimization of their use. Doesn't apply when they're passed as non-inline function parameters, etc.
Except this has nothing to do with const.
The compiler can do inlining, constant propagation, common sub-expression elimination, etc. without any hint from the programmer.
You need the newer constexpr in order to have any real semantic effect here (e.g., being able to use constants in contexts that require compile-time evaluation, like non-type template parameters).
Modern C++ const has two real purposes: protection against accidental misuse and marking functions or data as being "probably safe to read concurrently" in a multi-threaded application.
Actually optimizing with constness requires something much closer to Rust's mutability model, which guarantees that you can only have one mutable reference to a value at a time, which eliminates many of the aliasing concerns that severely hampers C++ optimization.
The point of C++ style casts is to specify your intent, so that the compiler can ensure that you're actually asking it to do what you meant to do. If you use C-style casts the compiler won't help you unless what you're writing is actually illegal code.
The way my C++ teacher taught us over a decade ago:
- static_cast<T> = "I know that type is naturally convertible to T."
- reinterpret_cast<T*> = "Yeah, I REALLY meant it."
- (T) = "Convert and shut the f... up!"
Personally, I don't use C++ casts in my code, but I don't have a strong opinion for or against using them: I just don't use them today, and perhaps I will start using them if it bites me in the face tomorrow. I don't really care.
EDIT: But I think having long and annoying to type keywords like reinterpret_cast<T>(...) hinders the use of C++ casts. I know it's supposed to encourage you to write code that does not need casting in the first place but I wonder if it's really working the way the C++ people saw it. If you could do a static cast by writing something like (static int) and I dunno maybe (mutable int) for a const cast I think there would be less lazy C++ programmers out there.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
