#define alloc_stack(T) ((struct T*)header_init( \
(char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack))
Under ARMv8, I think alignment is less of an issue.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
Another previous discussion: https://news.ycombinator.com/item?id=6047576
> It might be better to try Cello out on a hobby project first. Cello does aim to be production ready, but because it is a hack it has its fair share of oddities and pitfalls, and if you are working in a team, or to a deadline, there is much better tooling, support and community for languages such as C++.
Wow. Straight talk instead of salesmanship. High marks for that.
It's a pretty clever hack though, like using setjmp for exception handling. I'm pretty sure I'd never want to use that in production anywhere but it was probably fun to implement.
#define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
A I Sou
Just a few off the top of my head:
* No need to specify type. Use var.
* Simpler for loops
* Inbuilt types for Hash Tables
* File types, making file reading much easier
* Function types, making it easier to pass functions around
* Doctype access
* Threads & Mutexes
* Format strings
* GC (with ability to turn C-types into Cello-types for GCing.)
It is fundamentally syntax-sugar, but enough that what you end up with doesn't necessarily look like C at the end.
with(f in new(File, $S("test.txt"), $S("r"))) {
var k = new(String); resize(k, 100);
var v = new(Int, $I(0));
foreach (i in range($I(2))) {
scan_from(f, 0, "%$ is %$ ", k, v);
show(k); show(v);
}
}
I see types everywhere; they appear to just have been moved from the left-hand side to the right-hand side? eg:
var i0 = $(Int, 5);
var items = new(Array, Int, i0, i1, i2);It's higher level because it provides abstractions that improve the language's expressiveness.
You've really gone down the rabbit hole if you think GC is an improvment
I had thought about trying to make a type-safe version of Cello but I eventually realized that I can't do it in cpp so at that point it became its own language and too much work (I did not write Cello).
typedef void* var;
Nim is another take on that particular strategy.
« In this talk I dig into the depths of my programming library Cello - a fun experiment to see what C looks like when pushed to it's limits. I'll cover how Cello works internally, some of the cuter tricks used to make it look and feel so different, what is in store for future versions of Cello, and why it is important to push languages to their boundaries. »
portability? stable ABI? ... writing something in C make it easy for any other higher level language to link to it. That's why we're not done with C, at all ... it's basically the only serious language out there used to share code among every possible platform or language. Even C++ which is a bit safer in practice is harder to link.
I just wished C was a bit safer by default (arrays with bound checking,...)
Not to go down the C++ evangelist route, but if you want to write libraries in C++ to use with other high level languages, you can wrap the headers in extern "C", and still write C++ as normal in your own code.
So aside from performance and legacy codebases, there's no huge incentive to start a project in C these days. I think those who do it, do it in spite of the alternatives out there.
C is my main language and I dabble in C++. I really dislike C++. I love C. I welcome any efforts to add a bit of higher level functionality to C. I have no desire (ever) to switch to C++.
That's not really true now is it? Sure, C++ and C are separate languages but they have a common history and everyone knows that. One can write extensive programs that are valid for both C++ and C compilers. C isn't a true subset of C++ but for from many practical perspectives it is. In practice they have a common ancestor language that still can be (more or less) compiled with both compilers.
Lisp and Python however... they have no such common ancestor and the syntax are very different.
Only if a python programmer was resorting to contrived macros to shoehorn some of Lisp's features onto python.
If a python programmer wants to write lisp in python, why not simply use lisp?
What about D? Rust?
C++11 and further can be fancy, and not be supported in every possible platform like exotic ones.
Bad reasons would be to talk about the gimmicks of C++, but generally it boils down to programmers being taught well about the language, because it's not an easy one to understand fully, as there many weird pitfalls.
C++ still has to fix some its flaws, like compile times (this should be improved with modules).
So to put it simply, you can still do good work with C because C compilers are just simple and straightforward. When you don't need C anymore (because you only use for it's size and speed, not for the high level), you use something more high level like python. C++ should allow programmers to do everything, but C++ is not perfect and not fully accessible to everyone.
The main reason I can think not to use C++ is that C has a simple stable ABI so you can easily use C libraries from many languages and compilers. But you can always wrap C++ libraries in a C API so that's not a huge concern. Just a pain.
So, this Iron language sounds like deja vu to me from two, different directions. I recommend against it.
You pays the Gold price, or the Iron price.