Earlier quoted context omitted.
Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?
Having never used such a language, I'm curious, what's the debugging experience like? Can I source level step the application in the original language or do I have to debug the generated C?
C meeting is over. C23 added:
111–120 of 363 posts
Re: C meeting is over. C23 added:
#112C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.
And you will be forever left writing insecure memory unsafe code.
Re: C meeting is over. C23 added:
#113C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.
Majority of CVE's are because of C memory model, which is fixed in modern languages. C memory model is the constant source of vulnerabilities, thus it better to write new code in a memory safe language, like Rust.
Re: C meeting is over. C23 added:
#114Removing K&R style function prototypes though is kind of big. I remember when one of the Objective-C upgrades started enforcing K&R. I don't think ObjC will be upgraded to C23 (ever, as it's a language being deprecated now I presume) so it will be stuck with K&R... while the rest will move on? Could someone also explain what this means for pure C in terms of compatibility? If there's void foo(); would the meaning of…
Re: C meeting is over. C23 added:
#115Earlier quoted context omitted.
What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.
According to the OP tweet though, `foo()` is now a function that takes no arguments.
> In this proposal, a function declarator without a parameter list declares a prototype for a function that takes no parameters (like it does in C++).
And it seems like gcc implements this under -std=c2x now:
zx2c4@thinkpad /tmp $ cat a.c
int blah()
{
return 7;
}
int main(int argc, char *argv[])
{
return blah(argc);
}
zx2c4@thinkpad /tmp $ gcc -std=c17 a.c
zx2c4@thinkpad /tmp $ gcc -std=c2x a.c
a.c: In function ‘main’:
a.c:8:16: error: too many arguments to function ‘blah’
8 | return blah(argc);
| ^~~~
a.c:1:5: note: declared here
1 | int blah()
| ^~~~Re: C meeting is over. C23 added:
#116OMG! Please do not add more undefined behaviour!
We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can prove that 'new_size' went into 'realloc' before.
Re: C meeting is over. C23 added:
#117C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.
...except it just changed. And you will be forever left writing insecure memory unsafe code.
Re: C meeting is over. C23 added:
#118Earlier quoted context omitted.
What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.
Wow, that's annoying. There's a bunch of old code we have that'll need updating (written that way to keep the line lengths down).
Re: C meeting is over. C23 added:
#119Re: C meeting is over. C23 added:
#120Earlier quoted context omitted.
I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…
Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.