251–260 of 262 posts
Earlier quoted context omitted.
Why do you think so?
For two reasons: First, where C++ features are used, it make the code harder to understand rather than easier. Second, it requires newer and more complex toolchains to build GCC itself. Some people still maintain the last C version of GCC just to keep the bootstrap path open.
Earlier quoted context omitted.
For two reasons: First, where C++ features are used, it make the code harder to understand rather than easier. Second, it requires newer and more complex toolchains to build GCC itself. Some people still maintain the last C version of GCC just to keep the bootstrap path open.
I'm very far from compiler development, but in my experience, while C++ is hard to read, the equivalent C code would be much more unreadable.
In general, I think clean C code is easier to read than C++ due to much less complexity and not having language features that make it more difficult to understand by hiding crucial information from the reader (overloading, references, templates, auto, ..).
Earlier quoted context omitted.
It is, just the existence of goto makes control flow significantly harder to understand. People complain about exceptions in C++ obfuscating control flow, but then they recreate exceptions using goto. The funny thing is that exceptions are just fancy goto, the assembly is almost the same. The bigger picture of C as a language is not that it's simple, because it's not simple at all. It's inept. It doesn't give develop…
It is not. That `GOTO` makes things hard does not shift it to some unrelated category. > The funny thing is that exceptions are just fancy goto Not even close. >I like to compare it to building a shed with power tools versus only a screwdriver. That analogy is completely wrong in the context. > it's not intuitive at all. It is completely intuitive, while the "modern" languages with "helpful" magic is not. >C is a lan…
Earlier quoted context omitted.
I don't understand why destructors enter the discussion. This is C, there is no destructors. Are you comparing "adding destructors to C" vs "adding defer to C"? The former would be bring so much in C that it wouldn't be C anymore. And if your point is "you should switch to C++ to get destructors", then it seems out of topic. By very definition, if we're talking about language X and your answer is "switch to Y", this…
Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.
Macros (in general) are way spookier than a defer statement.
Earlier quoted context omitted.
It is not. That `GOTO` makes things hard does not shift it to some unrelated category. > The funny thing is that exceptions are just fancy goto Not even close. >I like to compare it to building a shed with power tools versus only a screwdriver. That analogy is completely wrong in the context. > it's not intuitive at all. It is completely intuitive, while the "modern" languages with "helpful" magic is not. >C is a lan…
None of these were arguments. You just said "nuh uh" in more words, which is really just a waste of storage.
It is, if you choose not to think about those nuh uhs.
Earlier quoted context omitted.
Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.
Defer is not spooky action at a distance. It is an explicit statement that gets executed as written. Unlike (for example, a familiar feature which C doesn’t have) operator overloading… which causes code that looks like one thing (adition for example) behave like another (a function call). Defer does exactly what it says on the tin can (“move this line to the end of the scope”), just like goto does exactly what it cla…
Where it is invisible! What is so hard about this to understand?
>operator overloading..
Yes, but if we go by your argument, you can say it gets executed exactly as it is written. It is just that it is written (ie overloading) somewhere else ie "at distance"...just like a defer block that could be far from the end of the scope that is trigerring it
Earlier quoted context omitted.
Just straight up huffing paint are we.
Explain why? Have you used C99 designated init vs other languages? E.g. neither Rust, Zig nor C++20 can do this: https://github.com/floooh/sokol-samples/blob/51f5a694f614253... Odin gets really close but can't chain initializers (which is ok though): https://github.com/floooh/sokol-odin/blob/d0c98fff9631946c11...
i.e.
struct foo { int a; struct { float b; const char * c } d; };
#define DEFAULT_FOO .a = 1 .d = { .b = 2.0f, .c = "hello" }
...
struct foo bar = { DEFAULT_FOO, .a = 2 }Earlier quoted context omitted.
To be honest I have similar reservations. The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002. (That's a rare enough situation to be unimportant, right? /laughs in industrial control gear.) I'm wary of anything which fragments the language and makes it inaccessible to sub…
C has its unique advantages that make some of us prefer it to C++ or Rust or other languages. But it also has some issues that can be addressed. IMHO it should evolve, but very slowly. C89 is certainly a much worse language than C99 and I think most of the changes in C23 were good. It is fine to not use them for the next two decades, but I think it is good that most projects moved on from C89 so it is also good that…
Earlier quoted context omitted.
If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.
We are talking about C. A destructor function in C is a function that gets called when the library gets unloaded. No you shouldn't have a destructor function for it.
I just mean, in the simple English sense, a function which exists to deallocate a structure.
Earlier quoted context omitted.
If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.
That's certainly one way to do it if you're writing all the code.