[snip]
>>>>>>> std::cout << hex << (int)c ;
>>>>>> C-Style casts?
>>>>>>
>>>>>> surely
>>>>>>
>>>>>> static_cast<int>(c);
>>>>>>
>>>>>> or
>>>>>>
>>>>>> int(c);
>>>>>>
>>>>>> would better still?
>>>>> I wonder why *in this particular case* it would be better. Care
>>>> You made me wonder, so I have to ask:
>>>> Why it wouldn't?
>>> There is no difference, AFAICT. When there is no difference, there
>>> can be no "better" or "worse". Of cousre, I may not know all the
>>> details, so I am asking why it would, to figure out whether I am
>>> missing anything.
>>>
>>> C-style casts are syntactically different from the new forms, but
>>> semantially they are equivalent to the static_cast, the const_cast,
>>> the reinterpret_cast, or some combination thereof, or (sometimes)
>>> to some cast that doesn't exist [legally] in C++. In this particular
>>> case, it's static_cast. Plain and simple. AFAIK, of course.
>> Right here, right now this cast is semantically a static_cast, which
>> is clearly as intended. My concern with this however is with the
>> possibility that not too far down the line this will *silently* become
>> some other cast that was most probably not intended. And it doesn't
>> really take much of a stretch of the imagination to see this happening
>> in the world of templates with a naive developer.
>
> Several assumptions at work. With all due respect, "the possibility"
> (meaning NOT guaranteed), "down the line" (meaning NOT in this code),
> "will become" (meaning NOT yet), "probably" (meaning NOT necessarily
> so), "in the world of templates" (meaning NOT in every program), "naive
> developer" (meaning NOT necessarily the OP), all contribute to the
> word "surely"'s being out of place. *As far as I know* there is no
> difference *whatsoever* between what James has written and what you've
> written for the purposes of printing out the integer value of a char.

> See my point? Any time the suggestion is called for by a software
> engineering principle, like "writing reusable code" or "refactoring
> only when needed", or some such, we should indicate so. comp.lang.c++
Agreed, "surely" sounded somewhat stronger than I initially meant for it to.

> is a technical language newsgroup, and while there are idioms and "best
> practices", their merits are not absolute. And not necessarily a priori
> known to all.
That said, if I'd suggested a solution to another (hypothetical) problem
in another thread that involved using printf/malloc or some other older
C-style approach without apparent reason I'm sure it would have
attracted criticism. This despite the fact the solution could be an
equally valid answer to the OP. Why would C-style casting syntax in this
case be any different than other C-style functions/syntax?

To phrase my central point as a technical language related question
though: "Why aren't C-style casts marked or viewed as deprecated more? -
Aren't they only in the language now to provide compatibility with C
code, not because they add any useful or tangible benefit to modern C++
developers?"

Alan