🚀 go-pugleaf

On 14.03.2006, Daniel P. <nako@go2.i.do.not.like.spam.pl> wrote:
> Użytkownik Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam>
> w wiadomości <slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl> napisał:
>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>
> A czy naprawdę w każdym programie używasz tych wszystkich technik?

Nie. Tam, gdzie tego nie używam, używam C.

> IMHO w C++ jedynym poważnym usprawnieniem było wprowadzenie
> czegoś takiego jak string. Tego tylko brakowało mi w C.

To jakoś mało używasz C++, IMO. Mnie się podoba cała masa kontenerów
(biblioteka standardowa), odseparowanie reprezentacji danych od operacji
na nich wykonywanych, zwiększenie "code reusability" (OOP i szablony)
i coś, co się nazywa algorytmy uogólnione (#include <algorithm>).

> W ogóle nie rozumiem o co Wy się kłucicie.

A ja nie wiem, co to znaczy "kłucicie".

> Do czego innego służy asembler i do czego innego służą języki wyższego
> poziomu.

Zgadza się. I zupełnie inna jest konstrukcja języka tu i tam, czego
niektórzy nie mogą zrozumieć i uparcie twierdzą, że assembler nie różni
się za bardzo od C++.

> Asembler stosuje się wtedy, gdy naprawdę zależy nam na szybkości działana,
> ponieważ tylko wtedy możemy zoptymalizować program tak, aby działał on
> możliwie najszybciej.

Z tego co wiem, kompilator radzi sobie z optymalizacją dużo szybciej,
efektywniej i bardziej przenośnie od człowieka. Co zresztą dyktuje
zdrowy rozsądek: optymalizator pisał cały sztab ludzi stosujących
wszystkie brudne tricki, jakie da się wykorzystać.

-- 
Feel free to correct my English
Stanislaw Klekot