Laoo: tylko że w C++ to są takie protezy i potworki składniowe że szkoda gadać :/ Krzywa trudności nauki stroma jak Mannerhorn ;)

Nikt nie każe Ci pisać bibliotek. W C++ można pisać prosto i wg mnie nawet łatwiej niż w C. Śmieszy mnie np co ostatnio przeczytałem, że Torvalds stwierdził, że goto w C jest dobre, oczywiście wywiązała się kłótnia, ale po wielu sporach okazało się, że w takim kernelu goto używają do czyszczenia w przypadku błędów (goto clean; itd), co w C++ dzieje się automatycznie dzięki wyjątkom i destrukcji obiektów przy zwijaniu stosu. Ot twardogłowość starych wyjadaczy...

Goto, jak każde narzędzie, może być użyteczne. No ale jest to ostre narzędzie dlatego młodym programistom mówi się żeby się nim nie bawili. Wyjątki w C++ też są fajne, lecz są jednym z głównych powodów dla których ciężko napisać w C++ jądro systemu operacyjnego (nie mówię że niemożliwe).

Sqward: tracing jit w V8 (engine JS w Chrome) powoli zbliża się do szybkości gcc, a nawet je przebija.

Sqward: nie Java ale JavaScript.
http://wingolog.org/archives/2011/06/10 … r-than-gcc
http://wingolog.org/tags/v8

No, jako że JS wymaga kompilacji, branie pod uwagę czasu kompilacji ma pewien sens. Benchmark może trochę syntetyczny ;) ale poczytaj w drugim linku - gościu naprawdę mądrze pisze.

co do mocy i to ciemnej strony mocy:

http://www.youtube.com/watch?v=xsymZCFz … re=related

dajcie sobie na luz

jellonek: js nie wymaga kompilacji per se, ale wszystkie najszybsze implementacje to kompilatory jit.

sliczne!

Ms wypuścił speca C++AMP

Te wszystkie wrappery na dane mogą być onieśmielające, ale nie ma nic za darmo :)

Idea jest taka, aby dać relatywnie proste w obsłudze i generyczne narzędzie do "masywnych" obliczeń, bez uciekania się do explicite heterogenicznych rozwiązań typu Cuda, OpenCL itd. Zapotrzebowanie jak widać jest, skoro wspomniane rozwiązania całkiem nieźle się rozwijają (np jakaś wersja gimpa używa chyba OpenCLa). C++AMP ma robić to samo, tylko bardziej kompaktowo, ukrywając tę heterogeniczność za parawanem runtime'u, tak, aby programista nie musiał zaprzątać sobie tym głowy. Rozwiązanie jest na tyle przyjazne, że w ramach prezentacji do jednego komputera włożyli jedną kartę nVidii i jedną ATI i program enumerujący akceleratory po prostu podzielił po równo obliczenia pomiędzy obie karty i to po prostu działało.

W przypadku gier przeważającym wg mnie argumentem przeciw temu rozwiązaniu mogłyby być istniejące powiązania pomiędzy bibliotekami. W Direct3D DirectCompute jest w naturalny sposób wpleciony w resztę potoku renderującego i chociażby żeby nie pisać specjalnych mechanizmów dbających o synchronizację i spójność danych łatwiej jest przeprowadzać obliczenia tak samo jak resztę renderowania właśnie za jego pomocą. Wydaje mi się, że podobnie jest w przypadku komba OpenGL + OpenCL. Ale przypuszczam, że C++AMP może wyprzeć CUDĘ, której targetem są właśnie takie obliczenia niezależne od grafiki, co w C++AMP robi się bardziej wprost.