Re: Opinion on coding style.


"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:9v4mm3pcq60gib4672fsrove81h2cplplt@xxxxxxxxxx
On Thu, 20 Dec 2007 15:42:16 -0800, "Leo V"
<LeoV@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

In the case of casting a DWORD to an int, it is done to avoid compiler
warning.

Right you are, I read it wrong. That's a legitimate cast.

In the case of the CString object, it's a bit more complicated why LPCTSTR
is specified
rather than letting the compiler interpret and automatically call the
LPCTSTR operator. But,
I'll just say that it is because we actually use about 3 different string
classes. And, only CString
works well on a Format(...) type statement. The other string classes
cause
a crash if you don't
force an LPCTSTR operator call. So.... for consistency we always cast to
LPCTSTR on
Format(...) type statements, even if the string is a CString (you never
know
when another dev
will come in and replace that CString with std::string or something like
that).

OK, that makes some sense, even though it doesn't apply to the code you
presented. I would still insist on not performing unnecessary casts,
especially C-style and function-style casts. I'd rather see them use
static_cast or even use the weird-looking str.operator LPCTSTR().

BTW, I made a feature request a couple of years ago concerning your
Format(...) issue:

Compiler should warn about passing objects of non-POD types to the
ellipsis
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98899

I don't know if they revisited it for VC2008, but if you're interested,
maybe you can vote on it or add a comment, assuming it lets you, since the
status is "Closed (postponed)". See also what I said about CString in the
"Proposed Solution" section.

Interesting. I was thinking about the possibility of proposing an
operator(...) language extension
so you could define what your class should return when used in a variable
argument list.

But, I definitely like your idea. Although, I don't know if it is valid for
things other than
Format(...). You could write a variable argument list function of your own
that could
take a variable number of class objects in the parm list and that should be
perfectly valid.
Unless there is some cdecl thing going on there that I'm not aware of where
C++ type
constructs aren't valid in variable argument lists.


Yes, there are times when more appropriate style casting happens. A lot
of
this is older code.
I'm was just wondering if I was correct in discouraging casting to base
types using this style:
basetype(othertype) when basetype is not a class.

The two forms are entirely equivalent, so it's really a matter of style. I
personally don't have a problem with int(dwVal), but I don't care much
either way.


Okay. Sounds good. Thanks for your thoughts on it. I'm probably
over-reacting to
my own style preferences. I will continue though to encourage the devs to
use
C++ style casts.

--
Doug Harrison
Visual C++ MVP


.

Relevant Pages

  • Re: Writing unsigned char to std::ostream
    ... I think that we should prefer C++-style casts, as you wrote, but there are ... and we have a CString as input): ... isn't there a CListBox class that gives a seamless ... a slightly more verbose syntax, as long as it works correctly and the ...
    (microsoft.public.vc.language)
  • Re: void and this
    ... > standard of the use of 'void' to indicate a null argument list. ... > then used his bool type in argument lists or structures, ... (Not deprecated IMO means that they will be ... Casts which really do something IMO better be written as C++ style casts. ...
    (comp.lang.cpp)
  • Re: ? Providing an Implicit (?) Cast Overload
    ... CString ThisIsTheQuestion() { ... do you really think those casts are desirable? ... INT age = p.GetAge; ... function overload: operator, but the compiler nags when I try to overload ...
    (microsoft.public.vc.mfc)
  • Re: 2009-2010 in America
    ... Bradley Wilber, on his site..."Met futures," lists many casts and all ...
    (rec.music.opera)