On 2016-10-23 01:43, g...@g...com wrote:
> jednak tego łatwo się nauczyć. Ważniejsze jest wyrobienie intuicji
> dotyczących złożoności obliczeniowej. Tego się nie da łatwo
> przekazać w dokumentacji. A do wyrabiania tych intuicji Pascal
> nadaje się moim zdaniem całkiem dobrze.

To się da trywialnie pokazac w dokumentacji. Piszą że find ma log N i
tyle. Gwarantuje Ci że wiele algorytmów pisanych od zera jako kwadratowe
koła ma złe złożoności.

I nie jestem wrogiem pisania sortowania przez studenta. Jestem wrogiem
języka który *nie* ma innego wyboru jak tylko napisać od zera każdy byt
potrzebny do pracy. Pascal, wypisz, wymaluj.

>> Takie dwa misie jak pisali wyszukiwarkę google to naprawde nie mieli
>> pojecia jaka bedzie przyszłość. A pisali. Kretyni.
> Otóż to. Robili to, co wydawało im się w danym momencie
> najsensowniejsze. I założę się, że stawiali sobie po drodze
> różne cele, które następnie realizowali.

Celow nie da się zrealizować bo ich nie było, były tylko mętne,
nieosiągalne zarysy. Chyba że celem jest dominacja nad światem. To sie
udało.

>>> Zresztą taki np. SDCC, COSMIC czy uVision nie są, według mojej wiedzy,
>>> kompilatorami C++.
>> A clang/gcc jest? I dlaczego nie padły w tym wyliczeniu? I co to za
>> wyliczenie?
> GCC jest dostępne na army i na atmele, natomiast w embedded używa
> się różnych architektur, nawet tak archaicznych, jak 8051.

Serio? 8051 uzywa się gdziekolwiek poza domami starców? Serio, uważasz
że wyciąganie potworka w designie CPU z lat 70tych ma cokolwiek
udowadniać współcześnie? Czas 8051 odchodzi podobnie jak czas
programistów Pascala. Trzeba tylko poczekać i kupić troche dębowych pudełek.

Naprawdę, tłumaczenie że 8051 to przedstawiciel embedded to tłumaczenie
że Ford T to przedstawiciel motoryzacji. Obecnie embedded stoi wyłacznie
na ARMach które zebrały cały rynek i zostały tylko glitche i firmy z
Bytomia od produkcji najszybszych furmanek na świecie.

> W takim razie w jakich jeszcze dziedzinach C++ dominuje?

A co to ma wspólego z Pascalem? Dominue tam gdzie wymagana jest kontrola
na niskim poziomie i/lub wymagana jest wysoka abstrakcja. Można w nim
napisać zarówno mała aplikację pod AVR jak i poteżny program z
wypasionym GUI, zlożoną algorytmiką a w razie czego wyskalować go na
klastry obliczeniowe.

> Mam prośbę. Jeżeli uważasz, że C++ ma jakieś cechy, które miałyby
> się okazać przydatne w embedded, to byłoby więcej warte, gdybyś
> napisał, jakie to cechy, zamiast odnosić się do mojej rzekomej
> niewiedzy w tym temacie.

Pisałem o tym tak wiele razy na grupach (głównie pl.misc.elektronika) że
aż się odechciewa. Podsumuje jednak:
a) ścisłe typy. Większość embedded to zastanawianie się który #define
bitu pasuje do którego rejestru. W C++ problem solved, nie da się
popełnic tego błedu
b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
przerwania przy wychodzeniu w z funkcji" przestają istnieć.
c) Templatey. Pozawalają pisać kod *lepiej* dostosowany do platformy i
powodować że przenośność jest łatwiejsza.
d) Statyczny polimorfizm. Powoduje że mozna mieć abstrakcje bez narzutu
wydajność. Istotne kiedy wazny jest każdy cykl i kiedy projekt jest w
formie prototypowej.

> I uważam, że w kontekście embedded C++ to dużo narzutów i mało
> korzyści (a często nawet "korzyści ujemne", związane z dużo większym
> poziomem komplikacji języka)

Uważasz to samo co legacy programmers. Tak więc czekamy na rozwiązanie
biologiczne.