> > W częście "krytycznej" konkurentem dla C nie jest C++, tylko Ada/SPARK, ale
branża nie zdąży tego konkursu rozstrzygnąć, bo prędzej przestawi się na kompletną
generację kodu a wtedy nie będzie znaczenia, w czym.

> Z branza motoryzacyjna i lotnicza kolega sie myli - w tym przypadku embeded system
sa programowane w wiekszosci w Matlab/Simulik (bo daje mozliwosc symulacji
zastosowanych algorytmow) i docelowy kod jest generowany w C.

Dokładnie o tym pisałem powyżej. Przeczytaj jeszcze raz.
Natomiast co do tej "większości" to bym nie szarżował. Na razie branża jest na etapie
wniosku, że to jest dobry kierunek na przyszłość. Dopiero wtedy (w przyszłości) może
to będzie większość - ale niekoniecznie Simulink i niekoniecznie C.

> C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z
uzyciem QT najczesciej)

Co oznacza, że szansą dla C++ są gotowe biblioteki i frameworki, bo o sam język dla
języka nikt walczyć nie będzie. Swoją drogą właśnie tak to zadziałało z Arduino.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> > To "C++" w Arduino równie dobrze mogłoby być Javą
>
> Nie.

Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku. Ma się po prostu
fajnie pisać i mają być gotowe biblioteki do pierdyliona "shieldów".
Zamienisz im C++ na Javę/łotewer i nawet im powieka nie mrugnie. To miałem na myśli.

Natomiast:

> Narzut na prosty procesor jest za duży.

Mówimy o Arduino. O branży, gdzie antenka do wifi ma w sobie uC N razy silniejszy od
głównego "procesora", który do tej antenki wysyła polecenia i nikogo to nie dziwi. O
branży, gdzie ludziom jest wszystko jedno, czy mają AVR czy Cortex-M4, bo diodą mruga
się tak samo fajnie. O branży, gdzie niektóre płytki mają Linuksa (!) udającego, że
jest AVRem i też mruga diodą - i też nikogo to nie dziwi.
Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu?

A z biegiem lat ta nisza niezauważająca różnicy będzie coraz większa. Za parę lat
będziesz miał w czajniku Linuksa z Javą udającą AVRa sterującego wyłacznikiem i
nikogo to nie będzie dziwiło.
Że będą nisze, gdzie to się nie stanie? Oczywiście - ale tak jak na desktopach i
serwerach, to będą coraz mniejsze, choć dobrze ustalone, nisze (i w tych niszach
będzie też przeciwnik w postaci VHDL).

> > W części "krytycznej" C++ nie wnosi niczego istotnego, bo to, co jest jego
obiektywną wartością dodaną
> > i tak nie obniża wymaganego wysiłku weryfikacyjnego a tego jest większość w całym
cyklu życia projektu.
>
> To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące
> ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na
> etapie unit testów, jak i przy głupiej kompilacji.

Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++. A
kompilacja nie jest czynnością weryfikacyjną, wręcz przeciwnie - to ją trzeba
weryfikować i to właśnie w C++ ten etap jest trudniejszy.
(mówimy o branży krytycznej)

> > To oznacza, że o ile w "normalnym" programie takie rzeczy jak RAII czy nawet sama
kontrola widoczności są cenne
> >, to w systemie krytycznym ich zbawczy wpływ w kontekście całego
> projektu jest znacznie mniejszy.
>
> Zawsze możesz przedstawić przykład dlaczego mniejszy.

Powyżej. Przykładowo, testy nie będą zależały od tego, w czym napiszesz kod. Być może
zaoszczędzisz trochę na pokryciu strukturalnym (bo kodu będzie trochę mniej), ale
dokładnie tyle samo stracisz na wykazaniu ciągłości kompilacji, bo kodu wynikowego
będzie odpowiednio więcej w stosunku do źródłowego. Dlatego fakt, że C++
automatycznie zawoła jakiś tam destruktor nie oszczędza wysiłku związanego ze
sprawdzeniem, czy akcja z tego destruktora się faktycznie wykonała. Ten wysiłek jest
ciągle taki sam.
(mówimy o branży krytycznej)

Natomiast w branży rozrywkowej oczywiście C++ ma przewagę, taką samą jak na desktopie
czy na serwerze. Problem w tym, że dokładnie tak samo będzie musiał zmierzyć się z
Javą (lub czymś jeszcze innym - jakieś Swifty, Rusty czy co tam jest teraz modne).
Dlatego rynek embedded wcale nie będzie dla C++ łatwiejszy.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2016-10-25 00:01, Maciej Sobczak wrote:
> Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku.

To nie jest prawda. Zależy im na jakości, redukjci bugów itp. Język C
tego nie zapewnia. Jezyk C++ załatwia część problemów. Java generuje
nowe (jak brak deterministycznego zachowania). Czekamy na Język
Ostateczny. Chwilowo brak.

> Ma się po prostu fajnie pisać i mają być gotowe biblioteki do pierdyliona
"shieldów".
> Zamienisz im C++ na Javę/łotewer i nawet im powieka nie mrugnie. To miałem na
myśli.

W sumie jest to o tyle istotne że C jest gorszy od czegokolwiek. Więc
być może zmiana na łotewer będzie i tak pozytywna.

>> Narzut na prosty procesor jest za duży.
> Mówimy o Arduino. O branży, gdzie antenka do wifi ma w sobie uC N
> razy silniejszy od głównego "procesora", który do tej antenki wysyła polecenia i
nikogo to nie dziwi.

W srodku takiej antenki ESP8266 siedzi *mały* ARM. Dalej Java się nie
zmieści (tak wiem że zmieści się na AVR ale to już nie jest Java).

> O branży, gdzie ludziom jest wszystko jedno, czy mają AVR czy Cortex-M4, bo diodą
mruga się tak samo fajnie.

Problem w tym że na żadnym z tych CPU w przypadku deterministycznego
zchowania programu, zagadnień RT itp. bedzie bardzo cieżko zmienić na
Jave. Nawet do migania diodą się taka java nie nadaje.

> O branży, gdzie niektóre płytki mają Linuksa (!) udającego
>, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi.

R-Pi to nie jest do końca embedded. Istnieje jakaś mętna granica kiedy
SoC staje się zwykłym komputerem. Wydaje sie że R-Pi z Linuxem jest poza
ta granicą.

> Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu?

Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.

Nie uogólniaj embedded tylko do mocy obliczeniowej. Istnieją zagadnienia
któych nie da się rozwiązać większym cpu.

> A z biegiem lat ta nisza niezauważająca różnicy będzie coraz większa.
> Za parę lat będziesz miał w czajniku Linuksa z Javą udającą AVRa sterującego
wyłacznikiem i nikogo to nie będzie dziwiło.

Problem w tym że słyszałem to po raz pierwszy około roku 2000. Nie od
wróżbity tylko od człowieka który znał doskonale rynek, zawodowo parał
się projektowaniem i budową calkiem sporych systemow embedded. Jak każdą
wrózbę można było ją sobie wsadzić w d... Świat jest pełen ARMów z
obciętymi ficzerami typu M0 i jest na to od groma rynku a Javy nie
sposób odpalić. I NIC nie wskazuje na zmianę w kierunku większych
prędkości i mocy obliczeniowych. Embedded które to potrzebuje to jest
jakaś część, ale nie dominująca. Jazelle umarło zanim ktokolwiek go użył.

Za parę lat ... czyli nigdy. Zawsze będzie przestrzeń na jakieś małe cpu
które mają specjalne cechy nie spotykane w duzym świecie.

Jakieś 10 lat temu było pełno wróżbitów którzy mówili że "już za pare
lat" CPU połaczy się z FPGA. No i się połaczył jako Zynq który ma
absurdalne ceny, idiotyczne narzędzia i maluteńki rynek zbytu. Reszta
wybiera zwykłe ARMy, AVRy PICe i jakoś nic nie wskazuje żeby nagle
pokochali FPGA posklejane z ARMem za $x00 kiedy osobno kosztują $x.

Dochodzi do absurdów kiedy chińska firma reanimowała 6502, wsadziła w
otoczenie peryferiów i sprzedaje (MegaWin). Jest rynek.

Powstrzymałbym się z tymi wrózbami co będzie za pare lat. Nic nie
będzie, będzie po staremu.

> Że będą nisze, gdzie to się nie stanie?
> Oczywiście - ale tak jak na desktopach i serwerach, to będą coraz mniejsze
>, choć dobrze ustalone, nisze (i w tych niszach będzie też przeciwnik
w postaci VHDL).

Niszą na razie jest używanie Linuxa jako bazy w mikrokontrolerach. Za
kilka lat będzie miał takie same wady jak dzisiaj.

>> To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące
>> ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na
>> etapie unit testów, jak i przy głupiej kompilacji.
> Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w C++.

Implementacja testów zalezy od tego. Implementacja testów w C jest
znacznie bardziej kłopotliwa niż w C++. Pewno że mozna powiedzieć że
"implementacja to szczegół". Zerknij jednak na UVM. Z tego "szczegółu"
zrobiono ogromna filozofię która *coś* znacząco poprawiła w jakości.

> A kompilacja nie jest czynnością weryfikacyjną, wręcz przeciwnie
> - to ją trzeba weryfikować i to właśnie w C++ ten etap jest trudniejszy.
> (mówimy o branży krytycznej)

Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem
skarpetek developera że nie ma sensu mówić o tym co w niej samodzielnie
wyewoluuje. Nic, do momentu aż komitety certyfikujące nie pozwolą. Nie
rozumiem jak tak hermetyczne i toksyczne środowisko ma niby być tłem dla
dyskucji o ewolucji embedded.

> Powyżej. Przykładowo, testy nie będą zależały od tego, w czym napiszesz kod.

Będzie zależała ich implementacja.

> Być może zaoszczędzisz trochę na pokryciu strukturalnym (bo kodu będzie trochę
mniej)
>, ale dokładnie tyle samo stracisz na wykazaniu ciągłości kompilacji
>, bo kodu wynikowego będzie odpowiednio więcej w stosunku do źródłowego.

Niby dlaczeog uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie
go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji.
Statyczy polimorfizm to jedna z prostych metod osiągnięcia perfekcyjnej
długości kodu dla produkjci i testowania.

> Dlatego fakt, że C++ automatycznie zawoła jakiś tam destruktor nie oszczędza
> wysiłku związanego ze sprawdzeniem, czy akcja z tego destruktora się
faktycznie wykonała.

Tu musisz mieć zaufanie do kompilatora lub certyfikaty dupochronne. Nie
tak dawno temu pewna firma robiąca dla wojska miała w standardzie obok
MISRA rowniez własne zalecenia w których było żeby nie uzywać jakiejśtam
konstrukcji językowej bo kompilator popsuty, ale certyfikowany.

Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w
sprawdzenie? A nie wkładasz go przypadkiem znacznie więcej kiedy musisz
sprawdzić czy programista wywołał tą akcję w każdym miejscu?

> Ten wysiłek jest ciągle taki sam.
> (mówimy o branży krytycznej)

Nie. Kiedy kompilator wykonuje swoje zadania w sposob pewny - wysiłek
jest mniejszy. Mozna nie mieć zaufania do kompilatora. Trudno, co robić,
można tez kopać rowy albo przeglądać wynikowy kod maszynowy co na jedno
wychodzi.

do góry

> > Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku.
>
> To nie jest prawda.

Nie zależy im na języku. Zobacz ich ostatnią nowinkę, ESLOV[*]. Na stronach słowo
"C++" nie pojawia się ani razu. Przypuszczam, że a) twórcy nie chcą się przywiązywać
do tego wyboru, b) odbiorcom to wisi.

[*] https://blog.arduino.cc/2016/09/28/eslov-is-the-amaz
ing-new-iot-invention-kit-from-arduino/

> Zależy im na jakości, redukjci bugów itp.

I właśnie dlatego (z powyższego linku):

"Draw the connections between the modules on the editor, and watch your project come
to life."

Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.
Jak już pisałem, branża przestawi się na generację kodu wcześniej, niż rozstrzygnie
wojnę o wyższość C, C++ czy Ady.

> > O branży, gdzie niektóre płytki mają Linuksa (!) udającego
> >, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi.
>
> R-Pi to nie jest do końca embedded.

Nawet mi do głowy nie przyszedł. RPi jest bardziej odpowiednikiem dawniejszych
Commodere 64, na których ludzie robili "automatykę domową" i inne mrugające choinki.
Dzisiaj ich dzieci mają do tego samego celu R-Pi.

Ja miałem na myśli raczej Intel Galileo - bo pracuje się z tym tak samo, jak z
Arduino. Bierzesz swój "sketch", który przed chwilą działał na Arduino Uno, wybierasz
w menu "Target board -> Galileo", wciskasz guzik "Upload" i Twoja płytka mruga diodą.
Tego Linuksa na tej płytce nie widać, on pełni bardziej funkcję firmware'u i właśnie
o tym pisałem - postęp w HW pozwala takie rzeczy robić a odbiorców to nie dziwi.

> > Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu?
>
> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.

Ta nisza to może być pojedynczy procent całego rynku embedded. Może przegapiłeś, ale
obecnie istnieje coś z miliard (albo dwa) urządzeń wbudowanych z Javą. Niektórzy
nazywają je smartfonami.
Masz w domu tony systemów embedded. Szybkość odpowiedzi na przerwanie jest istotna
tylko w... no nie wiem w ilu z nich. Ta nisza oczywiście będzie istnieć, ale to
będzie nisza a nie dominacja.

> Problem w tym że słyszałem to po raz pierwszy około roku 2000.

Właśnie od tamtego czasu wyprodukowano ten miliard (albo dwa) smartfonów z Javą.
Niedawno widziałem... lustro domowe z Androidem. Pokazuje prognozę pogody, akurat
wtedy, gdy się ubierasz. Fajne, nie?

> Powstrzymałbym się z tymi wrózbami co będzie za pare lat. Nic nie
> będzie, będzie po staremu.

Ale przecież to Ty twierdziłeś, że coś się zmieni w temacie użycia C++. Zmieniłeś
zdanie? :-)

> > Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w
C++.
>
> Implementacja testów zalezy od tego.

Testy pisze się z wymagań.

> Implementacja testów w C jest
> znacznie bardziej kłopotliwa niż w C++.

Nie. Jeżeli wymaganie mówi, że lampka ma zgasnąć, to z punktu widzenia testu, który
jest pisany z tego wymagania, nie ma znaczenia, czy lampka będzie zgaszona w C przez
jawne wywołanie jakiejś funkcji, czy w C++ przez destruktor jakiegoś kończącego życie
obiektu jakiegoś wrappera RAII.
To jest ten sam test. I to właśnie tam jest wysiłek w sprawdzeniu tego, że lampka
zgaśnie.

> Pewno że mozna powiedzieć że
> "implementacja to szczegół".

Z punktu widzenia testu tak właśnie jest.

> Zerknij jednak na UVM.

Nie miałem przyjemności. Z powierzchownej lektury wynika, że to jest metodologia,
którę mogę sobie zdownloadować z internetu. I chyba nie dotyczy dyskusji C vs. C++
(vs. Ada (vs. Java)).

> Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem
> skarpetek developera

Wręcz przeciwnie. Zdumiewająco mało określa. Nawet nie narzuca języka programowania.
Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.

> Nie
> rozumiem jak tak hermetyczne i toksyczne środowisko ma niby być tłem dla
> dyskucji o ewolucji embedded.

Bo niektóre urządzenia embedded są krytyczne?
W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?

[znowu o testach]
> Niby dlaczego uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie
> go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji.

Właśnie to mam na myśli. Kodu wynikowego będzie tyle ile trzeba, ale ponieważ kodu
źródłowego będzie mniej (RAII, itd.), to w rezultacie będzie więcej kodu wynikowego
*w stosunku* do źródłowego. I właśnie ten większy stosunek utrudni weryfikację. Bo w
branży krytycznej musisz wykazać ciągłość metody inżynierskiej a im większy skok
pomiędzy kolejnymi artefaktami w łańcuchu, tym trudniej tą ciągłość wykazać.
Właśnie dlatego C++ nie jest aż tak atrakcyjny dla branży krytycznej, jak w
rozrywkowej, gdzie zmniejszenie ilości kodu albo wsparcie kompilatora są oczywistą
wartością dodaną i dla której tak bardzo lubimy C++.
Problem w tym, że w branży krytycznej te argumenty nie działają.

> Tu musisz mieć zaufanie do kompilatora lub certyfikaty dupochronne.

Bingo. Doszliśmy do najciekawszego.
Otóż kompilator C jest znacznie prostszy konstrukcyjnie od C++. Dlatego istnieją
kwalifikowane kompilatory C, natomiast o takowym dla C++ nie słyszałem (przyjmijmy,
że wybór jest mniejszy). I teraz masz wybór:

1. piszesz w C i korzystasz z kwalifikowanego kompilatora C, który oszczędza kupę
wysiłku weryfikacyjnego
2. piszesz w C++ i przy braku kwalifikowanego kompilatora C++ robisz weryfikację kodu
wynikowego, co kosztuje Cię kupę czasu (i pieniędzy).

Którą opcję wybierasz?

Szach-mat.

> Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w
> sprawdzenie?

Tak. Sorry, taka branża.

> A nie wkładasz go przypadkiem znacznie więcej kiedy musisz
> sprawdzić czy programista wywołał tą akcję w każdym miejscu?

Testy są pisane z wymagań i to od nich zależy ten wysiłek.

> Mozna nie mieć zaufania do kompilatora. Trudno, co robić,
> można tez kopać rowy albo przeglądać wynikowy kod maszynowy co na jedno
> wychodzi.

Sorry, taka branża.

Do wyboru jest też Java (i takie tam), w branży rozrywkowej.
Prognoza pogody w lustrze, fajna sprawa. :-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2016-10-25 11:32, Maciej Sobczak wrote:
> I właśnie dlatego (z powyższego linku):
> "Draw the connections between the modules on the editor, and watch your project
come to life."

Był kiedys taki kawałek kodu o nazwie LabView. Kiedys siedziałem, koło
2000 roku, na jakiejś konferencji i prelegentowi aż piana leciała z ust
kiedy wymieniał wszelakie zalety takiego rysowania algorytmiki. Nie to
żeby pracował w TI, najzwyczajniejszy habilitowany bez pojecia o czym
mówi jak to zazwyczaj bywa. "I juz za rok nie bedzie trzeba nic
programować". Ta...

Swoją drogą znam kolesia który w tym pisywał gdzieś koło 2007.
Przesiadywał po kilka godzin nad projektem żeby "jakoś narysować ta
pętlę". Ewentualne refaktorowanie kosztowało uszkodzenie prawego nadgarstka.

Bez watpienia mamy do czynienia z przyszłościową technologią. Nastepna
proszę!

> Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.

Po LabView widac że strasznie zmniejszyło od 15 lat. O jakiś pewno
promil projektów.

> Jak już pisałem, branża przestawi się na generację kodu wcześniej, niż rozstrzygnie
wojnę o wyższość C, C++ czy Ady.

No ale jakos od 15 lat się nie daje rady przestawić. Widać nie ta
rzeczywistość.

> Ja miałem na myśli raczej Intel Galileo - bo pracuje się z tym tak samo, jak z
Arduino. Bierzesz swój "sketch"
>, który przed chwilą działał na Arduino Uno, wybierasz w menu "Target board ->
Galileo", wciskasz guzik "Upload"
> i Twoja płytka mruga diodą. Tego Linuksa na tej płytce nie widać, on pełni bardziej
funkcję firmware'u
> i właśnie o tym pisałem - postęp w HW pozwala takie rzeczy robić a odbiorców to nie
dziwi.

I ten projekt w Arduino to w czym napisano?

>> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.
> Ta nisza to może być pojedynczy procent całego rynku embedded.

IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded.

> Może przegapiłeś

Tak, głupi jestem, to wiem.

>, ale obecnie istnieje coś z miliard (albo dwa) urządzeń wbudowanych z Javą.
Niektórzy nazywają je smartfonami.

Dziękuję. Ale żeby sarkazm stosować to trzeba jednak umieć.

> Masz w domu tony systemów embedded.

Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
dlaczego miałbym to nazywać embedded. Czy jak do mojego peceta dokleje
monitor i klawiaturę to tez bedzie embedded?

> Szybkość odpowiedzi na przerwanie jest istotna tylko w... no nie wiem w ilu z nich.

Bo to pecety a nie embedded o którym tu mowa.

> Ta nisza oczywiście będzie istnieć, ale to będzie nisza a nie dominacja.

Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym
falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy.

> Niedawno widziałem... lustro domowe z Androidem. Pokazuje prognozę pogody, akurat
wtedy, gdy się ubierasz. Fajne, nie?

Jak tam wstawie płytę na iTX z Atomem to będzie embedded czy blaszak?
Zawieszenie peceta na ścianie to już embedded?

> Ale przecież to Ty twierdziłeś, że coś się zmieni w temacie użycia C++. Zmieniłeś
zdanie? :-)

Twierdze że będzie ewolucja C do C++. Nic C/C++ nie zastapi na skale
masową. Nie ma jak. Chwilowo ewolucjia jest blokowana, ale na szczęscie
natura rozwiązuje ten problem powoli i metodycznie.

>>> Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w
C++.
>> Implementacja testów zalezy od tego.
> Testy pisze się z wymagań.

Dalej mówisz jak typowy managier. Się pisze testy. A w czym?
Doswiadczenia z Verilog/Vhdl pokazują że to jest *zasadnicze* pytanie.
Decyduje o tak szerokim spektrum przyszłych problemów że nie da się go
zbyć byle jaką odpowiedzią.

>> Implementacja testów w C jest
>> znacznie bardziej kłopotliwa niż w C++.
> Nie. Jeżeli wymaganie mówi, że lampka ma zgasnąć, to z punktu widzenia testu
>, który jest pisany z tego wymagania, nie ma znaczenia, czy lampka będzie zgaszona w
C
> przez jawne wywołanie jakiejś funkcji, czy w C++ przez destruktor jakiegoś
kończącego życie obiektu jakiegoś wrappera RAII.

Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod
w C woła właściwą funkcję jest znacznie trudniejsze niż w C++. Dla
managera to żadna różnica, dla implementatora testu to różnica
*zasadnicza* która rzutuje na jakośc testowania. W skrajnym wypadku
sadza się jednostę białkową która nacicka przycisk jak się zapali bo ...
bo język nie pozwala na inne wykrycie.

Tak, ta jednostka białkowa tez jest potrzebna, ale dopiero na końcowym
etapie.

> To jest ten sam test. I to właśnie tam jest wysiłek w sprawdzeniu tego, że lampka
zgaśnie.

Ale możesz ten wysilek zautomatyzować mniej lub bardziej. Możesz nawet
wziąć książkę do teori testowania i zastanowić się jak podzielić ścieżkę
testowania na piramidę gdzie na samym dole jest tak wiele testów że
wymagane jest dostrzeżenie *jak* je implementować.

Nie rób z siebie takiego teoretyka. Implementacja unit testowania jest
na tyle złożonym problemem że nie można jej pomijąc głupim "się jakos
napisze". Ludzie od Veriloga od przynajmniej 10 lat wyprówają sobie żyły
żeby to robić właśnie w tym szczególe lepiej bo kazalo się że tam
przynosi to wymierne korzyści. Na tyle że obecnie testowanie bazujące na
tych szczegółach trzęsie rynkiem i jest wymogiem stawianym w krytycznych
aplikacjach.

>> "implementacja to szczegół".
> Z punktu widzenia testu tak właśnie jest.

No więc teoretyzujesz lub posiadasz toskyczne środowisko testowania w
którym czas implementacji testu jest już na tyle długi że nie ma
znaczenia jak jest stworzony. Coś jest popsute.

>> Zerknij jednak na UVM.
> Nie miałem przyjemności. Z powierzchownej lektury wynika, że to jest metodologia

To jest *implementacja* pewnej metodologii.

>, którę mogę sobie zdownloadować z internetu. I chyba nie dotyczy dyskusji C vs. C++
(vs. Ada (vs. Java)).

Ależ dotyczy wszystkiego, a w szczególności dotyczy "się jakoś napisze
te testy". Masz przykład (obecnie tip top światowy) że ktoś się pochylil
nad tymi szczegółami i okazalo się że można znaczaco podnieść komfort i
jakośc weryfikacji. Szczegóły miały znaczenie, kwestia dostrzeżenia ich
z wysokich stołków managerów od słupków w PowerPoincie.

>> Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem
>> skarpetek developera
> Wręcz przeciwnie. Zdumiewająco mało określa. Nawet nie narzuca języka
programowania.

Narzuca bardzo wiele. Być może rozmawiamy o róznych dziedzinach. Gdybyś
poszedł w kierunku latania z fpga ilość rzeczy
organizacyjno-implementacyjnych które musisz spelnić aby w ogole
rozmawiać jest zastanawiająca i dotycza może nie koloru skarpetek ale
niewiele brakuje.

> Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.

To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++.
To nie jest trywializm. To tylko oznacza że możesz z C++ wziąć to co w
danej chwili wyraża lepiej rozwiązanie problemu.

> Bo niektóre urządzenia embedded są krytyczne?
> W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?

Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z
druga osobowością?

> [znowu o testach]
>> Niby dlaczego uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie
>> go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji.
> Właśnie to mam na myśli. Kodu wynikowego będzie tyle ile trzeba
>, ale ponieważ kodu źródłowego będzie mniej (RAII, itd.),
> to w rezultacie będzie więcej kodu wynikowego *w stosunku* do źródłowego.

Podstawową zasadą przy redukcji bugow jest trzymanie się jak
najmniejszej ilości kodu źrodlowego i jak najczytelniejszego wyrażania
zamiarów. Ponieważ w ten sposób programista popełnia mniej błedów. Język
C musi być wspomagany przez makra, język C++ pozwala na wyrażanie wprost
w mniejszei ilości kodu.

> I właśnie ten większy stosunek utrudni weryfikację

Nieprawda. Weryfikację utrudnia cieżki do czytania kod, kłopotliwe
implementowanie testów i kiepski związek kodu (rysowanie z LabView) z
wynikiem (generowany C).

Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
templates mialo byc przeszkodą weryfikacyjną i traktowane jako miara
jakości. Po stronie kodu jest 10x mniej czytania i 10x czytelniej i 3x
mniej unit testów.

>. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej

Pomiędzy jednym a drugim masz kompilator. Możesz wygazać formalnie jego
działanie? FORMALNIE. Jesli nie to musisz za każdym razem sprawdzać kod
w C z kodem w asm. Ręcznie. No chyba że oszukujesz i te wszystkie nadęte
pojęcia o ciągłości są po prostu ponaginane że aż trzeszczy i podparte
zbutwiałymi certyfikatami?

> a im większy skok pomiędzy kolejnymi artefaktami w łańcuchu, tym trudniej tą
ciągłość wykazać.

Ale jak ją wykazujesz? Pomiędzy A i B użylismy kompilatora X? No no.
Robi wrażenie. Na managerach.

> Problem w tym, że w branży krytycznej te argumenty nie działają.

Z powodu biologi i komitetów certyfikujących a nie rozsądku.

> Bingo. Doszliśmy do najciekawszego.
> Otóż kompilator C jest znacznie prostszy konstrukcyjnie od C++.
> Dlatego istnieją kwalifikowane kompilatory C

Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
C z wielką dziurą. Zaznaczam przy okazji że w tym czasie kiedy oni w nim
pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów. I nie
oznacza to że należy wziąć gcc. Oznacza to że certyfikowany kompilator
okazał się polem minowym. "Jakoś(ć) przez certyfikację".

>, natomiast o takowym dla C++ nie słyszałem (przyjmijmy, że wybór jest mniejszy). I
teraz masz wybór:
> 1. piszesz w C i korzystasz z kwalifikowanego kompilatora C, który oszczędza kupę
wysiłku weryfikacyjnego

Nie oszczędzę. Bugi pochodzace z kompilatorów to promil promila problemu
bugow w ogólności.

> 2. piszesz w C++ i przy braku kwalifikowanego kompilatora C++
> robisz weryfikację kodu wynikowego, co kosztuje Cię kupę czasu (i pieniędzy).
> Którą opcję wybierasz?

Taką w ktorej jestem w stanie szybciej wykryć bugi w kodzie. C jest
drugi a C++ przedostatni.

> Szach-mat.

To nie jest szach mat. Piszesz o embedded tak jak Ci w danej chwili
pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
certyfikowane produkty wczesnej archeologii inzynieri programowania w
której ludzie rysują kreski od kodu w C do kodu w asm. Nie masz
certyfikowanej ciąglości wypowiedzi ...

>> Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w
>> sprawdzenie?
> Tak. Sorry, taka branża.

Ten promil embedded czy te miliardy smartfonów?

Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
promila aplikacji embedded obwarowanymi certyfikatami i komitetami
wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. A przy
okazji jesli chodzi o Pascala ...

do góry

On Tuesday, October 25, 2016 at 12:27:51 PM UTC+2, Sebastian Biały wrote:

> > I właśnie dlatego (z powyższego linku):
> > "Draw the connections between the modules on the editor, and watch your project
come to life."
>
> Był kiedys taki kawałek kodu o nazwie LabView.

Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach
embedded. Pokazuję Ci, co ci amatorzy teraz robią. Zgadnij, co będą robić za parę
lat. Pisać szablony w C++?

> > Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.
>
> Po LabView widac

Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów.

> No ale jakos od 15 lat się nie daje rady przestawić.

Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku.
Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach. To
się dzieje, niezależnie od tego, czy Ci się to podoba.

> >> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.
> > Ta nisza to może być pojedynczy procent całego rynku embedded.
>
> IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded.

Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się
pogodzić z postępem w hardwarze.
Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest system
embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego producenta
będzie mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo
specjaliści od embedded mają naruszone ego? No to sorry.

> Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
> dlaczego miałbym to nazywać embedded.

https://en.wikipedia.org/wiki/Embedded_system

> Czy jak do mojego peceta dokleje
> monitor i klawiaturę to tez bedzie embedded?

To zależy, czy będzie częścią większego produktu. Jeśli ten monitor i klawiatura są
akurat na frontowym panelu w samochodzie, to tak, ten pecet jest systemem embedded.
Sorry. Nie ja wymyśliłem definicję.

> Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym
> falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy.

Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową.

> > Testy pisze się z wymagań.
>
> Dalej mówisz jak typowy managier.

Nie, jestem inżynierem.

> Się pisze testy. A w czym?

Skup się: w Excelu.

(oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od
dyskusji nt. wyższości C++ nad C)

> Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod
> w C woła właściwą funkcję jest znacznie trudniejsze niż w C++.

Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś outpucie
ma być LOW (powiedzmy). Albo jakaś zmienna lub wartość w jakieś tablicy albo
strukturze ma być LOW. Itp. Zrobienie testu na takie coś nie zależy od tego, czy
ustawianie tej wartości jest w C czy w C++.

W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod i tym bardziej
wtedy widać, że robienie testu nie zależy od tego, czy gaszenie lampki jest w C, czy
w C++.

(Proszę nie mylić z TDD (Test-Driven Development), bo to nie to.)

[branża krytyczna]
> Narzuca bardzo wiele.

Na przykład?

> > Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.
>
> To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++.

Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu)
podzbiorem C++.
Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!).

> > Bo niektóre urządzenia embedded są krytyczne?
> > W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?
>
> Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z
> druga osobowością?

Uzupełniam:
Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na
przerwanie, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z
prognozą pogody. Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie
jest to system krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji.

> > I właśnie ten większy stosunek utrudni weryfikację
>
> Nieprawda. Weryfikację utrudnia cieżki do czytania kod,

Więc pisz kod łatwy do czytania. Standardy kodowania po to są.

> kłopotliwe
> implementowanie testów

Testy pisze się z wymagań. N-ty raz to powtarzam.

> i kiepski związek kodu (rysowanie z LabView) z
> wynikiem (generowany C).

Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C, bo w C++ jest większy
przeskok między kodem (źródłowym) a wynikiem (obiektowym).

> Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
> templates mialo byc przeszkodą weryfikacyjną

To jest tzw. total showstopper a nie przeszkoda.

> Po stronie kodu jest 10x mniej

Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu
jest 10x mniej. Gubisz się?

Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie
przybyło 20MB kodu wynikowego, to leżysz na weryfikacji.
Hasło: traceability.

> >. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej
>
> Pomiędzy jednym a drugim masz kompilator.

To jest nieciągłość.

> Możesz wygazać formalnie jego
> działanie?

Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie da
się gdy to jest kompilator w C.

Właśnie dlatego lepiej, żeby był C.

> Jesli nie to musisz za każdym razem sprawdzać kod
> w C z kodem w asm. Ręcznie.

Tak. Sorry, taka branża.

Dlatego łatwiej się to robi gdy kod źródłowy jest w C.
Naprawdę.

> Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
> C z wielką dziurą.

Nie ma problemu - certyfikował tą resztę wokół dziury.

> Zaznaczam przy okazji że w tym czasie kiedy oni w nim
> pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów.

Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału czasu,
żeby nie było bugów. Różnica jest taka, że w przypadku tego certyfikowanego wiedza o
tym gdzie są bugi (i jak trzeba pisać, żeby je ominąć) była większa.
Dlatego ten certyfikowany był bardziej odpowiedni w projekcie krytycznym.

> Bugi pochodzace z kompilatorów to promil promila problemu
> bugow w ogólności.

W branży rozrywkowej? Oczywiście.

Ale pisaliśmy o krytycznej.

> Piszesz o embedded tak jak Ci w danej chwili
> pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
> certyfikowane produkty

Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach...
Próbuję odpisywać wg bieżącego, zmiennego kontekstu.

> Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
> promila aplikacji embedded obwarowanymi certyfikatami i komitetami
> wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej.

Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej masie
rozrywkowych, z Javą w środku.
Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca.
Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++, którego nic
nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron.

W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak na
desktopie, z podobnych powodów.

> A przy
> okazji jesli chodzi o Pascala ...

Nie widziałem w embedded.

--
Maciej Sobczak * http://www.inspirel.com

do góry

Użytkownik "Sebastian Biały"

...
Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
promila aplikacji embedded obwarowanymi certyfikatami i komitetami
wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. A przy
okazji jesli chodzi o Pascala ...
---
Jeśli chodzi o Pascala to myślimy o Object Pascal czy Delphi i uznajemy go
za mało perspektywiczny, ale dobry język. Koniec kropka.

do góry

On 2016-10-25 16:10, Maciej Sobczak wrote:
>>> I właśnie dlatego (z powyższego linku):
>>> "Draw the connections between the modules on the editor, and watch your project
come to life."
>> Był kiedys taki kawałek kodu o nazwie LabView.
> Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach
embedded.
> Pokazuję Ci, co ci amatorzy teraz robią.

Adruino. Takiego ruchu amatorow na rynku uC nie było nigdy.

> Zgadnij, co będą robić za parę lat. Pisać szablony w C++?

No. Mniej więcej. Moze nawet mniej bo biologia nie jest aż tak okrutna.

>>> Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.
>> Po LabView widac
> Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów.

No, to widać po obu. Moving on.

>> No ale jakos od 15 lat się nie daje rady przestawić.
> Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku.
> Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach.
> To się dzieje, niezależnie od tego, czy Ci się to podoba.

Alez niech się dzieje. Tylko nic z tego nie wynika. LV nie dał rady
zdominować nawet procenta rynku. Złosliwi twierdzą że jak by sprzedawali
hardware za 1/10 ceny to może. Jestem pewny że co kilka lat ktoś musi
przeprowadzić nastepną kompletną rewolucję na rynku embedded po której
zostanie jak zwykle tylko troche rozrzuconych papierków po miętówkach na
sali konferencyjnej. Moving on.

>>>> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.
>>> Ta nisza to może być pojedynczy procent całego rynku embedded.
>> IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded.
> Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się
pogodzić z postępem w hardwarze.

Ale to nie jest postęp że masz coraz szybsze procesory *wszedzie* bo w
ogromnej i ignorowanej przez Ciebie części procesory nie zmieniają
prędkości na wieksze. Ba, odchudzają się z ficzerów, zmienia rdzenie na
urposzczone, dodaje hardware pozwalające zrobić coś sprzetowo itd. Takie
do migania diodą i sterowania silnikiem pralki. Przypuszczalnie ten
rynek to kilka rzedów więcej niż sterowników czarnych skrzynek w
samolotach które uważasz za istotny w tej dyskusji (a ja komiczny).

> Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest
system embedded.
> Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego
producenta będzie
> mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo
specjaliści od
> embedded mają naruszone ego? No to sorry.

Pokaż gdzie jest granica. Używanie hasła embedded do wszystkiego traci
sens tej rozmowy. Smartfony to już jest wszystko, bo po drugiej stronie
siedzi AtTiny13 i nijak nie ma tutaj zadnej analogii czegokolwiek a w/g
Ciebie to jest wszystko embedded. Oczekuje że mój laptop jak tylko go
podniosę można nazwac smartfonem a mój pecet po wsadzeniu akku i
monitore na taśmie to będzie laptopem.

>> Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
>> dlaczego miałbym to nazywać embedded.
> https://en.wikipedia.org/wiki/Embedded_system

I to lusterko ze smarfonem spełnia tą definicje? Smarfon spełnia tą
definicję?

>> Czy jak do mojego peceta dokleje
>> monitor i klawiaturę to tez bedzie embedded?
> To zależy, czy będzie częścią większego produktu.

Jak dokleje jeszcze lusterko to już będzie embedded? A jak takie duże to
już? A jak za tym lusterkime będzie monitor to już?

> Jeśli ten monitor i klawiatura są akurat na frontowym panelu w samochodzie
>, to tak, ten pecet jest systemem embedded. Sorry. Nie ja wymyśliłem
definicję.

To nie jest kwesia czy w samochdozie masz embeddeed tylko czy te
miliardy telefonów z java są embedded czy są mniejszymi pecetami? A może
nie ma róznicy i powinniśmy tą rozmowę nie prowadzić o embedded tylko o
mikrokontolerach? To zaraz przyjdzie jakiś misio i zacznie gadać o tym
że SoC to taki uC tylko większy itd itp.

Wyciągasz sobie z embedded dośc szeroki zakres hardware i rzucasz nim tu
i tam jak wygodniej. OK, trudno, co robić. Głuopia definicja to i głupie
trolowanie.

>> Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym
>> falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy.
> Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową.

Ich jest całkiem sporo. O dziwo nie pracuje zawodowo jako programista
embedded.

>> Się pisze testy. A w czym?
> Skup się: w Excelu.
> (oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od
dyskusji nt. wyższości C++ nad C)

Interesujące. A w czym sie je implementuje? Zapewne to już nie jest
istotne? A może masz na mysli systemy kontroli specyfikacji i testowania
które z *faktycznym* testowaniem mają tyle wspólnego co referencja z
bazy danych?

>> Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod
>> w C woła właściwą funkcję jest znacznie trudniejsze niż w C++.
> Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś
outpucie ma być LOW (powiedzmy).
> Albo jakaś zmienna lub wartość w jakieś tablicy albo strukturze ma być LOW. Itp.
> Zrobienie testu na takie coś nie zależy od tego, czy ustawianie tej wartości jest w
C czy w C++.

Zależy. W końcu ktoś kiedyś fizycznie musi to coś odczytać z przestrzeni
w której działa C/C++.

> W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod

Nie uzywaj aż takich oczywistości.

> i tym bardziej wtedy widać, że robienie testu nie zależy od tego, czy gaszenie
lampki jest w C, czy w C++.

Dalej nie wyjasnileś jak ten test czyta ten LOW. To jest *istotne* i gdy
zrozumiesz dlaczego UVM trzęsie światem FPGA zrozumiesz rownież dlaczego
jest istotne *jak* się tam implementuje testy i dlaczego 10 lat trwało
dojście do tego. Tak, w aplikacjach krytycznych też.

>> Narzuca bardzo wiele.
> Na przykład?

Na przykład metodykę testowania od dupereli jak raporty, przez sledzenie
specyfikacji po precyzyjne informacje jak testować na poziomie
implementacji pojedynczych machnięć drutami.

>>> Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.
>> To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++.
> Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu)
podzbiorem C++.
> Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!).

Nie, ponieważ w C emulujesz zachowania ktore w C++ masz OOTB. Na tym
polega róznica. Na tym że legacy programmers w C *emulują* zachowania
C++ jak RAII. I to *trzeba* testować intensywniej niż wypociny
kompilatora. Bo wypociny jednostek białkowych są z definicji popsute
*bardziej* niż wypociny kompilatora.

>>> Bo niektóre urządzenia embedded są krytyczne?
>>> W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?
>> Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z
>> druga osobowością?
> Uzupełniam:
> Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na
przerwanie
>, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z prognozą
pogody.

Interesujące. Przecietny DMA w byleczym wymaga krytycznego czasu
odpowiedzi na przerwanie. Od mówiącej chińskiej lalki po sterownik dysku
w klastrze. DMA jest wszedzie poza 8051 i AVR. I wszedzie masz
zagadnienie RT. Oczywiście zawsze można ściemniać że zajmie się tym VM
Javy a kod za to odpowiedzialny piszą krasnoludki.

> Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie jest to system
> krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji.

Najłatwiejsze narzedzia weryfikacji do C nie istnieją. To nie ten język.
C++ też nie.

Był kiedyś taki język e przeznaczony tylko do testowania o świetlanej
przyszłości. Niewiele można na ten temat znaleźć bo to raczej radosna
twórczość hindusów. Całkowicie poświęcony byciem abstrakcyjnym względem
implementacji i języka ktory testuje. Obecnie można książkami na jego
temat palić w kominku a i to krótko bo była jedna i chyba tyle. Ale za
to ile szumu, konferencji i posterów!

>>> I właśnie ten większy stosunek utrudni weryfikację
>> Nieprawda. Weryfikację utrudnia cieżki do czytania kod,
> Więc pisz kod łatwy do czytania. Standardy kodowania po to są.

Standard kodowania nie czyni kodu latwiejszym w czytaniu na poziomie
algorytmiki. Cieżko popelnić bład jedną spacją za dużo więc standardy
kodowania w niewielkim stopniu wpływają na generację błedów przez
programiste. Wpływa czytelność a więc rozumienie co autor mial na myśli.
W typowych wypocinach embedded zazwyczaj oznacza to przeczesanie sześciu
makr do emulacji RAII zmielone z #define na przemian z #include do
emulacji template.

>> kłopotliwe
>> implementowanie testów
> Testy pisze się z wymagań. N-ty raz to powtarzam.

Jak typowy menager: piszcie tak zeby było dobrze.

>> i kiepski związek kodu (rysowanie z LabView) z
>> wynikiem (generowany C).
> Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C
>, bo w C++ jest większy przeskok między kodem (źródłowym) a wynikiem (obiektowym).

Ide o zakład że nie weryfikujesz tego związku żadnym narzedziem i to
tylko puste hasła. W przypadku językow HDL taka weryfikacja zazwyczaj
oznacza wykonanie tych samych czynności na dwóch symulatorach roznych
producentów i komapracje wyników. I to wcale nie oznacza że choć jeden
jest dobry. To nic nie oznacza. Podnosi tylko jakość snu zespołu.

Przeciętny projekt fpga jest na tyle skomplikowany że nie da się go
zweryfikować dowolną metodą jaką znamy. Zakłada się pewien % jakości i tyle.

>> Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
>> templates mialo byc przeszkodą weryfikacyjną
> To jest tzw. total showstopper a nie przeszkoda.

Serio? A niby jak? Masz swój embedded z 2GB flash. program zajmuje po
kompilacji z 400MB. Każdy bajt Twoj zespół dronów sprawdził, czy zgadza
się z kodem źrodłowym. Teraz masz +20MB więcej. To przeciez tylko
kilkaset lat więcej sprawdzania bajt po bajcie. W czym widzisz problem?

>> Po stronie kodu jest 10x mniej
> Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu
jest 10x mniej. Gubisz się?

Kodu źródlowego mniej, kodu wynikowego więcej. Co poradze na to że to
kod i tamto kod?

> Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie
przybyło 20MB kodu wynikowego, to leżysz na weryfikacji.
> Hasło: traceability.

Puste. Dotyczy ono kodu źródlowego. Nie wynikowego.

Zaznacze też że w przypadku *ogromnych* projektów FPGA korzysta się
rownież z certyfikaowanych syntezerów i symulatorów. Naprawde myslisz że
ktokolwiek jak przybijał pieczatkę to mial pewnośc że takowy działa
poprawnie? Tego nawet w pojedynczym promilu nie da się stwierdzić.
Przechodza jakiś tam zestaw testów. Przejscie wszystkich ściezek jest
niemożliwe fizycznie. Ufa się na jakiś procent. Sorry, tak działa świat.
I co ważne: tam "kod wynikowy" to z grubsza sieć bramek. Każda synteza
robi ją inaczej. Powiedzmy że dostajesz milion bramek i dwa miliony
drutów. Drukujesz to na płachcie wielkości boiska i armia ludzi z lupami
ropoczyna proces weryfikacji. Tak, naprawdę. Zupełnie jak inni bajt po
bajcie oglądaja assembler po każdej kompilacji.

>>> . Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej
>> Pomiędzy jednym a drugim masz kompilator.
> To jest nieciągłość.

Więc jak rozumiem kompilujesz na kartce (notatnikowi tez bym nie ufał!).

>> Możesz wygazać formalnie jego
>> działanie?
> Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie
da się gdy to jest kompilator w C.

Ale możesz dla swojego? Ktoś to wykazał? Czy tylko ma pieczatkę?

> Właśnie dlatego lepiej, żeby był C.

Żadna roznica. I jeden i drugi nie jest mozliwy do weryfikacji. Bazujesz
na kompilatorze z pieczatką i tyle. Polepsza może to jakośc snu i
pozwala osiągnąc pewien poziom dupoochrony. Nie ma żadnej magicznej
ciągłosci na którą się powołujesz.

>> Jesli nie to musisz za każdym razem sprawdzać kod
>> w C z kodem w asm. Ręcznie.
> Tak. Sorry, taka branża.

Współczuje. Sprawdź czy nie czeka cie przyszlośc w kopaniu rowów. Z
prostej przyczyny: nie robicie tego. Ewentualnie robicie to w projektach
z gatunku miganie diodą gdzie to jest fizycznie możliwe.

> Dlatego łatwiej się to robi gdy kod źródłowy jest w C.
> Naprawdę.

Nie robicie tego lub robicie pierdołowate aplikacyjki. Tego nie da się
zrobić albo można mówić że się robi a oszukiwać (np. weryfikowac kawałek
i twierdzić bez podstaw że inne kawałki tego nie psują jak się zmienia kod).

>> Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
>> C z wielką dziurą.
> Nie ma problemu - certyfikował tą resztę wokół dziury.

Nie. Dziurę wykryto po certyfikacji. Bo tak ta certyfikacja wygląda.
Ziutek, na oko działa, przyp... pieczatkę, niech se zarobią. To na oko
to tysiące testów testujących może max kilka procent interakcji w
kompilatorze. Tylko testów tych testów nie ma. I ich testów.

Moment w którym mozna jeszcze bylo formalnie weryfikować kompilatory
czegokolwiek to chyba okolice lat 80tych. Natomiast chyba można ciągle
assemblery. Czy chciałbys może wyciągnąc z tego wniosek że pisanie w
asseblerze jest obaczone mniejszą iloscią błedów niż w C?

>> Zaznaczam przy okazji że w tym czasie kiedy oni w nim
>> pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów.
> Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału
czasu, żeby nie było bugów.

Zapomniałem dopisać: nie miał takich bugów. Chyba nie zakładasz że
jestem aż takim idiotą, co?

>> Bugi pochodzace z kompilatorów to promil promila problemu
>> bugow w ogólności.
> W branży rozrywkowej? Oczywiście.

W każdej. Od bardzo dawna. Już mineły lata 80te. Całkiem przyzwoite
kompilatory mamy.

>> Piszesz o embedded tak jak Ci w danej chwili
>> pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
>> certyfikowane produkty
> Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach...
Próbuję odpisywać wg bieżącego, zmiennego kontekstu.

Akuratnie falowniki i Atmega leża mniej więcej w tej samej przegródce.
Sam mam jeden na Atmega.

>> Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
>> promila aplikacji embedded obwarowanymi certyfikatami i komitetami
>> wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej.
> Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej
masie rozrywkowych, z Javą w środku.

Wiec po co argumenty z jednej strony przenosić na drugą? Czy któś uzywa
certyfikowanych kompialtorów do Javy? A może uzywa GC w apliakcja RT w
samolocie? Może i to embedded i tamto embedded ale przeciez to zupełnie
inne embedded!

> Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca.
> Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++

Ależ tam jest od groma miejsca. Widzisz świat z wlasnego krzesła. Troche
ruchu w lewo, w prawo. ARMy przejęły rynek, w wersjach miniaturowych.
Tam jest w cholere miejsca nawet na zombie 6502. jak wymyslisz za chwile
coś z rdzeniem AVR i ze 100 makrokomórkami to rynek wessa bez zająknięcia.

>, którego nic nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron.

Tak, od 15 lat.

> W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak
na desktopie, z podobnych powodów.

Tak na desktopie od 30 lat. Tu wróżbitów było więcej. Co roku coś nowego
jest rewolucją. Bitów szkoda.

>> A przy
>> okazji jesli chodzi o Pascala ...
> Nie widziałem w embedded.

Był. Niestety nie pomnę jaki, ale był. Autor twierdził że nic lepszego
na uC nie wymyślono. Zapamiętałem to bo wtedy łatwiej poznać.

do góry

On 2016-10-25 17:28, re wrote:
> Jeśli chodzi o Pascala to myślimy

Ale kto konkretnie?

do góry

Użytkownik "Maciej Sobczak"

...
> A przy
> okazji jesli chodzi o Pascala ...

Nie widziałem w embedded.
---
Czemu właściwie dyskutujesz ? Zobacz na temat. Ktoś podał tutaj środowisko
komercyjne do programowania 8051 itp w Pascalu.

do góry