Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing C

embedded.com

Post reply on HN
Print view View original

21–30 of 123 posts

Re: Fixing C

#21

Post by Gibbon1 »

rootlocus wrote: post #7

Removing curly braces? I have to paraphrase Torvalds on this: > The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, > and should fix your program. Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclom…

I don't really see the problem either. A lot of this stuff I see seems to be centered around stuff that 'trips up beginners'

What I would like would be a way to portably create a stack frame and pass it around as an object and then call a function with it.

Re: Fixing C

#22

Post by _pmf_ »

lake99 wrote: post #10

Oh god! This brings back memories of the nightmarish legacy code that I had to work on, a long time ago. The previous developer apparently liked Pascal and hated C. His principal header file had something like #define begin { #define end } and many other Pascalisms. As a result, his code did not look like C at all. IIRC, the code had gone unmaintained since the late 80's, which is not surprising in embedded systems.…

Isn't there the anecdote that the Bourne shell is written in this style?

Re: Fixing C

#23

Post by enriquto »

Closures.

This is the only thing that I miss in C. I always want to declare local functions, and return pointers to them.

Re: Fixing C

#24

Post by asmithmd1 »

cturner wrote: post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

If you are in the Boston area tomorrow you can ask him in person, he will be speaking at the Embedded Systems Conference:

http://www.embeddedconf.com/boston/scheduler/session/mars-at...

The full conference pass is $1300 but you can watch his session and many other sponsor sessions with the free pass.

Re: Fixing C

#26

Post by JulianMorrison »

rootlocus wrote: post #7

Removing curly braces? I have to paraphrase Torvalds on this: > The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, > and should fix your program. Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclom…

If it's embedded code, it's quite possible you can't just decompose code into little bitty chunks to avoid nesting, because your maximum stack depth is fixed and very small.

Re: Fixing C

#27

Post by asddubs »

adrianN wrote: post #13

C has many, many problems. Curly braces are really not one of them. If I could wave a magic wand and fix C I'd make arrays and strings know their size. Edit for the nitpickers: Yes, arrays decay to pointers and that's the real problem. Sorry.

I would make it impossible for a simple addition of two integers to result in undefined behaviour

Re: Fixing C

#28

Post by Gibbon1 »

XorNot wrote: post #15
rootlocus wrote: post #7

Removing curly braces? I have to paraphrase Torvalds on this: > The answer to that is that if you need > more than 3 levels of indentation, you're screwed anyway, > and should fix your program. Breaking the code into manageable chunks is a huge part in writing clear, maintainable software. A high amount of curly braces implies deep nested loops and/or branches, which also implies a high complexity (measured by cyclom…

Doesn't this equally imply the opposite argument? You could get away with enforced indenting, remove the curly braces, and there should still be no problem.

Problem is you end up like python where writing tooling is hard/impossible because the syntax doesn't have enough redundancy. I look at python and get the feeling the guy tried to make it work with just indenting, and then had to punt and add colons.

Re: Fixing C

#29

Post by _pmf_ »

cturner wrote: post #17

When I was reading I was thinking - if you like that kind of grammar just use Ada. And then later down he specifically mentions Ada. So - why not just use that? With Ada, it is straightforward to create the kind of tight, fast code you'd write in C. You can control your own garbage collection and it has a fabulous type system. And - unless you need templates - it can do pretty much everything C++ can do as well. I do…

I think the main two reasons are: - Ada is in practice managed by AdaCore; compiler features may or may not migrate back to the free GNAT compiler. I understand that they are kind of stuck: they have their customer base, and any kind of opening up would cause revenue losses that may or may not be recovered by more customers. I think they are making the right choice - superficial as the reason may be, the syntax turns many people off (it's kind of an acquired taste for me)

Re: Fixing C

#30

Post by veli_joza »

exprA wrote: post #19
adrianN wrote: post #13

C has many, many problems. Curly braces are really not one of them. If I could wave a magic wand and fix C I'd make arrays and strings know their size. Edit for the nitpickers: Yes, arrays decay to pointers and that's the real problem. Sorry.

C arrays “know” their size. (String literals do too.)

You can sizeof them if the declaration is in scope. If you pass them as function argument, this information is not obtainable inside function. You have to pass length as well. This is not very elegant and sometimes you elect to process them without using functions just because you can iterate them easier.
Post reply on HN