473,378 Members | 1,360 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,378 software developers and data experts.

C-style casts for built-in types?

Hi,

I am maintaining a lot of code that is rife with C-style casts. I've
seen a lot of comments that one should not use C-style casts at all. But
I'm wondering what harm there could be in doing so with the built-in types.
For example, if you have a long which needs to be passed to a function as an
unsigned long, or a char* that needs to be passed as an unsigned char*, or
an unsigned int that needs to be passed as a long, isn't it perfectly safe
to use C-style casts just to avoid compilation problems? When we make
release builds, we generally treat warnings as errors, so there's a lot of
casting going on, and it's a lot less typing to say, for example, (given an
unsigned char* aName): (char*)aName than it is to say
static_cast<char*>(aName). One's 12 characters, the other's 25! That's a
lot of extra work, and what for, exactly? What could go wrong with the
C-style cast in simple cases like this? I know reasons for when I'm dealing
with classes, unrelated pointer types, etc., but what about the simple
built-in types...is there *really* any difference?

Thanks,
-Howard

Jul 22 '05 #1
3 1440
Howard wrote:
I am maintaining a lot of code that is rife with C-style casts. I've
seen a lot of comments that one should not use C-style casts at all. But
I'm wondering what harm there could be in doing so with the built-in types.
For example, if you have a long which needs to be passed to a function as an
unsigned long, or a char* that needs to be passed as an unsigned char*, or
an unsigned int that needs to be passed as a long, isn't it perfectly safe
to use C-style casts just to avoid compilation problems? When we make
release builds, we generally treat warnings as errors, so there's a lot of
casting going on, and it's a lot less typing to say, for example, (given an
unsigned char* aName): (char*)aName than it is to say
static_cast<char*>(aName). One's 12 characters, the other's 25! That's a
lot of extra work, and what for, exactly? What could go wrong with the
C-style cast in simple cases like this? I know reasons for when I'm dealing
with classes, unrelated pointer types, etc., but what about the simple
built-in types...is there *really* any difference?


char, unsigned char, signed char, are all the same size and there is
probably no harm in casting one to another. There are, however, some
cases where the result is, well, questionable. What if you have 128
in an unsigned char and try to convert it to a signed char? The latter
cannot represent 128 (usually). What do you have? Implementation-
defined behaviour. IOW, it's not portable because it's may be
different with another compiler. Can you rely on those?

Unsigned int and long _can_ be of the same size. The same problem
exists when converting between those types -- if the unsigned int has
a value that cannot be represented in the long, the behaviour is set
by the implementation and not necessarily the same for all of them.

Now, if you can make sure that all you do is cast between "congenial"
types, then no big deal, use C-style casts. Hell, nobody can tell you
not to use them, it's your system, you're the maintainer, why should
we care? But the whole hoopla about them is based on the premise that
(a) sometimes you can't make sure and (b) it breeds a bad habit.

I'd say, if your primary concern is for wearing out your fingertips
while typing too much, your system is waaaay too simple or its life
span is waaaay too short to talk about.

V
Jul 22 '05 #2

"Howard" <al*****@hotmail.com> wrote in message
news:T2********************@bgtnsc04-news.ops.worldnet.att.net...
Hi,

I am maintaining a lot of code that is rife with C-style casts. I've
seen a lot of comments that one should not use C-style casts at all. But
I'm wondering what harm there could be in doing so with the built-in types. For example, if you have a long which needs to be passed to a function as an unsigned long, or a char* that needs to be passed as an unsigned char*, or
an unsigned int that needs to be passed as a long, isn't it perfectly safe
to use C-style casts just to avoid compilation problems? When we make
release builds, we generally treat warnings as errors, so there's a lot of
casting going on, and it's a lot less typing to say, for example, (given an unsigned char* aName): (char*)aName than it is to say
static_cast<char*>(aName). One's 12 characters, the other's 25! That's a
lot of extra work, and what for, exactly? What could go wrong with the
C-style cast in simple cases like this? I know reasons for when I'm dealing with classes, unrelated pointer types, etc., but what about the simple
built-in types...is there *really* any difference?


I think the main problem arises when you change the types in your program.
When you change types what had been a benign cast can suddenly become
dangerous. With C style casts you get no warning, the cast will happen
anyway. With C++ style casts you get a bit more insurance.

john
Jul 22 '05 #3
"Howard" <al*****@hotmail.com> wrote in message news:T2wLc.296307
I am maintaining a lot of code that is rife with C-style casts. I've
seen a lot of comments that one should not use C-style casts at all. But
I'm wondering what harm there could be in doing so with the built-in types. For example, if you have a long which needs to be passed to a function as an unsigned long, or a char* that needs to be passed as an unsigned char*, or
an unsigned int that needs to be passed as a long, isn't it perfectly safe
to use C-style casts just to avoid compilation problems? When we make
release builds, we generally treat warnings as errors, so there's a lot of
casting going on, and it's a lot less typing to say, for example, (given an unsigned char* aName): (char*)aName than it is to say
static_cast<char*>(aName). One's 12 characters, the other's 25! That's a
lot of extra work, and what for, exactly? What could go wrong with the
C-style cast in simple cases like this? I know reasons for when I'm dealing with classes, unrelated pointer types, etc., but what about the simple
built-in types...is there *really* any difference?


To me, C style casts are fine for any value types: if you have a long which
needs to be passed to a function as an unsigned long, or an unsigned int
that needs to be passed as a long. The C++ casts are generally only for
pointer and reference types: if you have a char* that needs to be passed as
an unsigned char* for which I'd use reinterpret_cast. Use const_cast to
cast away const or reference or pointer types, or in rare cases to add 2nd
level const. Use static_cast to cast from base to derived class, and
various other tasks. Use reinterpret_cast for the rest. The C++ style
casts stand out well and code reviews, and can be searched for by your IDE
or editor.
Jul 22 '05 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Pete Shinners | last post by:
I've been spending the last few night upgrading some 'classic' type objects to the more modern 'newstyle' types. Unless I am not finding some important page, this entire process is almost entirely...
2
by: BJörn Lindqvist | last post by:
A problem I have occured recently is that I want to subclass builtin types. Especially subclassing list is very troublesome to me. But I can't find the right syntax to use. Take for example this...
11
by: Shaun | last post by:
Hi, I'm trying to overload the divide operator in python for basic arithmetic. eg. 10/2 ... no classes involved. I am attempting to redefine operator.__div__ as follows: # my divide...
9
by: Steph | last post by:
Hello, I am searching for the best way to get all base types in framework (int, string, float...). Any idea ? Thanks
17
by: Fabiano Sidler | last post by:
Hi folks! For debugging purposes I tried this: --- snip --- def foo(): pass function = type(foo) class PrintingFunction(function): def __init__(self, func):
6
by: gangesmaster | last post by:
let's start with a question: ========== >>> class z(object): .... def __init__(self): .... self.blah=5 .... >>> class x(object): .... def __init__(self): .... ...
0
by: nejucomo | last post by:
Hi folks, Quick Synopsis: A test script demonstrates a memory leak when I use pythonic extensions of my builtin types, but if I use the builtin types themselves there is no memory leak. ...
20
by: Ari Krupnik | last post by:
scripts can add methods to the prototypes of builtin objects in JaavScript. I can assign functions to String.prototype.*, for instance. I want to add a method to Node, but when I try to execute...
6
by: =?iso-8859-1?q?Erik_Wikstr=F6m?= | last post by:
Is there some way to get a function-pointer to the operators of the builtin types? In the following example I have a generic function which applies an operator on two values, however it does not...
55
by: tonytech08 | last post by:
How valuable is it that class objects behave like built-in types? I appears that the whole "constructor doesn't return a value because they are called by the compiler" thing is to enable...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.