-
301. Data: 2022-07-21 14:23:13
Temat: Re: Rynek pracy STM32
Od: "Grzegorz Niemirowski" <g...@g...net>
Piotr Gałka <p...@c...pl> napisał(a):
> Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
> dlaczego do głównej tezy, że program wygenerowany z templates nie pójdzie
> w avr.
Pójdzie, bo szablony C++ nie mają nic wspólnego z wykonywaniem kodu z RAM-u.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
-
302. Data: 2022-07-21 14:37:02
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 21/07/2022 12:53, Janusz wrote:
>> Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.
> Co gorzej, odpowiedz na pytanie, czy avr wykona program z ramu?
Nie wykona. Nie musi. Szablony "nie są w ramie". Metody wirtualne też nie.
Dostałeś dwa przykłady, na oba przypadki, działajace na AVR, napisane w
kilka minut.
-
303. Data: 2022-07-21 14:40:49
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 21/07/2022 13:36, Grzegorz Niemirowski wrote:
>> No właśnie o tym cały czas piszę :) nic te szablony czy polimorfizmy
>> nie dają w np zmniejszeniu ilości kodu. Przejrzystości też nie.
> Zmniejszają kod źródłowy, wynikowy oczywiście nie.
To zależy. Nie da się jednoznacznie tak powiedzieć. Wynikiem
przeciętnego zastosowania szablonu w codziennej pracy jest *lepiej*
zoptymalizowany kod. Więc zależy od użycia a nie ogolnie od bycia lub
nie, szablonem.
-
304. Data: 2022-07-21 14:41:38
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 21/07/2022 13:51, Janusz wrote:
>> Zmniejszają kod źródłowy, wynikowy oczywiście nie.
> No właśnie, przy małych prockach z małymi zasobami jest to istotna wada.
> Dlatego cały czas piszę że nie da się jednej miary przykładać do
> wszystkiego, środowiska z dużych maszyn nijak sie mają do małych
> procków, ale herby zaraz na mnie nakrzyczy że jestem betonem i jest
> inaczej :)
Rzecz w tym, że nie masz pojęcia o czym mówisz. Więc to nie beton. To
takie inne słowo.
-
305. Data: 2022-07-21 14:59:56
Temat: Re: Rynek pracy STM32
Od: Janusz <j...@o...pl>
W dniu 2022-07-21 o 14:41, heby pisze:
> On 21/07/2022 13:51, Janusz wrote:
>>> Zmniejszają kod źródłowy, wynikowy oczywiście nie.
>> No właśnie, przy małych prockach z małymi zasobami jest to istotna wada.
>> Dlatego cały czas piszę że nie da się jednej miary przykładać do
>> wszystkiego, środowiska z dużych maszyn nijak sie mają do małych
>> procków, ale herby zaraz na mnie nakrzyczy że jestem betonem i jest
>> inaczej :)
>
> Rzecz w tym, że nie masz pojęcia o czym mówisz.
Widziałem te twoje wypociny, daruj sobie.
Więc to nie beton. To
> takie inne słowo.
Dalej wycieczki osobiste?
--
Janusz
-
306. Data: 2022-07-21 15:01:21
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-20 o 23:08, heby pisze:
> To jedyna ksiązka z dzieciństwa, w której pozytywny bohater jest ścisły :)
Ścisłych, pozytywnych bohaterów (ale nie ma tam głównego bohatera) miała
też książka "Niezwykłe perypetie odkryć i wynalazków", ale to nie była
beletrystyka tylko literatura faktu.
> Pamiętaj, że jestem złośliwy tylko, jesli ktoś mnie puknie kijem bez
> przyczyny.
To wiem. Ale mógłbyś mieć więcej tolerancji gdy ktoś się walnie i potem
nie umie się z tym pogodzić.
Ja uważam, że są dwa poziomy pewności:
- jestem pewny,
- jestem absolutnie pewny.
Jeśli jakaś dyskusja jest prowadzona tak, że można cokolwiek
jednoznacznie powiedzieć tylko w przypadku absolutnej pewności to
dyskusja jest bardzo trudna bo ktoś, kto coś wie jedynie na poziomie
'jestem pewny' nie powinien się odzywać, albo musi swoją wypowiedź
otoczyć szeregiem zastrzeżeń podających w jakich aspektach ma
wątpliwości co do przedstawianych faktów. Zaletą takiej dyskusji jest
to, że można zakładać, że wszystko co się usłyszało jest 100% pewne, ale
wadą, że można zgubić kluczowe informacje bo będą przemilczane.
Znacznie prostsze jest dyskutowanie, gdy również w stanie jedynie
'jestem pewny' można po prostu krótko powiedzieć 'to jest tak a tak'.
Wszyscy, którzy coś wiedzą się odezwą, żadnych informacji się nie
pominie bo ktoś nie absolutnie pewny nie przemilczy swojej wiedzy. Ale
uczestnicy muszą wtedy świadomie przykładać do wszystkich wypowiedzi
jakiś poziom ufności (rzędu 95% - czyli jedna na 20 wypowiedzi może
zawierać błąd).
Ja do wszystkich informacji, które widzę na p.m.e przykładam te 95%.
Również do Twoich wypowiedzi, choć wiem, że jesteś raczej z tego
pierwszego rodzaju dyskusji.
Dzięki temu nie mam żadnego problemu z tym, że ktoś się pomyli nie ze
złej woli tylko po prostu wypowiedział się na podstawie pewności a nie
absolutnej pewności.
Nie zwracam mu uwagi w sposób, który wywołuje odruch obronny prowadząc
stopniowo do przepychanek.
> To źle. Ogólnie ludzie w IT lubią dzielić się wiedzą. "Szkolenia z
> subversiona" realizowałem praktycznie co chwile z racji zawodu, więc
> niejako pojmuję czego kto nie pojmuje statystycznie najczęsciej i gdzie
> są niejasności.
Uważam, że jestem urodzonym dydaktykiem. Miałem co najmniej dwie okazje
się o tym 'prawie jednoznacznie' przekonać, ale nie miejsce tutaj na
rozpisywanie się jeszcze o tym.
>> Tylko, że przy moim programowaniu (góra miesiąc w roku) to mam
>> podejrzenie, że system kontroli wersji to trochę aż na wyrost.
>
> Widzisz, problem nie w tym, abyś go użył. Możesz pomarudzić, że to
> głupie i nigdy nie użyć. W pełni to rozumiem.
Wczoraj wieczorem (czyli koło 1-ej w nocy na spacerze) doszedłem do
wniosku, że chyba mam rację, że mi się to niewiele przyda, bo ja
niewiele piszę, ale mój brat prawie 100% pracy poświęca na pisanie.
Muszę kiedyś (miesiąc, dwa) pogadać z nim o tym i przekonać, że to może
być dobre. Wtedy jako najlepszą drogę widzę jakbym najpierw ja to ogarnął.
>
> Rzecz w tym, aby pojmowac, że ma się alternatywę. Nie ma nic gorszego
> niż beton w poglądach na to że "tak jak robie jest najlepiej, bo tak
> robię od 30 lat". W embedded takich sytuacji jest ogramna ilość. Nie
> wiem, dlaczego to środowisko jest takie specyficzne, ale praktycznie
> wszystkie anegdoty i opowieści zasłyszane, dotyczące średniowiecza
> narzędziowego, dotyczą embedded. Nawet duże korpo potrafią wstydliwie
> chować pakowanie źródeł do ftp jako substytut systemów kontroli wersji.
> Mam wrażenie, że nie ma przepływu wiedzy pomiędzy programistami dużych
> komputerów a embedded. Środowiska odizolowane od siebie i w dodatku
> obrażone. Nie mieszają się. A to mieszanie jest krytyczne ważne. Nic tak
> nie cieszy, jak ktoś, kto pokaze mi, że można zrobic coś *lepiej* niż ja
> potrafię. A to się dzieje codziennie w moim wypadku.
Ja myślę, że z embedded jest jednak trochę bardziej skomplikowanie niż
się Tobie wydaje (na podstawie Twoich wypowiedzi).
Brat niedawno nie zostawiał suchej nitki na jakimś przykładowym
programie USB dla tego Silabsa. Jak pisałeś o metodach znanych od lat
80-tych oddzielenia kodu od hardware'u to miałem wrażenie, że ten
program co mu się tak bardzo nie podobał to pewnie był napisany według
tych metod.
Niestety kompletnie za mało wiem, aby cokolwiek bardziej jednoznacznie
powiedzieć.
Nie mam pojęcia czy dotykam dobrego punktu, ale takie skojarzenie.
Wydaje mi się (podkreślam wydaje mi się), że w niektórych prockach nie
można odczytać portu, zmienić jednego bitu i zapisać z powrotem bo w ten
sposób można zmienić stan innego bitu, który akurat chwilowo był
wymuszony z zewnątrz. I jak przez mgłę pamiętam sprzed lat, że brat coś
takiego mówił, przy spotkaniu z jakimś programem, że jakiś idiota ma
swój kawałek do którego przydzielone są np. 3 nogi i program pisze tak,
jakby pozostałych nóg nie było. Pewnie użył jakąś bibliotekę gdzie ktoś
zdefiniował jakąś abstrakcję obejmującą te 3 linie i ma w dupie co się
dzieje naokoło - Jak można tak pisać !!
A przypuszczam (znów tylko przypuszczam) że próba tworzenia abstrakcji
tak aby jakieś rzeczy sprzętowe były od strony głównego programu zawsze
takie same może prowadzić właśnie w tym kierunku. Oczywiście, zapewne
ktoś coś tam źle podłożył łącząc to coś z tym akurat prockiem.
> Jesli nawet z tego mieszania nic nie wyjdzie i zostaniesz z tym co masz,
> nic straconego. Może inni, czytający te wypociny obok, zainteresuja się
> tematem.
Bardzo prawdopodobne. Nie raz śledzę jakąś dyskusję w ogóle się nie
odzywając i czasem coś sobie zanotuję bo a nuż się przyda więc dokładnie
to samo można podejrzewać o innych śledzących p.m.e
P.G.
-
307. Data: 2022-07-21 15:06:03
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-21 o 14:23, Grzegorz Niemirowski pisze:
> Piotr Gałka <p...@c...pl> napisał(a):
>> Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
>> dlaczego do głównej tezy, że program wygenerowany z templates nie
>> pójdzie w avr.
>
> Pójdzie, bo szablony C++ nie mają nic wspólnego z wykonywaniem kodu z
> RAM-u.
Nie wiem jak to skomentować.
Czy ja aż tak niejasno piszę, że można podejrzewać, że to ja twierdzę,
że nie pójdzie.
P.G.
-
308. Data: 2022-07-21 15:06:49
Temat: Re: Rynek pracy STM32
Od: Janusz <j...@o...pl>
W dniu 2022-07-21 o 14:23, Grzegorz Niemirowski pisze:
> Piotr Gałka <p...@c...pl> napisał(a):
>> Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
>> dlaczego do głównej tezy, że program wygenerowany z templates nie
>> pójdzie w avr.
>
> Pójdzie, bo szablony C++ nie mają nic wspólnego z wykonywaniem kodu z
> RAM-u.
>
Szablony tak, ale polimorfizm dynamiczny już nie, tzn pójdzie bo będzie
de fakto statyczny czyli stałe procedury wygenerowane na każdą
okoliczność wsadzone w rom.
Tyle że ten sam efekt osiągam pisząc sobie sam specjalizowane funkcje na
każdy rozdzaj argumentu, więc po co sie kopać z koniem czyli
kompilatorem i wymyślać mu szablony czy przeciążenia argumentów? Co ma
sens dla dużych procków i zespołów ludzi niekoniecznie ma sens dla
małych i pojedynczych autorów.
--
Janusz
-
309. Data: 2022-07-21 15:21:36
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 21/07/2022 15:06, Janusz wrote:
> Szablony tak, ale polimorfizm dynamiczny już nie, tzn pójdzie bo będzie
> de fakto statyczny czyli stałe procedury wygenerowane na każdą
> okoliczność wsadzone w rom.
To *jest* polimorfizm dynamiczny, kiedy kod *jest* wygenerowany przez
kompialtor ,a całośc procesu sterowania nim odbywa sie przez indirect call.
Myslisz to z "kodem dynamicznym" albo "kodem samomodyfikującym" który
nie ma z tym nic wspólnego.
Już to napisałem, ale najwyraźniej nie dociera.
Nawet na dużych komputerach używanie samomodyfikującego się kodu jest
niewskazane i nikt tego nie robi powszechnie z jednym wyjątkiem:
niektóre implementacje trampolin.
Działajacy na AVR przykład z polimorfizmem dynamicznym dostałeś na tacy.
Działa, bo nie ma nic wspólnego z kodem samomodyfikującym.
> sens dla dużych procków i zespołów ludzi niekoniecznie ma sens dla
> małych i pojedynczych autorów.
Nie rozumiesz sensu szablonów.
Bywa, że wynikiem skomplikowanego kodu w szablonach jest *nic*. Albo 1
liczba. Albo gigabajt kodu. Wkładasz szablony do worka "dużo" bo nigdy w
życiu ich nie używałeś do czegokolwiek. Po prostu wydaje Ci się, że dużo
kodu źrłodłwego musi wygenerować dużo asemblera. A tu jest czasami
odwrotnie.
-
310. Data: 2022-07-21 15:25:06
Temat: Re: Rynek pracy STM32
Od: "Grzegorz Niemirowski" <g...@g...net>
Piotr Gałka <p...@c...pl> napisał(a):
> Nie wiem jak to skomentować.
> Czy ja aż tak niejasno piszę, że można podejrzewać, że to ja twierdzę, że
> nie pójdzie.
Spoko, już jasne.
--
Grzegorz Niemirowski
https://www.grzegorz.net/