Ref: Toni Erdmann - GCC difference in size of 'long
- From: BearItAll <spam@xxxxxxxxxxxxx>
- Date: Thu, 10 Aug 2006 15:03:28 +0100
I was having trouble responding to your post until I realised you have
specified a followup group. I can't even add the suse group on the 'Groups'
line, it produces an error.
It seems unfair to me that the response Must go to the group you have
specified as the followup group instead of all groups that recieved your
post. Anyone finding his post in a search, who find the Suse one first,
will assume you got no replies. It works the other way round too, I had a
feeling I have missed a directive that would have been relevant and if one
of the other responders brings it up then I will miss it unless I join a
group that I don't have an interest in anymore.
It is much more conciderate in my view to allow replies to all groups that
your post went out to.
It did cross my mind that you might have thought that the question wasn't
really relevant to this group, but there are both 32 and 64 bit versions of
Suse in current use so the question is very relevant, particularly as more
users have multiple computers there is a good chance that they will be
split 32 and 64 possibly an old 16 bit machine too.
My Response to "Toni Erdmann - GCC difference in size of 'long dated
2006-08-10 10:43 UTC" question is then :-
It would be poor software if you have to change a globally used .h file in
order to compile it. What will happen with the next piece of software you
fancy trying from a source? Concider yourself told off and punish yourself
with one less Mars bar this week. (I know how important Mars bars are to
programmers).
It is usual to compile for the architecture, otherwise you run the risk of
clashing with the hardware and any libs that you interact with. In reverse,
if you compiled for 8bit ints then try to run on a machine with 4bit
natural ints, then you have data loss problems to concider. You are also
likely to hit boundary problems in arrays or volatiles. A system state
error signal caused by a single misplaced int is particularly hard to find.
But you have macros to restrain the size of the data type. So if your own
software needs the int to be a certain size, then you have the macros
INT_TYPE_SIZE and others for simmilar data type resizing. You can specify
the macros to use for your project as directives or in a file for use with
make. You can also specify the architecture of the target.
It is important though to concider carefully any of your ints that are used
in interaction with the OS and hardware that it is running on even if your
software can cope with potential losses.
For this reason you will often see programmers who have to work on many
platform types build up their own int types. Just by wrapping your ints
inside a class where you specify the size, possibly on the fly. If you do a
quick 'c++ integer class' search you will find examples, some of them
complete classes.
But still, you should compile for the hardware and OS your software will be
running on. If your machines are in touch with each other, then updating
the source across an rsync isn't hard, I have even done it before where
outstations checked nightly with a make dummy run to see if they are
changes, then re-makes the utility if necessary. .
So the answer is, if your software needs the int to be a certain size,
either carefully use one of the macros such as INT_TYPE_SIZE, or more
safely use an int class where you can specify the size used as the
datatype, this is more flexible because you can have anything from a nibble
to 2millionT byte integer (ok, touch of exageration there, but I'm sure I
saw a class of this type some time ago that claimed to be unlimited), but
in all cases compile for the target architecture.
By the way, if you are using one of the GUI's then each one already has
this, for example qt has the Q_INT{size_in_bits}, you can simply treat it
as a datatype and know that it will be correct on each architecture,
provided your software is compiled for that architecture too.
.
- Follow-Ups:
- Re: Ref: Toni Erdmann - GCC difference in size of 'long
- From: Toni Erdmann
- Re: Ref: Toni Erdmann - GCC difference in size of 'long
- Prev by Date: Firefox and mms://
- Next by Date: SLED10 and xgl for Intel 865 g
- Previous by thread: Firefox and mms://
- Next by thread: Re: Ref: Toni Erdmann - GCC difference in size of 'long
- Index(es):
Relevant Pages
|
