Re: size_t problems
- From: jacob navia <jacob@xxxxxxxxxxxxxxxx>
- Date: Sat, 01 Sep 2007 17:56:04 +0200
Ed Jensen wrote:
Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:Why? Surely everyone has learned their lesson from the early 1990s - "don't rely on exact-size types, or your code will break one day" - haven't they?
Sometimes (most of the time?) C developers need to choose between:
1. Writing 100% portable code. This can be non-trivial and really
slow down your development. (However, I'm sure writing 100% portable
code doesn't slow down any of the geniuses HERE. I'm talking strictly
about MORTAL developers.)
2. Writing code that's portable to the platforms they're currently
targeting. And perhaps keeping in mind platforms they're likely to
need to support in the future.
It's easy to be smug and regurgitate the ivory tower attitude:
"Well, just write your C code so it's 100% portable in the first
place. Easy! Problem solved! Only dummies don't do that!"
And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).
It is easy to play the guru here. More difficult in reality.
The reality of the situation is that many developers who choose the
"100% portable path" may end up (1) being unemployed, because their
productivity is low compared to more pragmatic developers, or (2)
working 80+ hours per week in order to keep pace with those more
who cares about the job?
c.lang.c is the only thing it counts
Of course, what's really happened in the market is that more and more
projects have abandoned C (and C++) for evil, horrible, limited,
short-sighted languages that made pragmatic choices like: fixed size
I personally try to walk the fine line between "TOO pragmatic" and
"TOO ivory tower". I'm not quite ready to look down my nose and
admonish those developers that sometimes used "int" when they should
have used "size_t". (I do agree, however, that they should fix their
code the right way, if they decide to continue to use C.)
The problem, if you care to see it as such, is really that C is aging,
and some of the choices made decades ago made sense then, but perhaps
don't make so much sense now, for an ever increasing number of
Because C was one of the first languages I knew well, and I had done
it for such a long time, it'll always have a soft spot in my heart.
However, I can't help but yearn for something very much in the C
tradition but updated and refreshed. A "C2" language, perhaps, where
there's no need for an alphabet soup of types, and where a "size_t"
type becomes unnecessary.
(a) far from being garbage, size_t is a useful type;
(b) the committee codified size_t is 1989, not 2007;
(c) far from being obsolete, code that uses proper types in the proper way is more likely to survive and flourish than code that does not.
In my opinion, (c) is only true in a limited sort of way. It's more
likely that developers will flee to languages that offer increased
productivity AND portability through fixed size types. Those
languages make (a) almost entirely, if not entirely, irrelevant.
That way you've got to keep on rewriting things.Precisely. Whereas, if you use the proper types in the right way, you are less likely to have to do that.
When programming in C, it is, quite simply, too much of a productivity
killer to always make sure you're using the proper types in the right
way 100% of the time. This comment shouldn't be mistaken as an excuse
for developers to use "int" when they should use "size_t", though.
It's just a comment on C in general.
more about that later
- Prev by Date: Re: size_t problems
- Next by Date: Re: Porting C software
- Previous by thread: Re: size_t problems
- Next by thread: Re: size_t problems