Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Formatting for casts

67 views
Skip to first unread message

Paul N

unread,
Mar 4, 2015, 5:48:48 PM3/4/15
to
I've decided to try to use the C++-style casts. But they look ugly! The best I have managed so far is to add spaces to give:

ti.lpszText = const_cast <LPTSTR> (text);

But this is still ugly, and is difficult to read - the round brackets look like an optional extra instead of being an essential part of the cast. Does anyone have anything better? Or is it the case, as one tutorial seemed to hint, that the casts are deliberately ugly to dissuade people from writing code that uses them?

Thanks.
Paul.

Christopher Pisz

unread,
Mar 4, 2015, 6:03:13 PM3/4/15
to
How is it ugly? Would it be better with blonde hair?

const_cast<wchar_t *>(text); Looks pretty to me and I haven't even drank
that many beers today.

I guess because I am used to templates.

I don't think I'd be casting to LPTSTR though. What's the type of text?
std::string::c_str() might be just fine.


--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

Jens Thoms Toerring

unread,
Mar 4, 2015, 8:01:13 PM3/4/15
to
Paul N <gw7...@aol.com> wrote:
> I've decided to try to use the C++-style casts. But they look ugly!

They're supposed to look ugly! In most cases you don't need casts
and if they are really required this is typically a point in the
code that needs to stand out. So an ugly and easily to find cast
is a rather good idea in my book. In such places something happens
where the author states "I know better than the compiler" - and I
have seen too many places where this wasn't true...

> The best I have managed so far is to add spaces to give:
> ti.lpszText = const_cast <LPTSTR> (text);

That's a typical cast that would raise an eyebrow: why do you
cast away the const-ness of 'text'? Probably there was some
reason why it was declared as constant? By casting away the
const-ness you just opened a hole for a lot of new bugs. So,
instead of trying to hide the cast you should better add a
long comment why this was unavoidable and leave the cast in
in all it's ugliness for you and others to find easily should
anything go wrong!

> But this is still ugly, and is difficult to read - the round brackets look
> like an optional extra instead of being an essential part of the cast. Does
> anyone have anything better? Or is it the case, as one tutorial seemed to
> hint, that the casts are deliberately ugly to dissuade people from writing
> code that uses them?

Well, don't use casts unless they're really required. And if a
cast is needed anyway but it's benign (but you should be absolutely
sure of that, it shouldn't just be something to make the compiler
stop whining) you can still use C-style casts which stand out less
(but don't explain what kind of cast it is):

ti.lpszText = (LPTSTR) text;

But, repeating myself, the ugliness isn't in the cast itself but
in the design (your's or some library's you may have to use) that
requires the cast.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

Robert Wessel

unread,
Mar 4, 2015, 8:21:27 PM3/4/15
to
On Wed, 4 Mar 2015 14:48:29 -0800 (PST), Paul N <gw7...@aol.com>
wrote:

>I've decided to try to use the C++-style casts. But they look ugly! The best I have managed so far is to add spaces to give:
>
>ti.lpszText = const_cast <LPTSTR> (text);
>
>But this is still ugly, and is difficult to read - the round brackets look like an optional extra instead of being an essential part of the cast. Does anyone have anything better? Or is it the case, as one tutorial seemed to hint, that the casts are deliberately ugly to dissuade people from writing code that uses them?


I think if you have enough casts that their ugliness is an issue, you
have far too many, and you need to rethink your design.

Paavo Helde

unread,
Mar 5, 2015, 3:05:27 AM3/5/15
to
Paul N <gw7...@aol.com> wrote in
news:8e1037b8-7fd9-4e12...@googlegroups.com:

> I've decided to try to use the C++-style casts. But they look ugly!
> The best I have managed so far is to add spaces to give:
>
> ti.lpszText = const_cast <LPTSTR> (text);
>
> But this is still ugly, and is difficult to read - the round brackets
> look like an optional extra instead of being an essential part of the
> cast.

This just tells that you have not written enough templated C++ code yet.

> Does anyone have anything better? Or is it the case, as one
> tutorial seemed to hint, that the casts are deliberately ugly to
> dissuade people from writing code that uses them?

This, and they are easier to search in the codebase than the C-style
casts.

You can hide it by wrapping the cast in a suitable function. This example
looks like it is preparing some kind of Windows tooltip structure or
like. In this case the buffer pointed to by the lpszText member may be
modified by the tooltip functions or not, depending on the flags and
usage. It might be a good idea to encapsulate this tooltip setup in a
single function which also contains assert statements checking that the
flags and usage are such that const_cast is indeed benign.

hth
Paavo

Jorgen Grahn

unread,
Mar 7, 2015, 12:49:59 PM3/7/15
to
On Thu, 2015-03-05, Paavo Helde wrote:
> Paul N <gw7...@aol.com> wrote in
> news:8e1037b8-7fd9-4e12...@googlegroups.com:
>
>> I've decided to try to use the C++-style casts. But they look ugly!
>> The best I have managed so far is to add spaces to give:
>>
>> ti.lpszText = const_cast <LPTSTR> (text);
>>
>> But this is still ugly, and is difficult to read - the round brackets
>> look like an optional extra instead of being an essential part of the
>> cast.
>
> This just tells that you have not written enough templated C++ code yet.

In the sense that if you had, you'd see 'const_cast<LPTSTR>' as the
function, and 'text' as the parameter.

For me, C-style casts look uglier nowadays.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
0 new messages