On Sun, 13 Aug 2017 16:52:25 +0200, w systemie siła
'POPIS/EU<N...@g...pl> wrote:
> za czasów C++

Za czasów MSC 5.1 już była.

Prawdopodobnie wcześniej.

Dobry makroasembler plus np. Win API daje wygodę programowania
porównywalną z C. Ale kosztem przywiązania do konkretnego procesora.
Co w dzisiejszych czasach jest raczej głupie... jeżeli nie jest
absolutnie konieczne.

Zaletą C jest że to prawie asembler. Czyli można pisać bardzo nisko.
Wadą C++ (która na ładne parę lat zniechęciła mnie do C++) jest
obiecywanie cudów na kiju i jednocześnie kompilatory nie potrafiące
zrobić dzielenia, źle obsługujące goto, niezgodne ze standardem w
obie strony, wojenka MS z POSIX, bałagan z wide char i spieranie się
o .h jakby nie było ważniejszych rzeczy.

do góry

cwanie wybrnąłeś z sytuacji!

bo już miałem napisać - że był to czas pojawienia się w szkołach tzw.
"pań informatyczek"...

do góry

On Sun, 13 Aug 2017 18:44:48 +0200, w systemie siła
'POPIS/EU<N...@g...pl> wrote:
> "pań informatyczek"...

Znam osobiście przynajmniej jedną informatyczkę, która jest naprawdę
dobra w tym co robi.

do góry

może i tak, ale nie można o tym wszystkim rozmawiać bez uwzględniania $...

do góry

On Sunday, August 13, 2017 at 3:01:57 PM UTC+2, slawek wrote:
> Asembler dobrych CPU ma cudeńka (rejestry wektorowe, rozszerzenia
> instrukcji) normalnie nie używane przez kompilator.

Właśnie, że normalnie używane przez kompilatory. Jest taki
etap kompilacji "peep-hole optimization" - to w nim zastępuje
się wzorce rozkazów innymi, szybszymi. To tylko kwestia bazy
danych kompilator, co potrafi zmienić, a co nie.

Co do rejestrów wektorowych, to googlaj za autovectorization.
Parę lat temu ICC był w tym świetny, ale GCC i Clang już dawno
dogoniły; nawet kompilator MSVC już wie, jak wektoryzować kod
(znalazłem im buga z tym związanego, BTW).

w.

do góry

On Wed, 16 Aug 2017 09:47:15 -0700 (PDT), Wojciech
Muła<w...@g...com> wrote:
> jak wektoryzować kod
> (znalazłem im buga z tym związanego, BTW).

I to zniechęca do kompilacji, a przynajmniej do kompilacji czymś
skomplikowanym (C++). Co z tego że napiszesz coś ślicznie... że
zwektoryzowane... jak kompilator będzie miał akurat "buga".

Dlatego prymitywny Fortran jest tak lubiany. Bo jak coś było nie tak,
to jakieś 60 lat było na poprawienie.

do góry

> Dlatego prymitywny Fortran jest tak lubiany. Bo jak coś było nie tak, to
> jakieś 60 lat było na poprawienie.

Dlatego 25 letnie samochody są tak lubiane. Bo jak coś było nie tak, to
poprzedni właściciele mieli 25 lat na poprawienie ;-)

-
Pozdrawiam,
Mateusz Bogusz

do góry

On Wed, 16 Aug 2017 20:35:45 +0200, Mateusz Bogusz <m...@o...pl>
wrote:
> Dlatego 25 letnie samochody są tak lubiane.

Po pierwsze, gdybyś miał sprawny samochód sprzed 1914, to byłby on
więcej dziś wart niż nówka sztuka jakiegoś byle czego.

Po drugie, twierdzenie Pitagorasa jest starsze niż Fortran. A ciągle
się go używa.

Po trzecie, twój 15 letni samochód za rok będzie bardziej zużyty niż
rok temu. Będzie gorzej jeździć i częściej się psuł. Natomiast
kompilator którego używasz prawdopodobnie będzie nieco lepszy: być
może naprawione błędy, być może lepsza optymalizacja, poprawiona
zgodność ze standardem.


Od tysiącleci młodych, gniewnych, rewolucjonistów podnieca że
Wszechświat powstał wraz z ich narodzinami. Uważają to co było
wcześniej za nic niewarte, a nawet szkodliwe. Fortran jest w twoim
odczuciu szkodliwy, bo się spóźniłeś na czas gdy powstawał, gdy był
modny. A przecież trzeba być postępowym, mieć najnowszego ajfona i
programować w Rust. Cool. Luzik.

do góry

> Po pierwsze, gdybyś miał sprawny samochód sprzed 1914, to byłby on
> więcej dziś wart niż nówka sztuka jakiegoś byle czego.

Dla kogoś pewnie i tak, to wtedy by kupił.

> Po drugie, twierdzenie Pitagorasa jest starsze niż Fortran. A ciągle się
> go używa.

No właśnie. Używa wtedy kiedy potrzebne, a nie pieje że rozwiązuje
wszystkie problemy.

> Po trzecie, twój 15 letni samochód za rok będzie bardziej zużyty niż rok
> temu. Będzie gorzej jeździć i częściej się psuł. Natomiast kompilator
> którego używasz prawdopodobnie będzie nieco lepszy: być może naprawione
> błędy, być może lepsza optymalizacja, poprawiona zgodność ze standardem.

Z jeden strony piszesz, że kod ładnie "zwektoryzujesz", a z drugiej że
dobre tylko kompilatory sprzed 30 lat. To jak Ty chcesz te nowoczesne
instrukcje wykorzystać w Fortranie?

--
Pozdrawiam,
Mateusz Bogusz

do góry

Ja odnoszę wrażenie, że obecnie programiści nie za bardzo wiedzą jaki język jest na
prawdę najlepszy i myślą, że w zasadzie to najbardziej zależy od zastosowania. Bo w
większości wypadków nie ważne jest jak jest szybki - liczy się jak szybko da się coś
zakodować.

Ja natomiast mam inne zdanie na ten temat.

Moim zdaniem (porównując najpopularniejsze języki: Asembler, C, C++, D, Java, PHP,
Python, JavaScript - tyle poznałem i mi to wystarczy) okazuje się, że C++ jest
najlepszy. Oto powody:

1. Bez udziwnień obsługuje standardowe API obecnych systemów operacyjnych (czyli C).
D ma niby wsparcie dla funkcji C ale trzeba je zdeklarować w języku D.

2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele
innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień -
są to cechy naturalne tego języka. Tak więc nie jest uczciwe porównywanie tego języka
do Asemblera. Tu bym porównał raczej Asemblera do łopaty, a C++ do koparki, a języki
skryptowe do mini koparek.

3. Kompiluje się do kodu maszynowego i przez to działa w sposób naturalny - jak to
przewiduje producent procesora. Jego pliki wykonywalne są najmniejsze z możliwych, są
prawie tak szybkie jak programy asemblerowe i działają samodzielnie (wymagając
jedynie bibliotek dll - jeśli tak zostały skompilowane - a często wymaga tego
licencja biblioteki). Nie wymaga żadnego interpretera, ani żadnych "maszyn
wirtualnych" które nic nie dają prawdziwemu programiście (bo gdy do C++ przechodzi
się z Asemblera to ręczne zarządzanie pamięcią jest czymś naturalnym i intuicyjnym -
ja w ten sposób się uczyłem, bo to wydawało mi się najsensowniejsze i nadal tak mi
się wydaje). Poza tym obecnie w C++ zarządzanie pamięcią często ogranicza się do
podania "rodzica" jako parametr konstruktora i on usuwa ten nowy obiekt (Qt tak jest
zrobione), lub używa się "sprytnych wskaźników" które usuną obiekt kiedy trzeba (to
implementuje biblioteka standardowa).

4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h
które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w
innych (wymienionych) językach z wyjątkiem C.

5. Jest przenośny. Umiejętnie pisane programy (w Qt ;] ) są bez problemowo przenośne.
A kod nieprzenośny daje się izolować (można wyłączać całe pliki *.cpp i kompilować
warunkowo). Ta przenośność teoretycznie nie jest obarczona jakimś spadkiem wydajności
czy innymi ukrytymi kosztami. Teoretycznie programy C++ są przenośne na każdą
platformę na którą jest odpowiednio aktualny kompilator C++. Jednak ważniejszym
ograniczeniem jest wsparcie danej platformy przez dostawców bibliotek.

6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki
ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć
wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++...

do góry