#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
float i = 10;
DO({i+= 10;} 20);
float i_1 = 10;
{I i_2=0,_n=(n);for(;i_2<_n;++i_2){i_2 += 10;}}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); var i0 = $(Int, 5);
i0 = $(String, "Hello");
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.
Which ones?
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?
https://github.com/django/django/blob/master/django/db/model...
In C++, everything is an int; except for objects; and templates; and lambdas; and classes; and exceptions; and all the other things which keep getting chucked on to the pile.
I like languages with a clear, simple concept behind their operation: lambda calculus, combinatory logic, Scheme, Forth, Joy, Pure, etc. C is a bit gnarly, but passable. C++ is horrible.
The aspect that I love about C is how easy it becomes to read. C offers a (arguably) nice programming interface while not allowing the programmer to hide very many things that are going on. C allows you to make nice abstractions, but those abstractions are still built upon the same basic concepts that C supports, and these abstractions generally don't fundamentally change how the language works, so you can very easily tell the control flow of your program if you simply understand the interactions between the basic parts in use.
Now that said, I'll be the first to say that I think C could benefit from a variety of different features (Some from C++, some from others, and some unique to C), and I could easily give you a fairly long "wish-list" I have for C. But, the clear nature of C is a huge advantage that I think is underrated, and is something that you really can't get back in a language once you lose it.
When you (or I) read a piece of C++ code, there are a lot more details you have to take into account then when you read a piece of C code, simply because C would force the writer to be more explicit in what they are doing in those cases.
Again though, I'll make it clear that I don't think C is the be-all end-all of languages - in particular I'm excited to see how Rust goes - but I do think it has traits that are very nice but largely ignored in most of the current languages in favor of adding lots of different ways to write your code.
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.
I beg to differ. C++ encourages placing more code than strictly necessary into header files. Even the standard headers such as <algorithm> add considerably to the compile time, and they keep getting larger with every revision of the standard. When you are making incremental changes, it accumulates to a lot of time spent waiting.
Variable x, y, z;
solver.add(x <= y);
solver.add(z >= x - y);
double row[size+1] = { };
/* ...fill row... */
add_constraint(solver, row);
/* ...fill row... */
add_constraint(solver, row);
From the employment point of view, C++ is a nightmare. No one really knows it, and everyone thinks he does. Experienced developers can't tell what explicit constructor is, are confused with move semantics, blink hopelessly on "what is RVO". You actually employ python programmers for sky prices, while all they know is easiest part of C++/stl magic, which is effectively beginner-grade python with low-level bugs and UBs.
>wrap C++ libraries in a C API
Together with "ecosystem" such as std::cool_ptr<std::map<std::bar,std::baz>>. That's a concern.
When I want nice bridgeable object model above C, I use Objective-C or simple embedded language with proper features. Personally, I'm really tired of C++ everywhere.
[1] http://stackoverflow.com/questions/4489012/does-c-have-a-sta...
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.