Re: Casting null terminated sequence of characters as std::string
On Aug 31, 7:10 pm, Sharad <sharadhona...@gmail.com> wrote:
Hi I work with a another programmer, and noticed something he did
which seemed to work in VC++ but I had suspicions about it's safety
and standards implications. before I rant about it, I wanted to make
sure.
what's wrong with this if at all anything?
char cStr[] = "What's wrong with this";
std::string s = (std::string)cStr;
What's wrong? For starters, there's an explicit cast where none is
needed. Why not the following?
std::string s = "What's wrong with this";
I know there is a conversion like for for cin for passing cStr (which
it may internally convert to a std::string by one of the std::string
constructors or have an overload for char*).
But straight casting like in my example seems somewhat odd, unless the
compiler recognizes and uses a std::string constuctor, otherwise if
just maps the char sequence in memory (either as char[] or char*) to a
std::string class it will obviously not work unkess the first member
of the string class is the the data member and it strip s the null
terminator. but it does seems to work..?
Does the compiler like VC++ convert the char sequence to std::string
when it ses a cast like this? Also if this is dangerous practice, I'd
like to know. (like what if the pgmer forgets to null terminate a char
buffer before casting as a std::string?) And is this standard
compliant.
A a; a's ctor is called
(B)a; I was told should the B's ctor which takes const A& , but what
if a is of type char* and not a proper class, and the rules of
upcasting/downcasting donot apply?
Now, in C++ a C-style cast is equivalent to a static_cast + const_cast
if it would compile, and it is equivalent to a static_cast +
const_cast if a static_cast would fail to compile with an ambiguity
error. Otherwise it is equivalent to a reinterpret_cast + const_cast.
The question then is "will a static_cast do this?". The standard
basically says that "static_cast<T>(e)" is well formed if "T t(e);" is
well formed for some invented variable t. (static_cast considers other
possible conversions, but prefers this one.) std::string has a
constructor which takes a char const*, thus "std::string foo(cStr);"
is well formed, thus the static_cast is well formed. The C-style cast
in the OP's post is equivalent to constructing a temporary std::string
object calling std::string's constructor, then copy constructing "s"
from the unnamed temporary.
Having said that, I try to avoid C-style casts as much as possible. In
this particular case, it works as intended, but c-style casts can
easily hide a reinterpret_cast, which is almost never what you want to
do. Also, the behavior of a C-style cast can change silently depending
on what types are in scope, making it particularly nasty IMO. Ex:
class A;
class B;
A* makeA();
A* a = makeA();
B* b1 = (B*)a; //is equivalent to a reinterpret_cast
class A { short x; };
class foo { float x; };
class B : public foo, public A { int x; };
B* b2 = (B*)a; //is equivalent to a static_cast
b1 and b2 will compare unequal on basically every compiler (except
maybe after optimization if it does whole program optimization and
notices that all 3 'x's are unused). b2 will correctly point to the B
subobject, but b1 will point at garbage due to the effective
reinterpret_cast. Now imagine this situation except where you may
remove a header and leave forward declarations only. The c-style casts
will continue to compile, but they will be equivalent to
reinterpret_cast instead of static_casts, and it will \silently\
break, without compiler error or warning, for any casts with virtual
or multiple inheritance.
Finally and most importantly, in "good" C++ code, there should be
little to no explicit casts of any kind (where I mean the colloquial
definition of explicit, a cast written out explicitly in source code,
not as defined by the C++ standard aka a C-style cast). Required
explicit casting is often the sign of a bad design. (Note the words
"little to no" and "often". Yes: sometimes some casting is required.)
Type safety is your friend, or at least that's one of the beliefs
behind C++, and explicit casts are holes in that safety net known as
type safety.
For example, I rewrote GNU Make myself in C++ (or at least large
portions of it). My source code has 3 static_casts, 2
reinterpret_casts, no const_casts, no dynamic_casts, and I think no C-
style casts. 1 static_cast to use the C threading libraries of windows
and POSIX. 3 static_casts are there just to quiet compiler warnings
about unsigned to signed integer comparisons and integer demotions. 1
reinterpret_cast for a hash on pointers. (Yes I know it's not
portable. 2 equal pointers may reinterpret_cast to 2 unequal
integers.) The last reinterpret_cast is used in a sanity check
comparing a pointer to 0xFEEEFEEE, a a garbage value set by the visual
studios debugger / windows C runtime. ~6600 lines of code.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]