On 12 Cze, 16:07, "AK" <n...@n...com> wrote:
> A dlaczego by nie ? Ze niby "klasyczny" C++ szybszy/mniejszy znacznie ?
> PS: W dzisiejszych czasach wiara, że "klasycznie kompilowany" C++
> bedzie wyraznie szybszy od podejscia CLI/jbytecode/innego "kodu posredniego"
> jest przejawem nie tylko "wiedzy niedzielnej", ale wrecz wstecznictwa i braku
> nawet "krotkotrwalej" wyobrazni.

Java/C# mogą być tak samo szybkie jak C++ jeżeli program w C++
napisany jest w stylu Javy/C# ( co zresztą udowadniają liczne
benchmarki będące bezmyślną translacją jednego języka na drugi). Ja
już parę razy pisałem: szybkość działania JVM/.Net jest dla mnie
akceptowalna. Problemem jest dla mnie zużycie pamięci w tych
środowiskach ( w .Net może być mniejsze dzięki dobrej implementacji
generyków i dostępnych typów wartości ). I można sobie różne bajki
opowiadać, ale w C/C++ zawsze mam jakąś możliwość optymalizacji, np.
zmniejszenie rozmiaru obiektów przez pakowanie ich pól na bitach +
użycie indeksów do innych obiektów , bo przechowywanie wskaźnika na
64bitach jest kosztowne. A że tych obiektów było bardzo dużo ilość
zajmowanej pamięci spadła o 40%.
Zresztą zobacz co powiedział nie byle kto, bo autor F# na temat C++:
http://blog.achrissmith.com/2012/03/if-your-software
-matters-you-will-write.html

I i jeszcze, ponieważ zaraz usłyszę, że jestem wstecznych ayatollahem C
++. Chętnie powitałbym coś innego. Bez chorego systemu templejtów, z
lepszym postawieniem na bezpieczeństwo, z algebraicznymi typami
danych. Ale nie ma i prędko nie będzie.
Kibicuję językowi Rust ( http://www.rust-lang.org/ ) i Clay (http://
claylabs.com/clay/) ale obawiam się że skończy się to jak zawsze.

Pozdrawiam
KK