User avatar
jahboater
Posts: 7316
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 8:52 am

Heater wrote:
Wed Jul 28, 2021 7:09 am
I have always wondered about C's bracketing system. For example why are those round brackets required around the condition in an "if" statement:

Code: Select all

if (somethingIsTrue) {
   ...
}
I suspect it made things easier for the very early compiler because it looks a bit like a function.

User avatar
jahboater
Posts: 7316
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 10:24 am

Heater wrote:
Wed Jul 28, 2021 7:09 am
The there is that use of round brackets when casting. For example:

Code: Select all

int i = 17, j = 5;
   double d;

   d = (double) i / j;
Always seemed a bit odd to me. Not entirely clear to a novice reader, one has to bear in mind type coercions and operator precedence to see what happens there.
Yes, I prefer "d = double(i / j);", but maybe it was to make clear it was not a function, or not clutter the function namespace, or something!

A cast is an operator, not a function.

Heater
Posts: 18514
Joined: Tue Jul 17, 2012 3:02 pm

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 10:54 am

jahboater wrote:
Wed Jul 28, 2021 10:24 am
A cast is an operator, not a function.
Indeed so.

However "sizeof" is also an operator. But can be used as "s = sizeof char" or more usually "s = sizeof(char)". So why not "i = int c" or "i = int(c)"?
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7316
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 11:11 am

Heater wrote:
Wed Jul 28, 2021 10:54 am
jahboater wrote:
Wed Jul 28, 2021 10:24 am
A cast is an operator, not a function.
Indeed so.

However "sizeof" is also an operator. But can be used as "s = sizeof char" or more usually "s = sizeof(char)". So why not "i = int c" or "i = int(c)"?
Yes, good point. Inconsistent.
Maybe sizeof was added much later.

Heater
Posts: 18514
Joined: Tue Jul 17, 2012 3:02 pm

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 4:56 pm

Sharkins wrote:
Wed Jul 28, 2021 4:20 pm
this book is not for everyone...
OK. What do you mean by that?

Which people do you think it is for? Which people do you think it is not for? For what reasons?

Personally I think anyone curious enough to be using a Pi and the PiOS operating system is very likely to be curious as to the origins of the tools we use. It's all interesting stuff.
Memory in C++ is a leaky abstraction .

ejolson
Posts: 8053
Joined: Tue Mar 18, 2014 11:47 am

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 5:03 pm

jahboater wrote:
Wed Jul 28, 2021 11:11 am
Heater wrote:
Wed Jul 28, 2021 10:54 am
jahboater wrote:
Wed Jul 28, 2021 10:24 am
A cast is an operator, not a function.
Indeed so.

However "sizeof" is also an operator. But can be used as "s = sizeof char" or more usually "s = sizeof(char)". So why not "i = int c" or "i = int(c)"?
Yes, good point. Inconsistent.
Maybe sizeof was added much later.
My suspicion is the syntax of C and the way it's formatted was designed to be easy for the humans who were writing an operating system called Unix to read. I think much of the syntax reflects experience with other languages. As a result there are much easier languages than C to write parsers for. Arguably the task of writing parsers was a solved problem, at least at Bell Labs, by the time Unix came out.

Heater
Posts: 18514
Joined: Tue Jul 17, 2012 3:02 pm

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 7:30 pm

ejolson wrote:
Wed Jul 28, 2021 5:03 pm
My suspicion is the syntax of C and the way it's formatted was designed to be easy for the humans who were writing an operating system called Unix to read. I think much of the syntax reflects experience with other languages. As a result there are much easier languages than C to write parsers for. Arguably the task of writing parsers was a solved problem, at least at Bell Labs, by the time Unix came out.
Sorry I can't link to where I read this but is some discussion of the history of C it was stated that the language was created specifically for the task of making the Unix kernel portable. That is recreating in a portable high level language what existed as assembler. That features were added to C as and when that task required them. For example C did not originally even have "struct".

So I can imagine C grew in some organic way, building on what already existed. And so it seems natural to me that the final resulting language is not the best possible solution seen in retrospect.

I'm sure the task of writing parsers was already a solved problem. However there have been languages that can do all that C can do, whist at the same time being more consistent and easier to parse created since then. But that is with the benefit of hind sight.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7316
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 7:45 pm

Heater wrote:
Wed Jul 28, 2021 7:30 pm
Sorry I can't link to where I read this but is some discussion of the history of C it was stated that the language was created specifically for the task of making the Unix kernel portable. That is recreating in a portable high level language what existed as assembler.
Yes, its well known. UNIX was rewritten in C and at the same time enhanced to be multi-user. Its all in that book!
Heater wrote:
Wed Jul 28, 2021 7:30 pm
I'm sure the task of writing parsers was already a solved problem.
Yes.
C obviously came from the typeless B (which had similar "if( expr )" syntax), with notes of the earlier BCPL and Algol68, possibly RatFor.
What I mean is, the reason for some of C's syntax oddities, probably goes back much further, long before C's inception.
Last edited by jahboater on Wed Jul 28, 2021 7:47 pm, edited 1 time in total.

Heater
Posts: 18514
Joined: Tue Jul 17, 2012 3:02 pm

Re: New book by Brian Kernighan.

Wed Jul 28, 2021 7:47 pm

That is my understanding of the history as well.
Memory in C++ is a leaky abstraction .

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 29330
Joined: Sat Jul 30, 2011 7:41 pm

Re: New book by Brian Kernighan.

Thu Jul 29, 2021 9:07 am

Heater wrote:
Wed Jul 28, 2021 4:56 pm
Sharkins wrote:
Wed Jul 28, 2021 4:20 pm
this book is not for everyone...
OK. What do you mean by that?

Which people do you think it is for? Which people do you think it is not for? For what reasons?

Personally I think anyone curious enough to be using a Pi and the PiOS operating system is very likely to be curious as to the origins of the tools we use. It's all interesting stuff.
Spammer, banned. For some reason this thread is like a honeypot for spammers, deleting posts on it every day. Must be some keywords in it that kick of some spammer system somewhere.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Working in the Applications Team.

lurk101
Posts: 898
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: New book by Brian Kernighan.

Sun Aug 01, 2021 12:57 pm

emma1997 wrote:
Wed May 05, 2021 4:12 pm
For me all this ANSI, ISO, plus-plus BS to be avoided whenever possible.
I'm guessing your phone still has a rotary dial.

Return to “Off topic discussion”