Someone is reading my mind!
-
I started writing a longer reply, knocking down each of his points, and then i got to this:
Danny wrote:
int n; double d=15.95; int n= static_cast (d); This code will not compile, though.
It won't compile because he's trying to define n twice! The cast is fine, yet he goes on with his contrived example, trying to illustrate the troubles that a programmer trying to silence compiler warnings regarding an implicit conversion (yes, a scenario that doesn't actually require a cast at all!) might encounter. Jackass. I've encountered more bugs related to C-style casts than i care to remember. Stack corruption due to someone trying to remove the
constqualifier but instead ensuring that changes made to a type aren't caught by the compiler... yeah, that's always fun. Scenarios where the original programmer intended to convert a baseclass pointer to that of a derived class but ended up converting between two unrelated types aren't uncommon either. The "newer" casts have a purpose, and if you're using C++ you're best off understanding what that purpose is. :|---- Scripts i’ve known... CPhog 1.7.1.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
And I notice he didn't mention
dynamic_cast, which is there to do something C style casts definitely can't do. If I can quote your own bad self: Jackass. Squared. -
And I notice he didn't mention
dynamic_cast, which is there to do something C style casts definitely can't do. If I can quote your own bad self: Jackass. Squared.Stuart Dootson wrote:
And I notice he didn't mention dynamic_cast, which is there to do something C style casts definitely can't do.
I got the distinct impression that he really didn't have a clue what C-style casts do, much less any desire to learn anything beyond. :rolleyes:
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
I started writing a longer reply, knocking down each of his points, and then i got to this:
Danny wrote:
int n; double d=15.95; int n= static_cast (d); This code will not compile, though.
It won't compile because he's trying to define n twice! The cast is fine, yet he goes on with his contrived example, trying to illustrate the troubles that a programmer trying to silence compiler warnings regarding an implicit conversion (yes, a scenario that doesn't actually require a cast at all!) might encounter. Jackass. I've encountered more bugs related to C-style casts than i care to remember. Stack corruption due to someone trying to remove the
constqualifier but instead ensuring that changes made to a type aren't caught by the compiler... yeah, that's always fun. Scenarios where the original programmer intended to convert a baseclass pointer to that of a derived class but ended up converting between two unrelated types aren't uncommon either. The "newer" casts have a purpose, and if you're using C++ you're best off understanding what that purpose is. :|---- Scripts i’ve known... CPhog 1.7.1.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
It won't compile because he's trying to define n twice! The cast is fine, yet he goes on with his contrived example, trying to illustrate the troubles that a programmer trying to silence compiler warnings regarding an implicit conversion (yes, a scenario that doesn't actually require a cast at all!) might encounter. Jackass.
:laugh: Now that's just funny. What a dummass. I think the new casts were actually invented for this guy!
- S 50 cups of coffee and you know it's on!
-
I started writing a longer reply, knocking down each of his points, and then i got to this:
Danny wrote:
int n; double d=15.95; int n= static_cast (d); This code will not compile, though.
It won't compile because he's trying to define n twice! The cast is fine, yet he goes on with his contrived example, trying to illustrate the troubles that a programmer trying to silence compiler warnings regarding an implicit conversion (yes, a scenario that doesn't actually require a cast at all!) might encounter. Jackass. I've encountered more bugs related to C-style casts than i care to remember. Stack corruption due to someone trying to remove the
constqualifier but instead ensuring that changes made to a type aren't caught by the compiler... yeah, that's always fun. Scenarios where the original programmer intended to convert a baseclass pointer to that of a derived class but ended up converting between two unrelated types aren't uncommon either. The "newer" casts have a purpose, and if you're using C++ you're best off understanding what that purpose is. :|---- Scripts i’ve known... CPhog 1.7.1.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
I've encountered more bugs related to C-style casts than i care to remember.
Casting bugs are probably the least common bugs I've seen. I'm struggling right now to remember the last one I dealt with. The only near candidate from three years ago in ten year old 'C' code doesn't count because the entire function was screwed up due to a stack overrun in a failed condition that had nothing to do with the original developer casting away a const [which was a error and unrelated to the overwrite condition].)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
And I notice he didn't mention
dynamic_cast, which is there to do something C style casts definitely can't do. If I can quote your own bad self: Jackass. Squared.Stuart Dootson wrote:
And I notice he didn't mention dynamic_cast
Noticed that too... forgot to put it in my reply...
-
Shog9 wrote:
I've encountered more bugs related to C-style casts than i care to remember.
Casting bugs are probably the least common bugs I've seen. I'm struggling right now to remember the last one I dealt with. The only near candidate from three years ago in ten year old 'C' code doesn't count because the entire function was screwed up due to a stack overrun in a failed condition that had nothing to do with the original developer casting away a const [which was a error and unrelated to the overwrite condition].)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
Casting bugs are probably the least common bugs I've seen.
Good. I tend to do a lot of maintenance work on a codebase that's had a few more than a few too many cooks over the years, so this sort of careless mistake tends to crop up a lot more than is healthy. It's at least a bit more understandable than the routine operating on a function address instead of its return value... BTW - i had my own issues with the C++ casts when i first learned of them, and i can definitely see complaining that they're a bit verbose. I just didn't think much of that article. :)
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
I swear this guy is reading my mind, only doing a better job expressing my thoughts. (I'm quite sure many CPians will have a cow about this guy's rants; we'll lose a few more when their head explode:).) http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=285&rl=1[^]
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Okay, I hear all these arguments for the new-style casts, but they just provide a false sense of security, right? You can still screw yourself (or others) by using the wrong new style cast operator. Aren't the new cast operators provided to imply intent, and enforce it, based on intent? If you get the intent wrong, well then you're know better off than old school C-style casts, right?
- S 50 cups of coffee and you know it's on!
-
Okay, I hear all these arguments for the new-style casts, but they just provide a false sense of security, right? You can still screw yourself (or others) by using the wrong new style cast operator. Aren't the new cast operators provided to imply intent, and enforce it, based on intent? If you get the intent wrong, well then you're know better off than old school C-style casts, right?
- S 50 cups of coffee and you know it's on!
Steve Echols wrote:
If you get the intent wrong, well then you're know better off than old school C-style casts, right?
:~ If you don't know what you're trying to do, doesn't it come down to luck regardless of what casts you use?
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Steve Echols wrote:
If you get the intent wrong, well then you're know better off than old school C-style casts, right?
:~ If you don't know what you're trying to do, doesn't it come down to luck regardless of what casts you use?
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Exactly. And that's why I said "You still have to know why you're casting and the ramifications of it.", in my response above.
- S 50 cups of coffee and you know it's on!
-
Exactly. And that's why I said "You still have to know why you're casting and the ramifications of it.", in my response above.
- S 50 cups of coffee and you know it's on!
Right. The advantage with the new ones then is that the compiler is less likely to do something you don't intend.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Steve Echols wrote:
If you get the intent wrong, well then you're know better off than old school C-style casts, right?
:~ If you don't know what you're trying to do, doesn't it come down to luck regardless of what casts you use?
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
If you don't know what you're trying to do, doesn't it come down to luck regardless of what casts you use?
I hear they are adding
<lucky_cast>to address just that concern. -- modified at 3:10 Thursday 3rd August, 2006Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Right. The advantage with the new ones then is that the compiler is less likely to do something you don't intend.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Hopefully, when casting in these conditions. :-D I'm not trying to claim right or wrong for the new or old casts, just that you still have to know what you're doing, either way.
- S 50 cups of coffee and you know it's on!
-
Shog9 wrote:
If you don't know what you're trying to do, doesn't it come down to luck regardless of what casts you use?
I hear they are adding
<lucky_cast>to address just that concern. -- modified at 3:10 Thursday 3rd August, 2006Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
:laugh::laugh:
- S 50 cups of coffee and you know it's on!
-
I swear this guy is reading my mind, only doing a better job expressing my thoughts. (I'm quite sure many CPians will have a cow about this guy's rants; we'll lose a few more when their head explode:).) http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=285&rl=1[^]
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
this guy wrote:
Many people still don’t understand what was amiss with C-style cast. Neither do I
Well, I do. After spending 4 days on hunting someone elses C-Style cast mistake through a dozen of class templates, I really do.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
this guy wrote:
Many people still don’t understand what was amiss with C-style cast. Neither do I
Well, I do. After spending 4 days on hunting someone elses C-Style cast mistake through a dozen of class templates, I really do.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistWould a static/reinterpret/dynamic_cast have helped you?
- S 50 cups of coffee and you know it's on!
-
Would a static/reinterpret/dynamic_cast have helped you?
- S 50 cups of coffee and you know it's on!
to be fair: no it was a reinterpret_cast to the wrong class. But still: knowing about why there are different cast operators might have helped the original developer thinking twice. (FWIW The different cast operators are no more than what Raymond Chen would call "developer tax on C++". I hate the syntax, too, but it looks like it was deliberately chosen to allow creating your own cast operators:
template <typename Target> Target * peterchens_cast(void * p) { return (Target *) ((DWORD *)p + *(DWORD *)p); } X * x = peterchens_cast<X>(0); // boom!note the deliberate use of a C style cast to avoid manually escaping the arrowheads.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
I totally agree. Long live C-style casts! The new casts are just pompous. I don't see how the new casts protect you in any way. You still have to know why you're casting and the ramifications of it. Maybe this is why they came up with c#? :-D
- S 50 cups of coffee and you know it's on!
If C style casts were safe, they'd be OK. Unfortunately they simply aren't...by using them you are effectively saying to the compiler "I know exactly what I'm doing" when in most cases you haven't even thought about it. A case in point: in one client's code I've studied I found a pointer to an object (lets call it 'A'), derived from 'B', but accessed via a type 'C' (also derived from 'B') pointer! The only reason it didn't crash was that the only methods accessed belonged to the base class. X| As a result of issues like this, C style casts are banned in all new code here. We use PC-Lint to enforce that restriction rigidly. :rose:
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Okay, I hear all these arguments for the new-style casts, but they just provide a false sense of security, right? You can still screw yourself (or others) by using the wrong new style cast operator. Aren't the new cast operators provided to imply intent, and enforce it, based on intent? If you get the intent wrong, well then you're know better off than old school C-style casts, right?
- S 50 cups of coffee and you know it's on!
Not really. For example, the compiler won't let you use static_cast where reinterpret_cast is required, or vice versa. The only ones that can be interchangeable under certain circumstances are static_cast and dynamic_cast. As a result, the (usually very few) reinterpret_casts stand out in a piece of code, and are likely to be more throughly scrutinised than would be the case if they were C-style casts. :rose:
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Shog9 wrote:
I've encountered more bugs related to C-style casts than i care to remember.
Casting bugs are probably the least common bugs I've seen. I'm struggling right now to remember the last one I dealt with. The only near candidate from three years ago in ten year old 'C' code doesn't count because the entire function was screwed up due to a stack overrun in a failed condition that had nothing to do with the original developer casting away a const [which was a error and unrelated to the overwrite condition].)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
I don't find them that often, but usually when I do they are really nasty little critters. Half the problem is that you have to hunt through all the reasonable examples to find the screwballs. It's far, far easier to just search for the unsafe casts (i.e. reinterpret_cast) to check them specifically. FYI I find variable scoping issues more common (e.g. hiding of an enclosing scope) in client code. Very few compilers warn about such occurrences, but they can cause huge changes in behaviour under the wrong circumstances. We check for both in our new code, along with a whole horde of other issues. Our lint warning policy is very strict, and so far it has paid off. :)
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
If C style casts were safe, they'd be OK. Unfortunately they simply aren't...by using them you are effectively saying to the compiler "I know exactly what I'm doing" when in most cases you haven't even thought about it. A case in point: in one client's code I've studied I found a pointer to an object (lets call it 'A'), derived from 'B', but accessed via a type 'C' (also derived from 'B') pointer! The only reason it didn't crash was that the only methods accessed belonged to the base class. X| As a result of issues like this, C style casts are banned in all new code here. We use PC-Lint to enforce that restriction rigidly. :rose:
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote:
I know exactly what I'm doing"
I do. Thats why I call myself an engineer and charge vast ammounts of money.
Anna-Jayne Metcalfe wrote:
C style casts are banned
Yet more dogma. If anyone cant handle this: serverID = LongEndianSwap(*((PULONG)(&pDHCPpacket->dhcp.options[i+2]))); Then dont write programs.
Truth is the subjection of reality to an individuals perception
