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

31–40 of 123 posts

Re: Fixing C

#31

Post by lmm »

Gibbon1 wrote: post #21
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.

Just having a standardized way to do tail calls would be a big step in the right direction. The likes of Java could do with that too.

Re: Fixing C

#32

Post by Gibbon1 »

enriquto wrote: post #23

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

You are not alone in that. A lot of the annoying stuff in C could be fixed going down that path.

Re: Fixing C

#33

Post by LoSboccacc »

huhtenberg wrote: post #20
andrewchambers wrote: post #16

I would add multiple return so api's don't suck.

There you go: struct much_improved_c { ... }; struct much_improved_c an_api_that_doesnt_suck() { ... };

I always found that unnatural in C and preferred the other way around: to pass the struct to populate as a pointer and keep the return code for tracking operation status/handlers

Re: Fixing C

#34

Post by Sinergy »

JulianMorrison wrote: post #26
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.

Inline functions.

Re: Fixing C

#36

Post by veli_joza »

huhtenberg wrote: post #20
andrewchambers wrote: post #16

I would add multiple return so api's don't suck.

There you go: struct much_improved_c { ... }; struct much_improved_c an_api_that_doesnt_suck() { ... };

This is the only way it can be done in statically typed language. You cannot have multiple returns without defining how many there are what are their types.

Re: Fixing C

#37

Post by not-much-io »

mschuster91 wrote: post #3
not-much-io wrote: post #2

Regarding the curly brackets thing vs. end statements and indentation: How is this a problem with editors/IDEs doing it all for you? If your editor/IDE does not do this, then.. why don't you have this in your setup?

You can do auto-indent in Java, PHP, Perl... but not in C/C++, where you're free to embed curly braces etc. in macros, and it's really common to do so. To make matters worse, you actually need to compile the program in order to determine which macro gets expanded into what amount of braces...

Ah now I see. Although I understand that there are some tools that do this, it is not a trivial process like in many other languages. Thanks for enlightening me.

Re: Fixing C

#38

Post by mfukar »

veli_joza wrote: post #30
exprA wrote: post #19

Earlier quoted context omitted.

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.

Now, at one point, you stopped talking about arrays and started talking about pointers.

Re: Fixing C

#39

Post by veli_joza »

There's no way to make C modern language without breaking all the legacy code. But if possible, I would remove the preprocessor and cover its usage in core language.

For projects where you are free to choose your language, Nim is very modern and powerful. It compiles to C so you can use it as easy replacement.

Re: Fixing C

#40

Post by legulere »

I would want it to be based on references and slices, both nullable and non-nullable. References don't allow pointer magic, therefore are always in bounds. Slices only allow sub slicing, therefore they're also always within bounds (dereferencing them would need bounds checks to be safe though).

The great problem of C is that almost everything is a pointer and they potentially can all be invalid. On top of this there's no easy way to check wether they are valid. This is the reason, why memory safety is so hard to get right with C.

Post reply on HN