There was a snippet I saw a while ago where someone made C look like Java for a joke, using macros. I wish I could find it to share here, it's great.
Here it is:
https://stackoverflow.com/a/653028/981408
Cello – High Level C
31–40 of 83 posts
Re: Cello – High Level C
#32Earlier quoted context omitted.
Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.
> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…
> e.g. it will automatically reshuffle your structs to get rid of excess padding
This is just more complexity as well. It introduces surprising behavior that can burn you when creating interfaces or serializing and forces the developer to know that the compiler will be doing such magic.
Re: Cello – High Level C
#33Earlier quoted context omitted.
> Rust is actually more optimized than C.... I think what you mean is that current Rust _implementations_ optimize better than current C _implementations_. There's no reason a C99 compiler can't do those optimizations.
>There's no reason a C99 compiler can't do those optimizations. No, there actually is, the C standard says structs have to be laid out in memory in the same order they're written and C has much weaker aliasing rules.
C99 has the restrict keyword, which guarantees that the pointer won't be aliased. As far as reordering struct members, there's no reason why an implementation can't provide that as an optional optimization you must explicitly turn on. Providing such an optimization and corresponding compiler flag would not disqualify it from being a conforming implementation.
Re: Cello – High Level C
#34Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.
> I feel like the fine grained low level control is exactly the reason they chose C in the first place
That's not the only reason, there is also simplicity, static typing and performance. If you favor the later two for whatever reason it can be used in places where you'd normal write a python/shell script or small program without too much extra effort (see https://github.com/RhysU/c99sh or suckless tools). Complexity is where Cello seems to fall down though, it seems like it introduces much more complexity than just using plain C with a decent "standard" library like glib.
Re: Cello – High Level C
#35Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.
Not only that, but last I looked into this library's code there was a lot of undefined behavior and general sloppiness that goes against good C practices, eg. ignoring errors, casting all types to void * literally all the time or treating char VLAs as structs without regard for alignment. My sympathy and respect to the author, but they did not appear learn C well before trying to "fix" it. It is kind of irresponsible…
> Not only that, but last I looked into this library's code there was a lot of undefined behavior
Neither GCC's nor Clang's sanitisers pick up any undefined behaviour - and it's been like that for at least the last few years I've looked at it.
As to ignoring errors, and ignoring alignment, I don't think I've ever seen anything like that in the project. I have seen several pull requests delayed so that they will.
Overall, for what it's doing, this is one of the cleaner codebases I've dealt with.
Re: Cello – High Level C
#36This is just an amusing aside: C is the lowest level of an actual cello. ;-)
Re: Cello – High Level C
#37There was a snippet I saw a while ago where someone made C look like Java for a joke, using macros. I wish I could find it to share here, it's great.
Could be worse:
Re: Cello – High Level C
#38Earlier quoted context omitted.
Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.
> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…
How is Rust an answer to not liking C++‘a complexity. With the complexities inherent in the borrow semantics (with the box ref cell stuff that comes with it) and the complexities inherent in the type system and trait system, Rudy seems to be at least as complex as C++. In fact this point gets tossed out a lot, Rust is not a C replacement for C developers, it is at best a C++ replacement for developers who want something more complex than C. Not commenting on the quality of the complexity, just that it seems odd that you would say Rust is an answer to disliking complexity.
Re: Cello – High Level C
#39Earlier quoted context omitted.
Not only that, but last I looked into this library's code there was a lot of undefined behavior and general sloppiness that goes against good C practices, eg. ignoring errors, casting all types to void * literally all the time or treating char VLAs as structs without regard for alignment. My sympathy and respect to the author, but they did not appear learn C well before trying to "fix" it. It is kind of irresponsible…
> Not only that, but last I looked into this library's code there was a lot of undefined behavior Neither GCC's nor Clang's sanitisers pick up any undefined behaviour - and it's been like that for at least the last few years I've looked at it. As to ignoring errors, and ignoring alignment, I don't think I've ever seen anything like that in the project. I have seen several pull requests delayed so that they will. Over…
I'm really surprised that you both came up with opposing results... What tests were done indicating undefined behavior?
Re: Cello – High Level C
#40Earlier quoted context omitted.
Not only that, but last I looked into this library's code there was a lot of undefined behavior and general sloppiness that goes against good C practices, eg. ignoring errors, casting all types to void * literally all the time or treating char VLAs as structs without regard for alignment. My sympathy and respect to the author, but they did not appear learn C well before trying to "fix" it. It is kind of irresponsible…
> Not only that, but last I looked into this library's code there was a lot of undefined behavior Neither GCC's nor Clang's sanitisers pick up any undefined behaviour - and it's been like that for at least the last few years I've looked at it. As to ignoring errors, and ignoring alignment, I don't think I've ever seen anything like that in the project. I have seen several pull requests delayed so that they will. Over…
#define alloc_stack(T) ((struct T*)header_init( \
(char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack))
It looks like they got rid of some undefined things I saw when I looked in 2015. eg. they used to think you can do arithmetic on void pointers, which I think even gcc -Wall would flag for you. [Edit: Trying it out it seems I am wrong, on gcc and clang you need -pedantic to get that warning.]