User forums > General (but related to Code::Blocks)
cast and static cast
Michael:
--- Quote from: me22 on December 10, 2005, 09:02:23 am ---static_cast : innocent casts. Derived* to Base*, int to float, etc
--- End quote ---
IMHO, no cast is innocent.
Michael
me22:
--- Quote from: Michael on December 10, 2005, 07:29:00 pm ---IMHO, no cast is innocent.
--- End quote ---
not even static_cast<T*>(0)?
zero matches int overloads or specialisations, so...
Michael:
--- Quote from: me22 on December 10, 2005, 08:03:45 pm ---not even static_cast<T*>(0)?
zero matches int overloads or specialisations, so...
--- End quote ---
Nice :), but useful for?
In the limit of the possible, casts should be avoided. After my experience, the use of casts is soon or late source of errors (most of the time, difficult to detect and debug). Naturally, if they could not be avoided, then there is no choice. But they should be at least limited.
And as BS says:
--- Quote ---...casts really are mostly avoidable in modern C++.
--- End quote ---
Michael
yop:
Since you've brought this topic up let me ask one more thing. How do you handle buffers that the type of them depends on some given data? Say you have a transmition line and you get an array of bytes of a given size and you know that the first x number of bytes will be a general descriptive "header" structure that will describe what kind of data are following. Do you cast? (you'll have to reinterpret the pointer to the first byte to a pointer to a "header" struct and depending on the contents cast the last+1 byte of the header to an appropriate struct) Or do you let's say memcpy from the buffer to a new object of every needed struct? Or is there another way?
BTW I haven't yet figured out why to prefer one way or the other though I use the second one to keep the buffer intact
Michael:
Interesting, but not-easy to answer questions :).
--- Quote from: yop on December 11, 2005, 12:22:27 am ---Since you've brought this topic up let me ask one more thing. How do you handle buffers that the type of them depends on some given data? Say you have a transmition line and you get an array of bytes of a given size and you know that the first x number of bytes will be a general descriptive "header" structure that will describe what kind of data are following. Do you cast? (you'll have to reinterpret the pointer to the first byte to a pointer to a "header" struct and depending on the contents cast the last+1 byte of the header to an appropriate struct)
--- End quote ---
I would say, yes, I would probably cast. Cast, because, I know of which type the x number of bytes is. Anyway, this could be a problem if the code is not sufficiently documented and robust. For example, if I change the format of the stream, then I should change the parsing too. But what will happen, if I have forgotten some bytes?
This remeber me, when I played with an MPEG-4 visual bitstream parser. In such a bitstream, the different elements are represent using specific patterns (start code, length of the element, etc.) and are byte-aligned (theoretically at least). To parse the stream I simply read each element into a char array big enough to hold it (the interesting is that elements are represented using how much bits is required and not one more :)). If the element was a number, I casted it, e.g., to an int.
This article (http://www.codeproject.com/audio/MPEGAudioInfo.asp) about the structure of the MPEG audio frame header could be of some interest (even if I find it too M$ style).
--- Quote from: yop on December 11, 2005, 12:22:27 am ---Or do you let's say memcpy from the buffer to a new object of every needed struct? Or is there another way?
--- End quote ---
Not sure that there is another way. But may be one of my colleagues could have used something different/better. I will inquire :).
--- Quote from: yop on December 11, 2005, 12:22:27 am ---BTW I haven't yet figured out why to prefer one way or the other though I use the second one to keep the buffer intact
--- End quote ---
I think that to chose one way or another mostly depend on the application specifications and somehow on personal preferences.
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version