W dniu niedziela, 23 października 2016 10:15:03 UTC+2 użytkownik Sebastian Biały
napisał:
> > 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.

Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
Do wyjaśniania algorytmiki nadaje się dobrze.

> >> 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.

To akurat zawsze jest celem. Ale myślę, że po drodze mogły się pojawić
np. takie, jak ułatwienie wyszukiwania rzeczy w internecie.

> >>> 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.

Widzę, że trafiłem nie dość, że na jasnowidza, to jeszcze na
prawdziwego eksperta od embedded.
Otóż nie. ARMy to są w embedded duże procesory, używane przy
bardziej złożonych zastosowaniach. Do wielu prostych zastosowań
są po pierwsze zbyt kosztowne, a po drugie zbyt prądożerne.
Jeżeli projektujesz układ produkowany seryjnie i mający działać
na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
znaczenie.

Jeżeli idzie o owe 8051, to jest duńska firma, która produkuje
rozwiązania bezprzewodowej automatyki domowej (bardzo nota bene
popularne) oparte właśnie na tej architekturze, i niestety jeśli
chcesz móc dostosowywać ich rozwiązania do swoich celów, musisz
się z tym pogodzić. (Zresztą ich wybór nie był nieracjonalny,
ponieważ dla 8051 istnieją działające, sprawdzone narzędzia).
No, ale co ja tam wiem.

> > 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.

Rzeczywiście, brzmi jak real-life use case.

> > 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

Nie bardzo wiem, o czym piszesz z tymi "ścisłymi typami"
(ale w C++ da się popełnić każdy błąd, który da się popełnić w C)

> b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
> przerwania przy wychodzeniu w z funkcji" przestają istnieć.

Z jednej strony, podoba mi się, że C++ poniekąd wymusza
(czy też nakłania) wczesne myślenie o dealokacji zasobów.
Ale z drugiej strony to samo można osiągnąć korzystając
z odpowiednich makr preprocesora C.

> c) Templatey. Pozawalają pisać kod *lepiej* dostosowany do platformy i
> powodować że przenośność jest łatwiejsza.

To samo można zrobić w preprocesorze C, jeśli jest taka potrzeba.
(Tracisz co prawda bezpieczeństwo typów, ale jeżeli napiszesz sobie
dobre testy, nie jest to problemem w praktyce)

> > 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.

Rozumiem, że jako osoba żyjąca w przyszłości wiesz, co mówisz.

do góry

On 2016-10-23 11:07, g...@g...com wrote:
> Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
> Do wyjaśniania algorytmiki nadaje się dobrze.

Nie. Nadaje się równie dobrze jak każdy inny język. Dodatkowo kazy inny
język *współczesny* nadaje się do masy innych rzeczy. Dlaczego więc
używać do czegokolwiek Pascala? Jaką on ma zaletę? Otóż nie ma żadnej.
Każdy współczesny język potrafi to samo i o wiele więcej.

Odrzuć guru Bieleckiego, przejrzyj na oczy. Świat zmienił się zasadniczo
od bardzo wielu lat.

> Widzę, że trafiłem nie dość, że na jasnowidza, to jeszcze na
> prawdziwego eksperta od embedded.
> Otóż nie. ARMy to są w embedded duże procesory, używane przy
> bardziej złożonych zastosowaniach. Do wielu prostych zastosowań
> są po pierwsze zbyt kosztowne, a po drugie zbyt prądożerne.

Nieprawda. Koszt STM32, SAM7, LPC i innych rodzin ARM jest obsultnie
znikomy, rzędu ułamków dolara. Pobór prądu jest rownież ulamkowy z
powodu znacznie nowoczesniejszych metod zarzadzania mocą jak również z
powodu znacznie nowszego kodu maszynowego dzięki czemu mozna zrobić to
samo co na 8051 w mniejszej ilości cykli i pójść spać wcześniej.

Tak, troche się na tym znam. Na tyle żeby rozpoznawać sektę 8051 która
posluguje się głównie ignorancją zamiast argumentacją.

> Jeżeli projektujesz układ produkowany seryjnie i mający działać
> na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
> znaczenie.

I wtedy nie bierze się dziadowskiego 8051 tylko CPU przeznaczone do
kolsalnych zastosowań jak niski pobór prądu. Jest tego trochę na rynku.

> Jeżeli idzie o owe 8051, to jest duńska firma, która produkuje
> rozwiązania bezprzewodowej automatyki domowej (bardzo nota bene
> popularne) oparte właśnie na tej architekturze, i niestety jeśli
> chcesz móc dostosowywać ich rozwiązania do swoich celów, musisz
> się z tym pogodzić.

Straszne. Jest jakaś jedna duńska firma ktora wybrała Forda T joako
slużbowy? Straszne. To zmienia całkowicie świat motoryzacji.

> (Zresztą ich wybór nie był nieracjonalny,
> ponieważ dla 8051 istnieją działające, sprawdzone narzędzia).

ROFL. Przeciez mówiłem że problem rozwiązać można tylko na drodze
bilogicznej.

Co ciekawe za tego zdania wynika że na pozostałych architekturach co
najmniej mozna mieć wątpliwość w działające i sprawdzone rozwiązania.
Możesz podać przykłady np. tego że ARM jest niedziałający i
niesprawdzony? Że narzedzia popsute? Trzeba czym prędzej dać znać tym
milionom firm na świecie które w tym glupim ARMie klepią kod. Niesprawdzony!

> No, ale co ja tam wiem.

Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
mitami w celu usprawiedliwienia głupich wyborów.

>> 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.
> Rzeczywiście, brzmi jak real-life use case.

Zdziwisz się jakie rzeczy pisuje się na świecie. W PL również.

>> 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
> Nie bardzo wiem, o czym piszesz z tymi "ścisłymi typami"
> (ale w C++ da się popełnić każdy błąd, który da się popełnić w C)

Nie. Nie masz pojęcia o C++ i nie rozumiesz dlaczego tego błedu nie da
się popelnic jesli tylko zrezygnujesz z #define i zaczniesz pisać kod
silnie typowany.

>> b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
>> przerwania przy wychodzeniu w z funkcji" przestają istnieć.
> Z jednej strony, podoba mi się, że C++ poniekąd wymusza
> (czy też nakłania) wczesne myślenie o dealokacji zasobów.
> Ale z drugiej strony to samo można osiągnąć korzystając
> z odpowiednich makr preprocesora C.

Nie. Nie masz pojęcia o ogrniczeniach makr C skoro widzisz jakiekolwiek
analogie.

>> c) Templatey. Pozawalają pisać kod *lepiej* dostosowany do platformy i
>> powodować że przenośność jest łatwiejsza.
> To samo można zrobić w preprocesorze C, jeśli jest taka potrzeba.
> (Tracisz co prawda bezpieczeństwo typów, ale jeżeli napiszesz sobie
> dobre testy, nie jest to problemem w praktyce)

Nie. Nie masz pojęcia dlaczego tracenie czegokolwiek w imie religijnego
podejścia do C jest złem.

> Rozumiem, że jako osoba żyjąca w przyszłości wiesz, co mówisz.

Niezupełnie. Do ciebie faktycznie jestem z przyszłości skoro wyjmujesz
40-letnią technologię i machasz nią mówiąz że nic lepszego nie
wymyślono. Sorry, wymyślono. Kwestia pozbycia się ignorancji,
doczytania, kupienia kilku płytek ewaluacyjnych i poczekania aż koledzy
... no wiadomo.

do góry

On Sun, 23 Oct 2016 02:07:31 -0700 (PDT), g...@g...com
wrote:
> Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
> Do wyjaśniania algorytmiki nadaje się dobrze.

A dlaczego do wyjaśniania algorytmiki nie nadaje się Ada?

do góry

On Sun, 23 Oct 2016 02:07:31 -0700 (PDT), g...@g...com
wrote:
> Otóż nie. ARMy to są w embedded duże procesory, uż=
> ywane przy
> bardziej złożonych zastosowaniach. Do wielu prostych zastosowa?=




> są po pierwsze zbyt kosztowne, a po drugie zbyt prądożerne.
> Jeżeli projektujesz układ produkowany seryjnie i mający dzia=
> łać
> na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
> znaczenie.

Owszem. I dlatego taki np. Atmega 328p. I da się go w C++. Zresztą
ten 8051 też da się w C++.

do góry

On Sun, 23 Oct 2016 02:07:31 -0700 (PDT), g...@g...com
wrote:
> Jeżeli idzie o owe 8051, to jest duńska firma, która produku=
> je
> rozwiązania bezprzewodowej automatyki domowej (bardzo nota bene
> popularne) oparte właśnie na tej architekturze, i niestety je?=
> ?li
> chcesz móc dostosowywać ich rozwiązania do swoich celów=
> , musisz
> się z tym pogodzić. (Zresztą ich wybór nie był nie=
> racjonalny,
> ponieważ dla 8051 istnieją działające, sprawdzone narz=
> ędzia).

Już samo "musisz" powinno wykluczyć. A sprawdzone narzędzia istnieją
do prawie wszystkiego.

do góry

On Sun, 23 Oct 2016 02:07:31 -0700 (PDT), g...@g...com
wrote:
> Ale z drugiej strony to samo można osiągnąć korzystaj=
> ąc
> z odpowiednich makr preprocesora C.

Każdy dół da się wykopać łopatą. Kanał Sueski tak zrobiono!

do góry

On Sun, 23 Oct 2016 10:19:46 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> C nic nie miał od początku. To goły jezyk do mieszania wskaźnikami i

I to akurat jest fajne. Sam C nie ma nic. Ale są biblioteki. I ma
wszystko. Na przykład qsort. Albo curses. Albo całe API do Widozy.
Albo jakaś popaprana biblioteka akurat do tego czegoś co ci
potrzebne.

do góry

W dniu niedziela, 23 października 2016 11:22:27 UTC+2 użytkownik Sebastian Biały
napisał:
> > Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
> > Do wyjaśniania algorytmiki nadaje się dobrze.
>
> Nie. Nadaje się równie dobrze jak każdy inny język. Dodatkowo kazy inny
> język *współczesny* nadaje się do masy innych rzeczy. Dlaczego więc
> używać do czegokolwiek Pascala? Jaką on ma zaletę? Otóż nie ma żadnej.
> Każdy współczesny język potrafi to samo i o wiele więcej.
>
> Odrzuć guru Bieleckiego, przejrzyj na oczy. Świat zmienił się zasadniczo
> od bardzo wielu lat.

Jakiego Bieleckiego? W Pascalu ostatni raz programowałem 15 lat temu.
(A obecnie najchętniej programuję w języku, który jest jego równolatkiem)

> > Jeżeli projektujesz układ produkowany seryjnie i mający działać
> > na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
> > znaczenie.
>
> I wtedy nie bierze się dziadowskiego 8051 tylko CPU przeznaczone do
> kolsalnych zastosowań jak niski pobór prądu. Jest tego trochę na rynku.

Owszem. I raczej nie chodzi to na armach. Texas Instruments
np. daje swój kompilator do mspków. I ogólniej, łatwiej stworzyć
autorski kompilator C, niż C++.

> > Jeżeli idzie o owe 8051, to jest duńska firma, która produkuje
> > rozwiązania bezprzewodowej automatyki domowej (bardzo nota bene
> > popularne) oparte właśnie na tej architekturze, i niestety jeśli
> > chcesz móc dostosowywać ich rozwiązania do swoich celów, musisz
> > się z tym pogodzić.
>
> Straszne. Jest jakaś jedna duńska firma ktora wybrała Forda T joako
> slużbowy? Straszne. To zmienia całkowicie świat motoryzacji.

Nie o to chodzi. Jeżeli chcesz korzystać z ich protokołu komunikacyjnego
(który jest dość popularnym standardem), musisz używać ich czipów.
A wtedy możesz oczywiście dodawać swojego czipa, który komunikuje
się z ich czipem po uarcie, albo -- jeżeli logika jest prosta i zmieści
się w dostepnej pamięci -- możesz zmodyfikować program dostarczony
przez nich. A przy milionie wyprodukowanych sztuk Twoje ćwierć
dolara to będzie ćwierć miliona dolarów. No niestety, taki biznes.

> Co ciekawe za tego zdania wynika że na pozostałych architekturach co
> najmniej mozna mieć wątpliwość w działające i sprawdzone rozwiązania.
> Możesz podać przykłady np. tego że ARM jest niedziałający i
> niesprawdzony? Że narzedzia popsute? Trzeba czym prędzej dać znać tym
> milionom firm na świecie które w tym glupim ARMie klepią kod. Niesprawdzony!

Nie. ARM byłby w tym przypadku overkillem.
Ogólnie ARM to jest bardzo dobra architektura, ale nie nadaje
się do wszystkiego -- w niektórych zastosowaniach jest zbyt
kosztowna albo zbyt prądożerna.

> > No, ale co ja tam wiem.
>
> Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
> mitami w celu usprawiedliwienia głupich wyborów.

Z całym szacunkiem, ale ton, w jakim się do mnie odnosisz, jest
obraźliwy, a Twoje stwierdzenie całkowicie niemerytoryczne.
Żeby określić, że jakiś wybór jest "głupi", trzeba mieć nieco
większą wiedzę odnośnie okoliczności, w jakich był dokonywany.

> >> 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
> > Nie bardzo wiem, o czym piszesz z tymi "ścisłymi typami"
> > (ale w C++ da się popełnić każdy błąd, który da się popełnić w C)
>
> Nie. Nie masz pojęcia o C++ i nie rozumiesz dlaczego tego błedu nie da
> się popelnic jesli tylko zrezygnujesz z #define i zaczniesz pisać kod
> silnie typowany.

Ależ rozumiem. Zazwyczaj jeżeli widzę define'y tam, gdzie
mogłyby być użyte enumy, szukam tego, który to zrobił.
Zasmuca mnie to, że pola bitowe w C są tak źle obsługiwane
(i rzeczywiście w C++ można to z pewnością zrobić lepiej)

> >> b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
> >> przerwania przy wychodzeniu w z funkcji" przestają istnieć.
> > Z jednej strony, podoba mi się, że C++ poniekąd wymusza
> > (czy też nakłania) wczesne myślenie o dealokacji zasobów.
> > Ale z drugiej strony to samo można osiągnąć korzystając
> > z odpowiednich makr preprocesora C.
>
> Nie. Nie masz pojęcia o ogrniczeniach makr C skoro widzisz jakiekolwiek
> analogie.

A może to Ty nie masz pomysłu na to, jak użyć makr dla osiągnięcia tego celu?
Na przykład, mam takie makra w kodzie w C (nie-embedded):
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/video.h?at=default&
fileviewer=file-view-default#video.h-16

i jeżeli chcę sobie użyć zasobu, nie martwiąc się o jego dealokację,
robię to w taki sposób:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/image.c?at=default&
fileviewer=file-view-default#image.c-573

ten sam cel jest osiągnięty. Czy coś pominąłem?

> >> c) Templatey. Pozawalajązpisać kod *lepiej* dostosowany do platformy i
> >> powodować że przenośność jest łatwiejsza.
> > To samo można zrobić w preprocesorze C, jeśli jest taka potrzeba.
> > (Tracisz co prawda bezpieczeństwo typów, ale jeżeli napiszesz sobie
> > dobre testy, nie jest to problemem w praktyce)
>
> Nie. Nie masz pojęcia dlaczego tracenie czegokolwiek w imie religijnego
> podejścia do C jest złem.

Raczej mam wrażenie, że to Ty masz religijne podejście do C++.
Ja po prostu mam świadomość, że kompilatory C++ nie są dostępne
na wielu systemach, z którymi jest mi dane pracować, i wiem,
że to się nie zmieni.

> > Rozumiem, że jako osoba żyjąca w przyszłości wiesz, co mówisz.
>
> Niezupełnie. Do ciebie faktycznie jestem z przyszłości skoro wyjmujesz
> 40-letnią technologię i machasz nią mówiąz że nic lepszego nie
> wymyślono.

Cały czas mam wrażenie, że przypisujesz mi rzeczy, których
nie powiedziałem.
Ja mówię tylko tyle, że środki należy dobierać do celów.

A co do Twojego argumentu z biologii, to spodziewam się, że
pierwotniaki wyginą jako ostatnie.

do góry

On Sun, 23 Oct 2016 03:41:53 -0700 (PDT), g...@g...com
wrote:
> np. daje swój kompilator do mspków. I ogólniej, łatwiej=
> stworzyć
> autorski kompilator C, niż C++.

Mit.

Tworzysz kompilator C. Bierzesz kompilator C++ napisany w C.
Kompilujesz. Masz kompilator C++.

do góry

On 2016-10-23 12:41, g...@g...com wrote:
>> I wtedy nie bierze się dziadowskiego 8051 tylko CPU przeznaczone do
>> kolsalnych zastosowań jak niski pobór prądu. Jest tego trochę na rynku.
> Owszem. I raczej nie chodzi to na armach. Texas Instruments
> np. daje swój kompilator do mspków. I ogólniej, łatwiej stworzyć
> autorski kompilator C, niż C++.

No i masz dokladnie to oczy mówie. Vendor-lockin. Twoj program pisany
pod 8051 albo MSP i stosuje idiotyczne niestandardowe konstrukcje
wynikające albo z ograniczeń hardware albo imbecylizmu programistów
kompilatora albo z powodu dobrze przemyślanego planu marketingowego.
Bierze ARMa - problemów nie ma, przynajmniej nie w takiej skali. Ale
ARMa nie bierzesz bo wierzysz w teorie spiskowe popularne wśrod legacy
programmers.

> Nie o to chodzi. Jeżeli chcesz korzystać z ich protokołu komunikacyjnego
> (który jest dość popularnym standardem), musisz używać ich czipów.

To sugeruje żeby sobie je wsadzili w dupę skoro nie są w stanie
dostarczyć algorytmu generycznego kompilowalnego na byle czym. Czy już
wspominałem że programiści embedded są głównie skansenem technik
programowania z lat 60tych? Dlaczego muszę? Czy ten czip musze
oprogramować? Musi być 8051 na czytaniu danych?

> A wtedy możesz oczywiście dodawać swojego czipa, który komunikuje
> się z ich czipem po uarcie, albo -- jeżeli logika jest prosta i zmieści
> się w dostepnej pamięci -- możesz zmodyfikować program dostarczony
> przez nich. A przy milionie wyprodukowanych sztuk Twoje ćwierć
> dolara to będzie ćwierć miliona dolarów. No niestety, taki biznes.

Chcesz powiedzieć że 8051 kosztuje mniej niż ćwierć dolara i że ma to
jakiekolwiek znaczenie przy produkcji urzadzeń gdzie cała reszta jest o
kilka rzedów droższa?

> Nie. ARM byłby w tym przypadku overkillem.

Wyjaśnij dlaczego. Jest szybszy więc oszczędza prąd. Jest wygodniejszy
bo są kompiltory wspóczesnych jezyków. Jest rownie drogi/tani co 8051.
Ma lepsze narzedzia debugowe. Projektowany poza Intelem więc nie jest
obarczony kretynizmami. W czym jest overkillem?

> Ogólnie ARM to jest bardzo dobra architektura, ale nie nadaje
> się do wszystkiego -- w niektórych zastosowaniach jest zbyt
> kosztowna albo zbyt prądożerna.

Już Ci wyjaśnilem że mówisz głupoty. 8051 jest bodaj najbardziej
prądożerną architekurą z powodu clk/12. Kiedy 8051 wlasnie zabiera się
za obsługę przerwania, AVR, PIC, ARM już dawno ją zakończyły i poszły spać.

>> Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
>> mitami w celu usprawiedliwienia głupich wyborów.
> Z całym szacunkiem, ale ton, w jakim się do mnie odnosisz, jest
> obraźliwy, a Twoje stwierdzenie całkowicie niemerytoryczne.
> Żeby określić, że jakiś wybór jest "głupi", trzeba mieć nieco
> większą wiedzę odnośnie okoliczności, w jakich był dokonywany.

Oczywiście, dlatego wniskując nad ogólnym "8051 przydaje się w
plikacjach o malym poborze prądu" można się tylko puknąć w głowę i to
solidnie. Napisz o szczegołach, z chęcią zobaczę ten *argument* który
powoduje że 8051 jest lepsze bezwzglednie od czegokolwiek innego. Tak
wiem, bo kod już był napisany. Badziewie-lockin. Takie zycie i ja to
nawet rozumiem.

>> Nie. Nie masz pojęcia o C++ i nie rozumiesz dlaczego tego błedu nie da
>> się popelnic jesli tylko zrezygnujesz z #define i zaczniesz pisać kod
>> silnie typowany.
> Ależ rozumiem. Zazwyczaj jeżeli widzę define'y tam, gdzie
> mogłyby być użyte enumy, szukam tego, który to zrobił.

Nie chodzi o enumy.

> Zasmuca mnie to, że pola bitowe w C są tak źle obsługiwane
> (i rzeczywiście w C++ można to z pewnością zrobić lepiej)

Nie chodzi o pola bitowe.

> A może to Ty nie masz pomysłu na to, jak użyć makr dla osiągnięcia tego celu?
> Na przykład, mam takie makra w kodzie w C (nie-embedded):
> https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/video.h?at=default&
fileviewer=file-view-default#video.h-16

To nie działa jak RAII. To działa pi razy drzwi jak opakowanie funkcji w
niewidzialną funkcję. Ma dokładnie takie wady jak napisanie tego
ręcznie. Zrob z action jakieś return. Albo lepiej goto, ulubiny szit
embedowców.

> i jeżeli chcę sobie użyć zasobu, nie martwiąc się o jego dealokację,
> robię to w taki sposób:
> https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/image.c?at=default&
fileviewer=file-view-default#image.c-573
> ten sam cel jest osiągnięty. Czy coś pominąłem?

Tak. RAII i pojęcie scope.

> Raczej mam wrażenie, że to Ty masz religijne podejście do C++.

Pragmatyczne.

> Ja po prostu mam świadomość, że kompilatory C++ nie są dostępne
> na wielu systemach, z którymi jest mi dane pracować, i wiem,
> że to się nie zmieni.

Nie. Wybierasz idiotyczna architekturę 8051 na podstwie mitów i bajek a
potem narzekasz że nie ma tam kompilatora. Tak, na to nic nie da sie
poradzić. Dębowe pudełko, położyć się i czekać.

> Ja mówię tylko tyle, że środki należy dobierać do celów.

Pascal nie jest środkiem dla jakiegokolwiek sensownego celu. 8051 nie
jest środkiem dla jakiegokolwiek sensownego celu. C nie jest środkiem
dla jakiegokolwiek sensownego celu.

To wszystko archeologia. I doskonale sobie zdaje sprawę że Duńczycy mają
takie same firmy jakie my mamy w Bytomiu. I bardzo dobrze, media mają o
czym pisać a świat ma przynajmniej poczucie że pojecia dna można znowu
przesunąc nieco niżej.

> A co do Twojego argumentu z biologii, to spodziewam się, że
> pierwotniaki wyginą jako ostatnie.

O jak miło :D

do góry