Re: Why C?
- From: "Steve" <steve49152@xxxxxxxx>
- Date: 8 Nov 2005 19:52:32 -0800
Keith Thompson wrote:
> "Steve" <steve49152@xxxxxxxx> writes:
> [...]
> > I fell into the habit of defining my types explicitly in the top-level
> > header for arbitrary applications: s16 for short int, u64 for unsigned
> > long long, and so on. Generally, I tried to ensure that I was aware of
> > the size of a type as I was writing code, since I figure boundary
> > conditions bite harder than I want to be bitten. Assuring I was
> > getting what I asked for is another matter, and I can only say that I
> > have not had the chance to port much of my code to different
> > architectures, so I can only say that I was preparing my software for
> > that eventuality.
>
> C99's <stdint.h> header covers this, with typedefs like int32_t,
> uint32_t, and so forth -- and the header isn't difficult to implement
> in C90. But of course none of these types are guaranteed to exist.
Exactly.
> But the number of bits isn't always the most important aspect of a
> type. If you want to count something, and you know there can't be
> more than 32767 of them, just use int; if you want to measure the size
> of something, use size_t.
That's nice. What if I don't like the layer of abstraction chosen for
the definitions of [numeric] data types?
> What might be more useful is a syntax for specifying the *range* of a
> type.
There are probably quite a few things that various people would like.
I was merely expressing my opinion of the current approach.
> > There has been a lot of talk about the virtues of portability, on
> > abstracting language syntax from hardware dependencies, and I simply
> > cannot fathom why it is that programmers wish to remain entirely
> > insulated from the world their programs run in. I guess I'm just a
> > heretic, but as much as I like C, there are just some things that I
> > don't want the language doing with my code. I want to know what my
> > code looks like once it is compiled into assembly, I want my language
> > rigidly defined (operator overloading sucks), I want my types fixed
> > across all platforms, and in general, greater control over the language
> > features. printf() and all the rest should have never been made part
> > of the spec.
>
> I rarely care what the generated assembly code looks like. I care
> that the code works the way I intend it to, in accordance with the
> language specification. Much of the time, I wouldn't be able to read
> the generated assembly language even if I bothered to examine it.
Yeah, well that's true too. But you must turn off certain
optimisations when you anticipate examining the assembly language.
Heavy reliance on macros can also impede the understanding of generated
code. This is by the by, however. On one level, I am simply of the
opinion that certain things about the underlying architecture ought to
be kept in mind while writing code, rather than allowing the
architecture to impose itself upon the program after the code is
written and running. Most HLLs seem to insulate the program from the
world, and hence the programmer as well.
Regards,
Steve
.
- Follow-Ups:
- Re: Why C?
- From: Keith Thompson
- Re: Why C?
- References:
- Why C?
- From: jacob navia
- Re: Why C?
- From: Skarmander
- Re: Why C?
- From: jacob navia
- Re: Why C?
- From: Skarmander
- Re: Why C?
- From: jacob navia
- Re: Why C?
- From: Keith Thompson
- Re: Why C?
- From: k_over_hbarc
- Re: Why C?
- From: Steve
- Why C?
- Prev by Date: Re: Simple Matrix Rotation
- Next by Date: Re: how to replace a substring in a string using C?
- Previous by thread: Re: Why C?
- Next by thread: Re: Why C?
- Index(es):
Relevant Pages
|
