On Sat, 22 Oct 2016 12:13:24 -0700 (PDT), g...@g...com
wrote:
> 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.

Czyli po prostu nie masz pojęcia o embeded.

do góry

On Sat, 22 Oct 2016 22:07:01 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> integralną całością to byś o nim nie usłyszał. Nie da się mówić o
> przydatnosci c# bez ekosystemu .NET i tyle. Bez tego jest nastepnym
> nudnym klonem Javy.

Bo jest.

do góry

W dniu niedziela, 23 października 2016 09:23:55 UTC+2 użytkownik slawek napisał:

> > Mówisz poważnie? Ale masz świadomość, że powo=
> > dem, dla którego
> > owe stada studentów piszą programy do sortowania bąbelkowego=
> > ,
> > nie jest brak istniejących implementacji funkcji sortujących?
>
> Skoro ty to wiesz, to wyjaw nam dlaczego stada studentów piszą
> programy do sortowania bąbelkowego?

Już "wyjawiłem" w jednym z wcześniejszych postów.

do góry

On Sat, 22 Oct 2016 16:43:30 -0700 (PDT), g...@g...com
wrote:
> 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=

Ma mnóstwo takich cech.

Jedyna wada: im więcej ficzerów, tym większa szansa że coś jest
skopane. Przykład: goto Borlanda - w C++ mogło psuć stos.

do góry

W dniu niedziela, 23 października 2016 09:27:12 UTC+2 użytkownik slawek napisał:

> > 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.
>
> Czyli po prostu nie masz pojęcia o embeded.

i to mówi gość, który twierdzi, że .NET jest spoko, ale CLR beznadziejne.
(hint: następnym razem jak będziesz chciał powiedzieć o czymś, o czym
nie masz pojęcia, poczytaj chociaż o tym najpierw na wikipedii)

niestety, tak się składa, że na co dzień zawodowo programuję embedded
(i to nie arduino). ale oczywiście zamiast powiedzieć coś merytorycznie
wartościowego, wolisz zrobić wybieg "ad personam"

do góry

On Sun, 23 Oct 2016 00:32:31 -0700 (PDT), g...@g...com
wrote:
> Już "wyjawiłem" w jednym z wcześniejszych postów.

Że cośtam?

Sorry, ale człowiek tak już ma, że nie da się (wbrew temu co uważają
wioskowe głupki) czegoś "oduczyć".
Uczenie sortowania bąbelkowego ma jeden skutek: tak wytresowany
będzie wszędzie te bąbelkowe sortowanie wsadzał. I nie piszę tego
teoretycznie: naprawdę większość ma wdrukowane w mózg skojarzenie
sortowanie->bąbelkowe.

do góry

On Sun, 23 Oct 2016 00:43:38 -0700 (PDT), g...@g...com
wrote:
> i to mówi gość, który twierdzi, że .NET jest spoko=
> , ale CLR beznadziejne.

C/CLR - przejaśniło ci się w łepetynce?

do góry

On Sun, 23 Oct 2016 00:43:38 -0700 (PDT), g...@g...com
wrote:
> niestety, tak się składa, że na co dzień zawodowo progr=
> amuję embedded

Możliwe. Czy już odkryłeś makra w Asemblerze, czy ten etap ciągle
przed tobą?

do góry

On 2016-10-23 01:43, g...@g...com wrote:
> 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.

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

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

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

> 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
b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
przerwania przy wychodzeniu w z funkcji" przestają istnieć.
c) Templatey. Pozawalają pisać kod *lepiej* dostosowany do platformy i
powodować że przenośność jest łatwiejsza.
d) Statyczny polimorfizm. Powoduje że mozna mieć abstrakcje bez narzutu
wydajność. Istotne kiedy wazny jest każdy cykl i kiedy projekt jest w
formie prototypowej.

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

do góry

On 2016-10-23 08:42, slawek wrote:
>> powinny być częścią języka. 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
> Zgoda. Ale zauważyłeś, iż C miał to wszystko od początku? Naturalnie gdy
> powstawał nie było Internetu w Polsce. A ilość dostępnych bibliotek od
> tamtych czasów trochę wzrosła.

C nikt nie traktowal jako godnego miana języka edukacyjnego. A nie był
dostępny wprost w PL w latach 80-tych z powodów bardziej
polityczno-gospodarczych. Tu była nisza i zostala wypełniona przez
Pascala. Cieszmy się że nie przez BCPLa.

C nic nie miał od początku. To goły jezyk do mieszania wskaźnikami i
grzebania w hardware. Do dzisiaj jest tylko żałosnym assemblerem i tak
należy go traktować. A to że istnieją programiści z brodami którzy
potrafią albo pisać tylko w C albo tylko w Pascalu to trudno. Jak mówię,
biologia jest jedyna drogą do rozwiązania problemu.

do góry