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