Re: Why are fundamental type sizes not exactly specified? - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Re: Why are fundamental type sizes not exactly specified?
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

Steven T. Hatton
Guest

Posted: Thu Apr 01, 2004 7:19 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

James Kuyper wrote:

Quote:

hattons (AT) globalsymmetry (DOT) com ("Steven T. Hatton") wrote in message

not trying to be difficult, but to some extent you beg the question. When
am
I going to really care that I'm using the natural integer type for the
hardware?

The vast majority of the time, that's precisely what you will want.
You seldom want the system wasting a lot of time emulating int16_t on
a 32-bit platform by bit-masking, or emulating int32_t on a 16 bit
platform with expensive double-word operations, unless you have some
very specific need for precisely those bit sizes. Most of the time
what you will want is 'int', which will be 32 bits on the 32 bit
platform, and 16 bits on the 16 bit platform.

Typically I expect most programmers have a fair sense of their target
platform(s), and could chose appropriate sizes to match the targets. OTOH,
if there really is a need to adjust from one platform to another, it seems
a typedef would work. What kind of empirical evidence is available to show
the impact of masking on performance? How is char handled in a typical
implementation?

Quote:

..
That's not true if you insert the appropriate checks for overflow,
which you would need to do anyway if you're running close to the
limits.

But now I need to know if I'm running close to the limit on every
possible hardware the program might be ported to. Since the limit on a 32
bit

Which is trivial: just compare with the *_MAX macros, and familiarize
yourself with the minimum values for those macros.

Yes, I'm sure it's all trivial in comparison to what I know now. I have
well over a decade of systems administration experience. But that wasn't
the case when I started my Computer Science program. Imagine a student
takes a C++ course where the professor lectures for half an hour describing
the C++ fundamental datatype specification, and then half an hour
describing the consequences of getting it wrong. Mind you, in my case,
getting it wrong on my previous job meant getting killed. When I said I
worked with equipment the generated 36,000 volts, I meant that I actually
went into the cabinets and replaced the parts which produced that
potential. This was not an office job.

At that time there were few viable alternatives to C/C++, but the
uncertainty that placed in my mind was discouraging. I know I'm not alone
in having such misgivings. Many people making decisions regarding what
programming language to chose for a particular task have the same doubts.
When they look at another language and see clearly specified data types
they feel more confident.

Quote:

That is _if_ I foresee the potential problem.

I can't improve your foresight; neither can the language.

No, but it is conceivable the language could obviate the need to consider
such matters.

Quote:

..
Can you provide a specific example of how a program might be adversely
affected by exactly specifying the size of data types? I don't believe
the

See above, where I use the word "emulate".

I mean something along the lines of actual benchmarks. Sure, I want my
programs to run as fast as possible. I'm probably more likely to care
about such things than 95% of all programmers. I tend to do a lot of
things that require heavy number crunching, such as 3D graphics involving
finite element approaches to deformable continue.

Quote:

C++ Standard specifies anything related to 'fastest' integer type. I'm
also not sure what fast and slow are in this context. Can you provide an
example of an integer type that would be slower on one machine than on
another simply due to size?

Yes. Any type that has to be emulated by bit-masking or double-word
operations is generally going to be slower than a type that can be
implemented directly by the hardware.

I am really interested in scientific measurement.

My concern is with the psychological effect these matters have on language
acceptance, as well as the potential for serious adverse consequences
resulting from miscalculation. If NASA can mangage to lose a spaceprobe
because one team used SI to do their computations and the other used the
archaic system, it is certainly possible more subtle mistakes can be made.

It's difficult for me to quantify the cost of such things, but the arguments
about performance being adversely affected by masking integer data types
should be fairly easy to asses, at least for restricted cases. Has anybody
ever done anything but handwaving when making these decisions? Do you want
to be the person the world points to when NASA loses a manned spaceship
because of an oversite in porting a program which could have been avoided
by taking a different approach to language design? I honestly don't know
what the risks are, nor do I know what the performance costs are likely to
be. I /do/ believe there are risks involved, and I haven't seen any real
research on the subject.

If that research has been conducted, and people have consulted it when
making these decision, then I would like to know.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Pete Becker
Guest

Posted: Sun Apr 04, 2004 12:14 am Post subject: Re: Why are fundamental type sizes not exactly specified?

"Steven T. Hatton" wrote:

Quote:

But now I need to know if I'm running close to the limit on every possible
hardware the program might be ported to. Since the limit on a 32 bit
counter is significantly different from a 16 bit counter, being close to
the limit is not a clearly defined concept in my mind.

#define MAX_REPS /* whatever */
typedef int counter;
#if INT_MAX < MAX_REPS
#error bad assumption about int size
#endif

Quote:

The only difference is that you need to #include and compare versus INT_MAX, rather than having a fixed value to
compare against that's the same on all implementations.

That is _if_ I foresee the potential problem.

Yup. That's your job.

Quote:

Can you provide a specific example of how a program might be adversely
affected by exactly specifying the size of data types?

I gave the example earlier of the Java requirements on floating point
types: they're horrendously slow on Intel processors, because they don't
match the native mode of the CPU.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Pete Becker
Guest

Posted: Sun Apr 04, 2004 12:15 am Post subject: Re: Why are fundamental type sizes not exactly specified?

"Steven T. Hatton" wrote:

Quote:

I would
really like to know if people do have objections to standardizing the
fundamental types based on powers of 2.

They are standardized based on powers of 2. unsigned char must be able
to represent values in the range [0,2^ Cool

. unsigned short and unsigned
int must be able to represent values in the range [0,2^16). unsigned
long must be able to represent values in the range [0,2^32).
Implementations are permitted to represent larger ranges, but if you
want to write portable code you stick to the standardized ranges.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Pete Becker
Guest

Posted: Sun Apr 04, 2004 5:23 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

"Steven T. Hatton" wrote:

Quote:

The disadvantage is not knowing what a variable might do on a particular
platform. For example, I might use a particular size numerical type on one
machine where doesn't overflow when used as a loop counter, thus behaving
as expected. When the program is ported to a machine with a smaller size
defined for the same typename, the same variable might overflow
unpredictably

That is, if you don't write portable code, then your code is not
portable. <g> The answer is to be aware of the minimum sizes of the
fundamental types in C and C++, and to write code that works correctly
with those sizes.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Pete Becker
Guest

Posted: Mon Apr 05, 2004 6:32 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

"Steven T. Hatton" wrote:

Quote:

Why are fundamental type sizes not exactly specified?

This was explained to me in my first programming courses many years ago.
The explanation was something like: 'not all hardware supports the same
size fundamental data storage unit'. Usually followed by the professor
mumbling something unintelligible.

Other than the last sentence, that's correct. The goal of C and C++ is
to make it easier to write robust, fast code.

Quote:

It seems to me, in today's world, technology is sufficiently advanced to
support a layer of abstraction which would provide a mapping between any
specified size of data type and the physical storage units.

It certainly could be done. Indeed, Java imposes exact requirements on
all fundamental types, and the result is that floating point math on
Intel systems is horrendously slow, because the required semantics don't
match the hardware.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

James Kuyper
Guest

Posted: Tue Apr 06, 2004 7:00 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

[email]hattons (AT) globalsymmetry (DOT) com[/email] ("Steven T. Hatton") wrote in message news:<UqGdnTeIj_hY9fHdRVn-sA (AT) speakeasy (DOT) net>...

Quote:

James Kuyper wrote:

[email]hattons (AT) globalsymmetry (DOT) com[/email] ("Steven T. Hatton") wrote in message
...
Typically I expect most programmers have a fair sense of their target
platform(s), and could chose appropriate sizes to match the targets. OTOH,

Then you're not talking about portable code, in which the size of
'int' is constant - that constant value is defined by the implementors
for that platform, rather than by the standard, but it is constant for
that platform.

Quote:

if there really is a need to adjust from one platform to another, it seems
a typedef would work. ...

That's precisely what the new size-named types in <stdint.h> for C99
are. They're a better solution than the original type names, but the
originals still need to be retained for backward compatibility.

...

Quote:

That is _if_ I foresee the potential problem.

I can't improve your foresight; neither can the language.

No, but it is conceivable the language could obviate the need to consider
such matters.

You can concieve it, but you'd be wrong. The correct handling of
overly-large values is always context-dependent; for many applications
it doesn't even need to be thought of.

Quote:

Can you provide a specific example of how a program might be adversely
affected by exactly specifying the size of data types? I don't believe
the
See above, where I use the word "emulate".

I mean something along the lines of actual benchmarks.

Benchmarks are always platform-dependent. If you can accept a
platform-dependent answer to your question, then 'int' is fixed for
that platform, and the problem you're worrying about disappears. The
size of 'int' is variable only in the context of the need to port code
to multiple platforms.

If you need to know precisely which type is fastest, and by how much,
you'll need to consider changing data types for each platform that you
port it to, no matter what the standard promises about the different
data types. The interactions can get complicated: a larger data type
might process faster because it's the natural word size for the
platform, yet still end up slowing the program down overall, because
it requires more space in memory or on disk.

You can use 'int' if you're not going to re-write for each platform,
but only if the vague promise that 'int' is the natural type for each
platform is good enough for your purposes. The new C99 size-named
types that contain "fast" in the name are more appropriate than 'int'
for most such purposes; I hope that something like them gets adopted
into C++.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Steven T. Hatton
Guest

Posted: Wed Apr 07, 2004 1:43 am Post subject: Re: Why are fundamental type sizes not exactly specified?

Pete Becker wrote:

Quote:

"Steven T. Hatton" wrote:

Why are fundamental type sizes not exactly specified?

This was explained to me in my first programming courses many years ago.
The explanation was something like: 'not all hardware supports the same
size fundamental data storage unit'. Usually followed by the professor
mumbling something unintelligible.

Other than the last sentence, that's correct. The goal of C and C++ is
to make it easier to write robust, fast code.

I had a number of professors who weren't particularly fond of the feature.

Quote:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?
* What actual experimentation has been done to quantify the impact of
specifying the exact size of these types?
* Is it reasonable to provide both a set of exactly specified types, and a
set of adaptive types?

My two concerns are 1) the psychological impact on people who are trying to
chose a language to learn, or to use on a project. 2) Determining if there
is a real and significant risk involved in porting software written using
the current adaptive types of C++?

My comments about the consequences on something as vital as a manned space
mission are not wholly unfounded. I am aware of one case in which an
unmanned vehicle was lost due to an error involving a loop counter, and
another case in which a vehicle was lost due to the use of incompatible
measurement units by different teams working on the same project.

I once built a computer system for NASA. After we built systems, we ran
tests on them to deternine if they would fail under a load. The system in
question locked up during one of the tests. My supervisor assured me the
problem was in the test, not in the hardware. I was not 100% convinced.
Nonetheless, I boxed up the system and delivered it to Goddard Space Flight
Center. When I got to Goddard, I was directed to the building containing
the cargo bay of the Space Shuttle. I was told to set the system up on a
table next to the controls for the robotic arm used by the Shuttle.

I was then asked to remove the cover of the system and install some
customized hardware created by GSFC. I asked what they were planning to
use the system for. He said "telemetry for experiments involving the
robotic arm." That was *not* a pleasant experience.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Nicola Musatti
Guest

Posted: Wed Apr 07, 2004 7:52 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

[email]hattons (AT) globalsymmetry (DOT) com[/email] ("Steven T. Hatton") wrote in message news:<VMydnbJtZJcGHu_dRVn-vw (AT) speakeasy (DOT) net>...

Quote:

Pete Becker wrote:
[...]
I had a number of professors who weren't particularly fond of the feature.

Fondness strikes me as a curious way to measure suitability. In a
reasonably well designed language each feature is the result of
compromise between different goals and constraints. If you do not
share these goals, you probably should look for a different language,
better suited for your needs.

Quote:

It certainly could be done. Indeed, Java imposes exact requirements on
all fundamental types, and the result is that floating point math on
Intel systems is horrendously slow, because the required semantics don't
match the hardware.

My questions are these:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?

Maybe you should ask them, shouldn't you? Smile

Their main assumption
appears to be that the increase in portability is worth the cost of a
thicker abstraction layer above the machine. Note that in the area of
floating point calculations this was determined afterwards not to be
the case, and the specification was relaxed in favour of performance.

[...]

Quote:

My two concerns are 1) the psychological impact on people who are trying to
chose a language to learn, or to use on a project.

People having problems overcoming such a psychological impact should
probably give up programming completely.

Quote:

2) Determining if there is a real and significant risk involved in porting
software written using the current adaptive types of C++?

Of course there is. It is well known and should be taken into account
when porting.

Quote:

My comments about the consequences on something as vital as a manned space
mission are not wholly unfounded. I am aware of one case in which an
unmanned vehicle was lost due to an error involving a loop counter, and
another case in which a vehicle was lost due to the use of incompatible
measurement units by different teams working on the same project.

This says more about the inadequacy of the process and/or the people
involved than about the chosen language. In my opinion the more
complex a piece of software is the more the impact of programming
errors is reduced with respect with process errors (e.g.
misunderstanding on requirements, design or architectural errors,
insufficient testing, etc.). No set of language features can
compensate the effect of ignorance, laziness and stupidity.

Quote:

I once built a computer system for NASA. After we built systems, we ran
tests on them to deternine if they would fail under a load. The system in
question locked up during one of the tests. My supervisor assured me the
problem was in the test, not in the hardware. I was not 100% convinced.
Nonetheless, I boxed up the system and delivered it to Goddard Space Flight
Center. When I got to Goddard, I was directed to the building containing
the cargo bay of the Space Shuttle. I was told to set the system up on a
table next to the controls for the robotic arm used by the Shuttle.

I was then asked to remove the cover of the system and install some
customized hardware created by GSFC. I asked what they were planning to
use the system for. He said "telemetry for experiments involving the
robotic arm." That was *not* a pleasant experience.

But it did work, didn't it?

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Michiel Salters
Guest

Posted: Thu Apr 08, 2004 12:10 am Post subject: Re: Why are fundamental type sizes not exactly specified?

[email]hattons (AT) globalsymmetry (DOT) com[/email] ("Steven T. Hatton") wrote in message news:<VMydnbJtZJcGHu_dRVn-vw (AT) speakeasy (DOT) net>...

Quote:

Of course. Professors are humans, and also make mistakes. C and C++ have
steeper penalties for mistakes, and more rewards (eg. speed/size) for
correctness. If you don't need the advantages, why risk anything?

Quote:

It certainly could be done. Indeed, Java imposes exact requirements on
all fundamental types, and the result is that floating point math on
Intel systems is horrendously slow, because the required semantics don't
match the hardware.

My questions are these:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?

Because they were designing a language that was designed to complement C++,
not to replace it. Consider a language just like C++, but with all
identifiers changed to uppercase. You could use it everywhere where C++
is appropriate, but it wouldn't be used - because it is precisely what we
already have. Anything new differs, that is what new means.

Quote:

* What actual experimentation has been done to quantify the impact of
specifying the exact size of these types?

The transition from Win16 to Win32 comes to mind. Anyone assuming that
the whole world was a 16 bits 8086 was hurt. The next obvious case will
be Win64 (although the impact will be lower there, int stays 32 bits).

Quote:

* Is it reasonable to provide both a set of exactly specified types, and a
set of adaptive types?

Sure, see the C99 comments.

Quote:

My two concerns are 1) the psychological impact on people who are trying to
chose a language to learn, or to use on a project. 2) Determining if there
is a real and significant risk involved in porting software written using
the current adaptive types of C++?

1) is simply handled in teaching. 2) is obvious. There is a risk, as you
might uncover errors in existing code. That is typical for all porting.

Quote:

In such cases, you must control our code carefully. In particular, every
expression in your code must be validated for correctness. Range checks
are just one item, just as checking for division by 0. Do you want to
add types without a representation of 0, just so you don't have to check
those divisions?

Regards,
Michiel Salters

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Pete Becker
Guest

Posted: Thu Apr 08, 2004 12:10 am Post subject: Re: Why are fundamental type sizes not exactly specified?

"Steven T. Hatton" wrote:

Quote:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?

Stupidity? Arrogance? Different design goals?

Quote:

* What actual experimentation has been done to quantify the impact of
specifying the exact size of these types?

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Quote:

* Is it reasonable to provide both a set of exactly specified types, and a
set of adaptive types?

Only if you ignore the psychological impact on people who are trying to
choose a language to learn, or to use on a project. Such complexity is
daunting.

Quote:

If you don't know how to do it, it's dangerous.

Quote:

Yup: programmers make mistakes. Languages can't change that. Robust
development processes can compensate for it.

Quote:

How does this relate to your desire for exactly specified numeric types?
Ignoring test results is a process failure.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

John Nagle
Guest

Posted: Thu Apr 08, 2004 2:55 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

Pete Becker wrote:

Quote:

"Steven T. Hatton" wrote:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?

Stupidity? Arrogance? Different design goals?

The realization that neither Sun nor Microsoft needs
to support 36-bit mainframes?

The 12, 18, 24, 36, 48, and 60-bit machines are essentially
dead. Other than Unisys ClearPath mainframes and some older
DSPs, very few non-power-of-two machines are still manufactured.

John Nagle
Animats

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Francis Glassborow
Guest

Posted: Thu Apr 08, 2004 9:05 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

In article <cefd6cde.0404070104.559c755c (AT) posting (DOT) google.com>, Michiel
Salters <Michiel.Salters (AT) cmg (DOT) nl> writes

Quote:

And, I believe, we already see the problem in several other languages
that chose to make the character representation type 16 bits wide whicc
is insufficient for a 'flat' mapping of Unicode (or ISO 10646)

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Steven T. Hatton
Guest

Posted: Fri Apr 09, 2004 2:45 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

Pete Becker wrote:

Quote:

"Steven T. Hatton" wrote:

* Why did the Java (and C# designers AFAIK) choose to exactly specify
these values?

Stupidity? Arrogance?

Neither of these seem to be reasonable explanations.

Quote:

Different design goals?

What design goals would have led to the choices they made? I believe it's
noteworthey that two general purpose programming languages which both drew
heavily from C/C++ have the exact size of fundamental types specified.
These people who made the decisions are not stupid. Stupid people cannot
design successful programming languages.

Quote:

* What actual experimentation has been done to quantify the impact of
specifying the exact size of these types?

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

I didn't see anything in the article directly addressing my question. It
directly addresses Java's chosen approach to floating point math. Some of
the assertions of the authors are nothing more than a rejection of the
unfamiliar. You may find the following somewhat amusing in this context:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0210&L=java3d-interest&F=&S=&P=58005

I have since learned of good reasons for the choices made by the designers
of the vecmath package. But this is a digression, and does not address the
topic.

Quote:

* Is it reasonable to provide both a set of exactly specified types, and
a set of adaptive types?

Only if you ignore the psychological impact on people who are trying to
choose a language to learn, or to use on a project. Such complexity is
daunting.

Perhaps. Perhaps it's an issue of presentation.

Quote:

My two concerns are 1) the psychological impact on people who are trying
to chose a language to learn, or to use on a project. 2) Determining if
there is a real and significant risk involved in porting software written
using the current adaptive types of C++?

If you don't know how to do it, it's dangerous.

What if you don't realize it needs to be addressed?

I will observe the article you referenced above gave yet another example of
how a computer program led to the loss of an astronautical vehicle. That
strengthens my case that human error regarding software can lead to costly
mishaps. So far I have not seen where people have addressed my fundamental
concerns.

Quote:

How does this relate to your desire for exactly specified numeric types?

It relates to the topic at hand in so much as it gives a real world example
of how decisions that can impact vital missions are actually made.

Quote:

Ignoring test results is a process failure.

The person who assured me the problem was due to a fault in the test didn't
ignore the test result. He simply believed (probably correctly) that the
errant result was due to a fault in the OS, not in the hardware. It was an
informed decision. So far in this discussion I have not seen a great deal
of evidence to support the view that the C++ design decisions under
discussion have been carefully examined.

I will observe that I have not explicitly stated the choices made by the C++
Committy were wrong. I have merely called them into question so that I
might be confident that the best choice was made.

I've been in situations where my input weighed hevily in choosing things
such as a programming language to use on a major DoD project. If I ask a
language J expert if there is a risk R involving the use of language J, and
she confidently says "no", and explains why, then I ask a C++ expert the
same question about C++ and he says "Only if you're an idiot", I am likely
to favor language J.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bo Persson
Guest

Posted: Fri Apr 09, 2004 2:45 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

""Steven T. Hatton"" <hattons (AT) globalsymmetry (DOT) com> skrev i meddelandet
news:VMydnbJtZJcGHu_dRVn-vw (AT) speakeasy (DOT) net...

Quote:

Pete Becker wrote:

"Steven T. Hatton" wrote:

Why are fundamental type sizes not exactly specified?

This was explained to me in my first programming courses many years
ago.
The explanation was something like: 'not all hardware supports the same
size fundamental data storage unit'. Usually followed by the professor
mumbling something unintelligible.

Other than the last sentence, that's correct. The goal of C and C++ is
to make it easier to write robust, fast code.

I had a number of professors who weren't particularly fond of the feature.

It certainly could be done. Indeed, Java imposes exact requirements on
all fundamental types, and the result is that floating point math on
Intel systems is horrendously slow, because the required semantics don't
match the hardware.

My questions are these:

* Why did the Java (and C# designers AFAIK) choose to exactly specify
these
values?

Because they, like you, thought it would be a good idea?

Quote:

* What actual experimentation has been done to quantify the impact of
specifying the exact size of these types?

Try this "How Java's Floating-Point Hurts Everyone Everywhere":

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Quote:

* Is it reasonable to provide both a set of exactly specified types, and a
set of adaptive types?

But what sizes?

We are back again at our old 36 bit machines. Why would you like them to
give you *exactly* 32 bits in an int?

Quote:

The latter was because one system used feet and another system used meters.
Having a fixed value size would hardly help here.

Bo Persson

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

James Kuyper
Guest

Posted: Fri Apr 09, 2004 2:45 pm Post subject: Re: Why are fundamental type sizes not exactly specified?

[email]hattons (AT) globalsymmetry (DOT) com[/email] ("Steven T. Hatton") wrote in message news:<VMydnbJtZJcGHu_dRVn-vw (AT) speakeasy (DOT) net>...

Quote:

Pete Becker wrote:
...
Other than the last sentence, that's correct. The goal of C and C++ is
to make it easier to write robust, fast code.

I had a number of professors who weren't particularly fond of the feature.

To each his own. That's why C and C++ are NOT the only languages on
the market.

Quote:

It certainly could be done. Indeed, Java imposes exact requirements on
all fundamental types, and the result is that floating point math on
Intel systems is horrendously slow, because the required semantics don't
match the hardware.

My questions are these:

* Why did the Java (and C# designers AFAIK) choose to exactly specify these
values?

Because they had different goals and priorities than the C designers.
Those goals and priorities may make Java a superior language for some
purposes; but they make it a worse one for others.

...

Quote:

* Is it reasonable to provide both a set of exactly specified types, and a
set of adaptive types?

Yes.

Quote:

My two concerns are 1) the psychological impact on people who are trying to
chose a language to learn, or to use on a project.

... 2) Determining if there
is a real and significant risk involved in porting software written using
the current adaptive types of C++?

Yes, of course. There's also a risk when using non-adaptive types.
They're pretty much inverse risks. The risk with the adaptive types is
that you might really need a fixed-sized type, in which case you'll
need to change the code for different platforms. The risk with
fixed-size types is that you might not need a fixed-size type, in
which case you might fail to use the best type for a given platform
because you're forcing it to use a less efficient type.

That's why a combination of exact-sized and adaptive types is a better
solution.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum