Cello

There is a lightweight object oriented extension to C called Objective-C [1] that unfortunately never gained much traction outside the NeXT/Apple ecosystem. There is also Cello [2]. [1] https://en.wikipedia.org/wiki/Objective-C [2] https://github.com/orangeduck/Cello

with skills like this, mind to push cello forward? https://github.com/orangeduck/Cello really like it but not skillful enough to do it myself.

Not in active development https://github.com/orangeduck/Cello/issues/135

In my personal experience, "a bit more than a pointer" works best as a pair of (start, end) pointers (where "end" points to just beyond the last element.) The most obvious reasons for this are: - slices become a total non-issue since a pair of (start, end) already is a slice and you can just move start and end. - comparing against an end pointer is generally easier than adding up a length value first, particularly if you're slicing at the same time. - the end pointer value is independent of the array element type, so if you e.g. cast to uint8_t * (which arguably you shouldn't in most cases) it stays exactly the same. If you store a count you need to adjust a multiplier. If you store a byte length, you need to do a lot of divides or casts to deal with pointer arithmetics. Also, this is a huge red flag to me: https://github.com/orangeduc

I'm left wondering about the iteration example that is also quoted in the home page: https://github.com/orangeduck/Cello/blob/master/examples/ite... Okay, so the vector is garbage-collectable once the function terminates ... but it has references to stack-allocated integers i0, i1 and i2. That leaves me wondering: won't the GC walk these and trample on stack memory that has been deallocated/reused. (Maybe those integer values have a tag right in the val pointer that gets the GC to avoid dereferencing them.)

This really reminds me of a project called TinyGC/tgc[0], made by Daniel Holden who is currently a Ubisoft researcher. I have also tried his Cello[1] framework for C99 which also incorporated a garbage collector similar to tgc. Cello is pretty fun to use but the syntax was still limiting. [0]: https://github.com/orangeduck/tgc [1]: https://github.com/orangeduck/Cello

It's not just macros. See the src directory https://github.com/orangeduck/Cello/tree/master/src

https://github.com/orangeduck/Cello/blob/master/include/Cell... Appealing though it is you are not allowed to use $ for a MACRO name in C. It fails in vendor C compilers on AIX and SunOS at least IIRC. I know cause I tried to use it myself once ;)

Wow, this is seriously great! This is exactly what I needed for my project, Viola[1], that provides an abstraction on top of libCello[2] to allow you to write really high-level C. This really helps make Viola a little more high-level. I am really grateful for your blog post! [1] - https://github.com/eatonphil/Viola [2] - https://github.com/orangeduck/libCello

Has the development moved away from github[1] or has it completely stalled ? The last commit I see is from 8 months ago. [1] https://github.com/orangeduck/libCello/

Thanks. I have got a copy of a Stroustrup on my shelf (I think it's a standard library reference, not the language definition) and I've been developing in "C with classes" for a while, so I've discovered quite a few of the pitfalls. I prefer to let clang++ point out when I stumble across something insane, like: vector<vector<T>> // wrong, uses a >> operator?! vector<vector<T> > // compiles correctly. In some ways I prefer what Objective C did, as a proper superset, and in others I'm drawn to projects like Cello[1]. I'm happy with using (and knowing only) a very small set of C++ features, especially where they're useful for defining simple algebras for objects! I'm sure I'll find another feature I like one day - this one (GGP) may be one of them. There is one OSS project I know that I never want to emulate: the code literally fai

Also see https://github.com/orangeduck/libCello/issues/35