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