Clang, bloky a std::function

Když čtu příspěvky od zboje, vždycky mě fascinuje, co všechno za pi*oviny řeší uživatelé C++ v důsledku nekonečné snahy o zkombinování nízkoúrovňových vlastností jazyku (ukazatele, ruční alokace, ...) s vysokoúrovňovými (lambda-výrazy, objekty, ...). Že důsledkem složitosti je chybovost, je známá věc. Připomíná mi to vtip:
386: "Pentium, kolik je 3*3?"
Pentium: "8."
386: "To je ale špatně."
Pentium: "To nevadí, ale je to rychle."

(*=č)

To se jen zdá, ve skutečnosti to není tak hrozný. Akorát nesmíte použít STL. Já mám pro vlastní práci knihovnu, kde si člověk může vybrat. Buď nebudu řešit píčoviny, ale dosáhnu "standardní rychlosti" (tj rychlost srovnatelná s virtuálními strojemi různých frameworků), nebo budu řešit 3.14oviny kvůli tomu, abych to měl rychlejší (nebo menší na paměť, atd). Vždycky záleží na konkrétním použití

A není tohle lepší řešit několika doménovými jazyky, kde každý z nich dělá jen to, co umí nejlíp?

To je pak otázka, jaká je režie na přecházeni mezi temi jazyky a zda vůbec je přechod možný.

2: zlate reseni :D

ono generalizovat co je lepsi, jestli nizkourovnove veci nebo mit to pripravene od jazyka nejde... vzdycky je na kazdou vec neco lepsiho a reseni ondra.novacisko.cz mi pripada jako genialni, pise to porad v jednom jazyce, ale muze si vybrat jestli se s tim musi patlat aby to bylo rychle, nebo ne :-)

clang uz C++11 lambda funkce podporuje:

#include
int main() {
auto l = [] { printf("hello world!\n"); };

l();
}

clang++ -std=c++11 lambda.cpp
./a.out
hello world!

Vetsinu dalsich C++11 veci taky (constexpr, initalizer lists atd.).

SB to je len vec zvyku keby vsetci programovali v nizkourovnovych jazykoch a snazili sa optimalizovat tak nemusime kazdy pol rok kupovat novu masinu, takto sice hardware zrychluje ale software spomaluje takze sme sa nepohli z miesta. je velka skoda ze sa svet ubera tymto smerom.

[7] V tom to není, složitost mnoha SW je stejná. Nyní, když je konečně dost výkonu, můžu ho kus dát, abych dosáhnul vyšší abstrakce a nemusel se srát s nízkoúrovňovými detaily (tj. zdroji chyb a složitosti). Až v případě, když chci něco rychle, použiju nízkoúrovňový jazyk, ale pak tam přece nebudu srát uzávěry!

@8 To nemusí být nutně uzávěry. Uzávěr znamená, že kód (lambda výraz/blok) lze použít i mimo lexikální kontext, kde byl definován. Pokud ho ale použiju v tomto lexikálním kontextu, zůstává na zásobníku (v C++11 i clangu) a ani proměnné použité uvnitř lambda výrazu se (při správné deklaraci) nekopírují/ne­retainují, takže nízkoúrovňovější to už být nemůže. Ostatně v libdispatch se to tak dělá všude bez negativního vlivu na rychlost.
Až když je nutné lambdu/blok uchovat pro pozdější použití, je časová náročnost vyšší, protože se kopíruje (na haldu a podle kontextu obsah uvnitř použitých proměnných). Pak to zhruba odpovídá uzávěrům například v Javascriptu. V nízkoúrovňovém kódu je takové použití netypický, spíše se používá u časově náročných operací, kde se čeká na callback. Stejné to je v Cocoa i WinRT (async).