On Mon, 24 Oct 2016 08:06:42 +0200, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Bzdura - nie znając różnic między listą, a wektorem, czasami użycie
> niewłaściwego typu danych dla danego problemu zabije wydajność.
> Oczywiście, przy tworzeniu formatek w javie nie ma znaczenia, ale
> własnie w bardziej rozbudowanych problemach ma. Może być istotny
czas
> dostępu/fragmentacja pamięci/szybkość dodawania - więc należy
rozważyć
> wtedy który kontenerr będzie lepszy, ale by to wiedziec, trzeba
mieć
> choćby trochę informacji jak moga być one utworzone.

Aj aj.

Albo program działa, albo nie działa. Tzn. także osiągi.

Reszta to bicie piany przez teoretyków.

do góry

> > Nie spotkałem się z jego szerszym zastosowaniem w embedded
>
> Nie szukaj daleko: Arduino. Że amatorskie? Za chwile Ci amatorzy będa
> pracować dla firm robiących embedded.

Co nie znaczy, że dalej będą pisać w C++.
To "C++" w Arduino równie dobrze mogłoby być Javą, nawet bez wielkiej zmiany w
składni. I tym ludziom od Arduino nie zrobiłoby to żadnej różnicy.

To wcale nie jest takie oczywiste, że C++ będzie poważniej używane w embedzie.
Ogólnie i z obraźliwym zaokrągleniem, embedy można podzielić na:

- krytyczne
- rozrywkowe

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 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.
Stąd też znacznie mniejsza motywacja, żeby po C++ sięgnąć. Tak, jest MISRA-C++, ale
chyba wszyscy to olali.
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.

Natomiast w części "rozrywkowej" C++ nie zdąży wyprzeć obowiązującego obecnie C, bo
zanim się zorientujemy, to hardware będzie wspierał Javę albo coś z tej ligi. I cała
ta brać makersów z plecakami pełnymi prototypów na Arduino bez mrugnięcia okiem się
na to coś przestawi, bo z ich punktu widzenia język nie ma znaczenia, znaczenie mają
natomiast IDE oraz bogactwo frameworków do IoT.

> Ale biologia działa i
> wystarczy poczekać.

Sęk w tym, że hardware rozwija się szybciej, niż programiści C wymierają. To może
spowodować, że okno czasowe, w którym C++ miałby szansę na zdobycie istotnej części
rynku, może nie wystąpić. Czyli po C nastąpi od razu porzucenie kodu jako istotnego
artefaktu projektowego (w częśći "krytycznej") albo Java/łotewer (w części
"rozrywkowej").

Oczywiście nie twierdzę, że C++ nie będzie używany. Będzie. Prawdopodobnie branża
motoryzacyjna będzie jego głównym użytkownikiem, bo tam będzie presja na
wykorzystanie istniejącego kodu w C i są jakieś standardy jakości utrudniające
bezmyślne uzywanie Javy. Ale rynek embedded jest znacznie większy, niż samochody.

> Przeszkodą jest jedynie biologia, inercja i Linus Torvalds.

Trafne.

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

do góry

On Saturday, October 22, 2016 at 3:13:25 PM UTC-4, g...@g...com wrote:
> W dniu sobota, 22 października 2016 20:27:36 UTC+2 użytkownik Sebastian Biały
napisał:
>
> > > Co w takim razie jest w Pascalu takiego złego, tak konkretnie?
> >
> > Jego banalność. Nigdy nie był dostarczony z jakąkolwiek sensowną
> > bibliteka do algorytmiki. Stada studentów przez dziesięciolecia na
> > uczelniach pisały nastepny program do sortowania bąbelkowego, listy
> > dwukierunkowe, "bazy danych z uzyciem writeln", itp, zawsze w złym stylu
> > (np. na tablicach albo niegenerycznie). I tak w kółko, banały które
> > powinny być częścią języka.
>
> Mówisz poważnie? Ale masz świadomość, że powodem, dla którego
> owe stada studentów piszą programy do sortowania bąbelkowego,
> nie jest brak istniejących implementacji funkcji sortujących?
>
> Jeżeli idzie o wsparcie generyczności, to zgodzę się, że to
> istotnie jest problem przy tworzeniu dużych aplikacji (no i ja
> osobiście nie zalecałbym Pascala do tego celu).
>
> > Posiadanie pętli for i wskaźnika nie czyni z
> > języka przydatnego narzędzia. Czynią to bibliteki, wsparcie, przenośność
> > itp pierdoły czygo w Pascalu nie było bo *reszta* świata uważała go za
> > zabawkowy. Chyba tylko w PL zdobył jako taką popularnośc z przyczyn
> > politycznych. Dzisiaj mozna znaleźć głównie religijnych wyznawców że
> > Pascal był nalepszy do nauki. A g... prawda.
>
> To, o czym piszesz, nie jest "projektem języka", tylko
> jego ekosystemem. Pisałeś zaś, że Pascal jest przykładem
> "jak nie należy projektować języków", jakby w projekcie
> tego języka były popełnione jakieś fundamentalne błędy.
>
> > >> Rozmowa o przyszłości językow z przyszłościa ma sens. Pascal nie nalezy
> > >> do tej grupy od wieków. Delphi już nie od kilku lat.
> > > Niestety, przyszłości nie ma, jest tylko teraźniejszość, i tylko
> > > o niej możemy się sensownie wypowiadać.
> >
> > Wobec tego nie pracuj w IT. Praca jako programista-projektant polega na
> > bezustannym przewidywaniu przyszłości, niekiedy na lata.
>
> Dla mnie praca programisty do tej pory polegała na stawianiu sobie
> celów, określaniu problemów, które pojawiają się na drodze do tych
> celów, i następnie rozwiązywaniu tych problemów. Jak do tej pory
> całkiem się sprawdza, ale nie jestem w stanie Ci powiedzieć, co będzie
> w przyszłości.
>
> > > Jeżeli mówisz o języku C jako
> > > "używanym podczas ostatniego zlodowacenia", to najwidoczniej ignorujesz
> > > takie dziedziny, jak systemy wbudowane czy systemy operacyjne (które
> > > chyba nigdzie daleko się nie wybierają).
> >
> > Niczego nie ignoruje. Język C obecnie kompilowany jest kompilatorami C++
> > i powoli (w miare wymierania legacy programmers) coraz wiecej kodu
> > embedded łyka techniki programowania z C++.
>
> Bo C++ akurat jest przykładem tego, jak należy projektować języki.
> Niestety, C++ jest pod wieloma względami dużo gorszy od Pascala,
> bo nawet pozornie proste rzeczy okazują się okropnie skomplikowane,
> jak choćby obsługa stringów.
>
> Zresztą taki np. SDCC, COSMIC czy uVision nie są, według mojej wiedzy,
> kompilatorami C++.
>
> > Tak wiem, MISRA itp. Ale te
> > standardy były pisane kiedy jezyki były primitywne, jak C. C trzyma się
> > na rynku siłą inercji. Pozerkaj na około: kod embedded, najbardziej
> > odporny na zmiany okazał się miejscem gdzie C++ ma najwięcej do
> > powiedzenia.
>
> Z tego co wiem, C++ ma najwięcej do powiedzenia w programowaniu gier.
> Nie spotkałem się z jego szerszym zastosowaniem w embedded, i nie
> widzę praktycznie żadnych powodów, dla których miałby być stosowany
> w tej dziedzinie.
>
> > Wiec tylko musimy poczekać aż natura zrobi swoje.
> > Przeszkodą jest jedynie biologia, inercja i Linus Torvalds.
>
> Co ma Linus Torvalds do embedded?

Jak to widze z dyskusji to koledzy nie maja pojecia o programowaniu embeded.
W prostych embeded C jest nipodwazalnym krolem (chociaz czsami ten embeded C nie za
bardzo przypomina normalny C - tak wiele ograniczen jest narzuconych przez docelowa
platforme). W bardziej skomplikowanych zastosowaniach uzywa sie Matlab/Simulink z
docelowa generacja kodu do C. C++ na embeded uzywa sie najczescie do programowania
skomplikowanego GUI - i w wiekszosci przypadkow to nie jest czyste C++ ale QT

Pozdrawiam
Adam M.

do góry

On Monday, October 24, 2016 at 9:21:30 AM UTC-4, Maciej Sobczak wrote:
> > > Nie spotkałem się z jego szerszym zastosowaniem w embedded
> >
> > Nie szukaj daleko: Arduino. Że amatorskie? Za chwile Ci amatorzy będa
> > pracować dla firm robiących embedded.
>
> Co nie znaczy, że dalej będą pisać w C++.
> To "C++" w Arduino równie dobrze mogłoby być Javą, nawet bez wielkiej zmiany w
składni. I tym ludziom od Arduino nie zrobiłoby to żadnej różnicy.
>
> To wcale nie jest takie oczywiste, że C++ będzie poważniej używane w embedzie.
Ogólnie i z obraźliwym zaokrągleniem, embedy można podzielić na:
>
> - krytyczne
> - rozrywkowe
>
> 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 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. Stąd też znacznie mniejsza motywacja, żeby po C++ sięgnąć. Tak, jest
MISRA-C++, ale chyba wszyscy to olali.
> 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.
>
> Natomiast w części "rozrywkowej" C++ nie zdąży wyprzeć obowiązującego obecnie C, bo
zanim się zorientujemy, to hardware będzie wspierał Javę albo coś z tej ligi. I cała
ta brać makersów z plecakami pełnymi prototypów na Arduino bez mrugnięcia okiem się
na to coś przestawi, bo z ich punktu widzenia język nie ma znaczenia, znaczenie mają
natomiast IDE oraz bogactwo frameworków do IoT.
>
> > Ale biologia działa i
> > wystarczy poczekać.
>
> Sęk w tym, że hardware rozwija się szybciej, niż programiści C wymierają. To może
spowodować, że okno czasowe, w którym C++ miałby szansę na zdobycie istotnej części
rynku, może nie wystąpić. Czyli po C nastąpi od razu porzucenie kodu jako istotnego
artefaktu projektowego (w częśći "krytycznej") albo Java/łotewer (w części
"rozrywkowej").
>
> Oczywiście nie twierdzę, że C++ nie będzie używany. Będzie. Prawdopodobnie branża
motoryzacyjna będzie jego głównym użytkownikiem, bo tam będzie presja na
wykorzystanie istniejącego kodu w C i są jakieś standardy jakości utrudniające
bezmyślne uzywanie Javy. Ale rynek embedded jest znacznie większy, niż samochody.
>
> > Przeszkodą jest jedynie biologia, inercja i Linus Torvalds.
>
> Trafne.
>
> --
> Maciej Sobczak * http://www.inspirel.com

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. W C pisze sie tez niskopoziomowa i
czasow krytyczna obsluge np SPI i DMA. C++ najczesciej jest uzywany gdy zachodzi
potrzeba programowania ladnego GUI (z uzyciem QT najczesciej)

do góry

On 2016-10-24 15:29, Adam M wrote:
> Jak to widze z dyskusji to koledzy nie maja pojecia o programowaniu embeded.

Żebym ja dostawał złotówkę za każdego programiste embedded który mówi że
inni nie mają pojęcia o embedded...

> W prostych embeded C jest nipodwazalnym krolem

I kto twierdzi inaczej?

do góry

On 2016-10-24 08:06, Tomasz Kaczanowski wrote:
> Trochę pojechałeś... Nawet zaawansowanym programistom, nop Wujek Bob
> zaleca trening w pisaniu znanych algorytmów od czasu do czasu, nie po
> to, aby tego uzywać, tylko dla treningu...

Odróznij trening od przemysłu. Odróżnij trening przedszkolaka od nauki
dalszych działów programowania.

>> Programowanie nie polega na tym że piszesz codzienne nastepne sortowanie
>> bąbelkowe. Programowanie polega (i polegało wtedy rownież) na umiejętnym
>> wykorzystaniu algorytmiki zamiast grzebania w szczegółach implementacji
>> trywializmów.
> Bzdura - nie znając różnic między listą, a wektorem

Na sąsiedniej grupie o Delphi (zawodowi programisci zapewne) stwierdzili
że to żadna różnica bo przecież danych jest zazwyczaj mało. To jest
wlasnie patlogia Pascala i Delphi. Po co komu wiedzieć jakie są róznice
skoro jest jeden TList to rule them all i lecimy dalej.

, czasami użycie
> niewłaściwego typu danych dla danego problemu zabije wydajność.

Dziękujemy. Dzięki takim wypowiedzom entropa internetu maleje choć na
pikosekundę. Wspaniale że ktoś siedzi po drugiej stronie i tłumaczy
reszcie swiata oczywistości.

do góry

On 2016-10-24 15:37, Adam M wrote:
> 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.

No popatrz, a z mojejgo stołka widać że branża motoryzacyjna i lotnicza
projektowane są w Verilog/UVM, VHDL. Pewno siedzimy na różnych stołkach.

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

W tej branzy lotniczej i samochodowej ...

do góry

On 2016-10-24 15:21, Maciej Sobczak wrote:
>> Nie szukaj daleko: Arduino. Że amatorskie? Za chwile Ci amatorzy będa
>> pracować dla firm robiących embedded.
> Co nie znaczy, że dalej będą pisać w C++.

Pewno że nie, będa musza poczekać aż zadziala biologia w starych
zespołach. Jesli ktoś zabiera Ci możliwości i każe pisać w języku z ery
bita łupanego to prędzej czy później frustracja przerodzi się w zmiany.
Takie zmiany generowane przez młodych bez kompleksow i wbudowanej
ignorancji widuję tu i tam.

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

Nie. Narzut na prosty procesor jest za duży. Nie mogłoby. Rownież z
powodu faktu że Java bedzie silnie zależeć od GC co jest w wielu
aplikacjach embedded niedopuszczalne nawet jesli to jakies protezy jak
JavaRT.

> To wcale nie jest takie oczywiste, że C++ będzie poważniej używane w embedzie.

Alez nie będzie. Nikt tak nie wróży. Docelowo to będzie C z elementami
C++. Tak jak obecnie coraz częsciej się robi. Może z czasem coraz większymi.

Problemem programistów C jest to że sama zmiana gcc na g++ wystarcza aby
z nich (ficzerów) korzystać. To tak nie daje im spać że internet jest
pełen idiotyzmów dlaczego C++ nie nadaje się na uC. Zjawisko z
pogranicza religii.

> 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. C tego nie ma i
cieżko to zrobić bez psucia kodu. To że zdecydowana większość
programistów embedded rozumie C++ jako new Foo; to jest ich problem.

> 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. W tym watku
właśnie jeden mistrz pokazał jak sobie żyły wypruł makrem aby uzyskać
popsutą symulację RAII. Oglądałem nie jeden kod embedded w którym
wymyślano takie kwadratowe koła za każdym razem. Za każdym razem
identycznie popsute. Na haslo "ale przeciez to działa w C++" zazwyczaj
parskali albo ignoranckim śmiechem albo pustą godzinną przemową o
debiliźmie młodego pokolenia.

Nie ma przeszkod technicznych.

A wracają do Pascala ...

do góry

On 2016-10-24 09:00, slawek wrote:
>> Banał. Wszyscy to wiemy. Skąd więc w tej dyskusji pojawił się 8051?
>> Przecież nie istnieje ani jedno zastosowanie gdzie byłby lepszy od
>> czegokolwiek. Poza pewna duńską firmą.
> Spokojnie.
> Trzeba byłoby udowodnić że w każdym jest gorszy.

Proszę:
a) nie posiada ani jednego kompilatora C++ poza protezami.
b) ma najwiekszy podzielnik zegara spotykany w przyrodzie
c) ma popieprzony assembler jak każdy Intel

> Samo "nie lepszy" nie jest argumentem przeciw. Bo może jest równie
> dobry? I co wtedy?

Nic. Co najwyżej kilka programowalnych dzwonków w szkołach i sterowników
pieców biedzie zmuszone przejśc na jakiś klon 8051 który będzie
kosztował 20x więcej od AVRa bo właśnie znaleziono ostatni 8051 na
smietniku w Bangladeszu. Bo kod w asm i przetestowany!

do góry

On Monday, October 24, 2016 at 10:05:25 AM UTC-4, Sebastian Biały wrote:
> On 2016-10-24 15:37, Adam M wrote:
> > 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.
>
> No popatrz, a z mojejgo stołka widać że branża motoryzacyjna i lotnicza
> projektowane są w Verilog/UVM, VHDL. Pewno siedzimy na różnych stołkach.
>
> > C++ najczesciej jest uzywany gdy zachodzi potrzeba programowania ladnego GUI (z
uzyciem QT najczesciej)
>
> W tej branzy lotniczej i samochodowej ...

Kolega pewnie pisze dla FPGA lub CPLD. Ja mam doczynienia z DSP/MCU - tu Verilog nie
powalczy ;-) .

do góry