Fixing C
41–50 of 123 posts
Re: Fixing C
#42Earlier quoted context omitted.
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
#43Oh 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
#44Re: Fixing C
#45Oh 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
#46When 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
#47C 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.
Good news. Arrays have sizeof(arr)/sizeof(arr[0]) elements and strings have strlen(str) letters.
Re: Fixing C
#48Here is a much better start: http://blog.regehr.org/archives/1180
"Proposal for a Friendly Dialect of C"
Re: Fixing C
#49Re: Fixing C
#50When 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…