[TUHS] C declarations.
lm at mcvoy.com
Mon May 15 10:40:19 AEST 2017
On Sun, May 14, 2017 at 08:14:47PM -0400, Dan Cross wrote:
> The kludge is that it works different than everything else for no really
> good reason.
I'd be curious what Steve thinks about all this, I know he weighed in
a bit, but does he think that Dennis / Brian/ Ken regret this design choice?
Personally, I can easily see why they did it. C doesn't really have a lot
of behind-the-scenes magic, it can easily be viewed as a pleasant way to
do portable code that sits directly on the hardware, no frameworks, no
garbage collector, no magic. It's predictable in ways that higher level
languages are not. That's one of the things I like about C, I can reason
But I suspect it was more basic than that. They were running on 16 bit
pretty slow machines and having a pass by value model for arrays just
didn't make any sense. *Everyone* would pass by reference so why bother
having a pass by value model? If you really, really wanted that you
could get it
int payroll = add_them_up(malloc_and_copy(salaries, sizeof(salaries));
But any sane person in that day and age would go "why on God's green earth
would you do that? It's slow. Just don't change the salaries array and
you'll be fine".
Think about all the str* stuff - you really want to malloc and free that?
It would have killed performance.
Personally I think they looked at it, said "everyone will use references
for arrays anyway, let's make them references by default".
I get that it is not clean and pure and doesn't match how other types work,
I do see that, but I also see that their choice made a ton of sense at the
time. And maybe still does. It's not the same as the other types because
the other types are, typically, small. Arrays can be big, really big.
More information about the TUHS