Re: Use of Long and Long Long
- From: William Ahern <william@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 14 Jan 2008 20:29:49 -0800
Bart C <bc@xxxxxxxxxx> wrote:
Bart C wrote:
I've always had a problem knowing exactly how wide my integer
variables were in C...
Integer widths that obey the rule short < int < long int <long long
int (instead of short<=int<=long int or whatever) would be far more
intuitive and much more useful...
Just been looking at a book on the C# language and it has these signed
datatypes:
sbyte 8 bits
short 16 bits
int 32 bits
long 64 bits
With unsigned versions byte, ushort, uint, ulong. Perfect and unambiguous,
exactly what I wanted in C. By comparison C's numeric types are a minefield.
(And visually untidy, like _Bool and size_t)
Of course C# is a fairly recent language devised by MS that didn't have to
worry about old code or running on obscure processors.
Or worry about new code, either. In some respects all that mattered was the
instant impressions and opinions at the moment of inception. Only time can
tell whether they're "perfect and unamgiguous" over a longer duration of
computing evolution. Same thing happened with UCS-2/UTF-16. I highly doubt
that C# "got it right".
Only a few years out and C# has already become disheveled. Delegates weren't
the panacea once touted (maybe not be the creators). There are many other
warts and such popping up, especially in relation to newer and more modern
languages.
Many (most?) will argue that C's path is, on balance, preferable. A little
"ambiguity" never hurt anybody. Certainly it forces you to focus more on the
end and not the means. In any event, I think many here would agree that
unjustfied concern with the layout of data types is a sign of inexperience.
When I began programming in C I struggled for years with appropriate usage
of data types. Autoconf tests, macros, typedefs. I was convinced that it
mattered, if only because so many other programmers seemingly expended great
effort wrestling with the "problem".
The implications of C# and Java's decisions aren't as clear cut as you might
think.
Eventually you become comfortable with the notion that you can create
software in a world where all your constraints aren't predefined and
absolutely fixed for you. Amount of memory changes, CPUs get faster (or
slower in some cases). Networks provide higher (or lower) throughput; higher
(or lower) latency. And yes, in some languages even the properties of data
types can change. And if they didn't, it wouldn't matter one iota. At some
point you have to learn how to program in a manner which isn't at odds with
reality, unless you enjoy re-writing the same code over and over again. You
use the tools to solve the abstract problem; you shouldn't invent problems
where none need exist.
At the very least, that some programmers aren't bothered by this aspect of C
should give you pause.
.
- References:
- Use of Long and Long Long
- From: Bart C
- Re: Use of Long and Long Long
- From: Bart C
- Use of Long and Long Long
- Prev by Date: Re: Urgent C Questions
- Next by Date: Re: The machine stack and the C language
- Previous by thread: Re: Use of Long and Long Long
- Next by thread: Re: Use of Long and Long Long
- Index(es):
Relevant Pages
|
|
