🚀 go-pugleaf

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1c4ok.bae.dozzie@hans.zsh.bash.org.pl...
>> 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.
> Sam dobierasz narzedzia do skali zadania, a innym zabraniasz.

Że co robię? Gdzie ja komukolwiek zabraniam czegokolwiek? Ja tylko
wyjaśniam, gdzie jest C++, a gdzie nie. I że C++ nie jest takim
masmem na sterydach.

>>> 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>).
[...]
>>> 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++.
> To Ty istoty sporu nie zrozumiałeś - w assemblerze mozna pisac tak samo
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> jak innych językach - kwestia makr.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Znowu ROTFL. I jak chcesz samymi makrami symulować klasy z obiektami?
A obliczenia leniwe? A funkcyjne? A co z programowaniem deklaratywnym?
Aha, i doczytaj o programowaniu funkcyjnym (albo funkcjonalnym; polska
terminologia nie jeszcze tu nie okrzepła) i deklaratywnym.
Hint: Haskell, SML, Prolog.
Albo nie, nawet nie. Pokaż mi, jakbyś chciał zrobić choć część kodu
pisanego w Perlu, Tclu albo Rubym. Przykładów poszukaj w sieci.

> C++ nie zwalnia od myślenia,
> assembler zmusza do myślenia to jedyna zasadnicza różnica.

Dla kogoś, kto nie używał C++, to i owszem, to jest jedyna większa
różnica. Dla kogoś, kto pisał w obu, C++ to coś znacznie więcej.

>>> 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ć.
> Brudne tricki kolidują z przenośnością, można je 'uaktywniać' w C,
> zlikwidowano to całkowicie w C++. Optymalizator dysponuje
> tylko określonym zbiorem reguł. Prawdziwa optymalizacja
> to zmiana algorytmu, a nie wyrzucenie zbędnych operacji.
> Typowe to np. wywalenie jakiejś instrukcji z wnętrza pętli
> na zewnątrz - w wielu przypadkach kompilator nie ma prawa
> tego zrobić np. w przypadku wywolania funkcji.

I co to ma wspólnego z optymalizacją na poziomie kodu assemblera?

-- 
Feel free to correct my English
Stanislaw Klekot