Cinder - open source library for professional-quality creative coding in C++
libcinder.orgLooks nice- more cross platform batteries for C++. I'm sort of sad they don't support Linux though.
That is a really clever logo. Who designed it?
The Barbarian Group is known to be a top design agency that creates really impressive creative design. So probably them.
You must be joking.
Did anybody else misinterpret the phrase "creative coding in C++"?
Yes. I thought: "How would this library help the way I write code in C++?" Apparently "creative coding" means a particular class of applications.
source: http://github.com/cinder/Cinder
Looks like Robert Hodgins, et al, has graduated from the world of Processing. For those of you who aren't familiar with Hodgins/Barbarian Group, he's the guy behind the original Magnetopshere visualization, which was eventually ported over to iTunes.
it's interesting the use the phrase "creative coding" but make no reference to openframeworks, which is essentially the competition and also uses that phrase http://www.openframeworks.cc/
No offence to the OF project intended, but if nothing else the Cinder code appears to be a lot cleaner. I don't like the way OF wraps GL functions for a start.
At a first gander it looks like Cinder lets doesn't baby you as much, and really provides a "consistent way to do this kind of C++" as much as the library functions themselves.
That's my first impression anyway.
Openframeworks is mentioned in the FAQ. http://libcinder.org/about/
can anyone comment on how Cinder compares to openFrameworks?
From the FAQ:
>First, when it comes to power and performance, C++ is still the language to beat.
Oh really?
Yes.
This is borne out, IMHO, by the fact that even though everyone supposedly "knows" it's broken and how to fix it, it is by far still the most popular choice when you need very high performance with reasonable abstraction power in industry. It's been around for decades, and there's nothing worthwhile to replace it that fits in the particular domain it fits into.
I'm not advocating here -- I suspect what will happen is that as the low-level architecture of computers change, something may take it's place that maps better, but for now, that statement is no lie.
What do you find controversial about that statement?
You can certainly argue over which languages are most powerful, but there's really only one other general purpose language that rivals C++ in terms of performance and that's C. C++ being nearly a strict superset of C is almost by definition more powerful.
This whole thing implicitly assumes there's some acceptable "balance" you're making when you compare abstraction power and performance. Ignoring the fact that "choosing speed" or "choosing abstraction" is a bit of a false dichotomy, that's okay. But according to this page, C++ is the perfect harmony between these two areas. I'm calling bullshit on how arbitrary that is.
WTF are you on about? The page doesn't say any of that. They acknowledge that C++ is not perfect but give specific reasons why it's a good fit for this domain: performance, access to cutting edge tech (e.g. GPUs, iPhone, iPad) and access to native OS facilities. The only other language that fits that description is C, and you're damn right that "speed" and "abstraction" do not sum to zero: C++ is C with more abstractive power.
> C++ being nearly a strict superset of C is almost by definition more powerful.
Not necessarily. In the general case, restrictions can make a language more powerful [1], by allowing the user and the compiler to make more assumptions. E.g. removing gotos and mutations seem good ideas.
In the case of C vs C++, removing operator overloading and exceptions could turn out to make the language more powerful.
[1] If you use the right definition of `powerful'. You need a sensible definition that avoids "They are all Turing complete and thus equally powerful."
Removing operator overloading makes vector and matrix math deeply unpleasant - something that this kind of "creative coding" tends to use rather heavily.
I like how Haskell handles operator overloading: You need to conform to some kind of type class, _and_ you can make up your own operators instead of having to reuse bit-shifts for I/O.
Oh, I do not really have an opinion on operator overloading in C++. I just conceded the possibility that "removing operator overloading [...] could turn out to make the language more powerful [...]", because I have heard the opinion being advanced with some good arguments.