czwartek, 18 maja 2023 o 15:38:33 UTC+2 heby napisał(a):
> On 18/05/2023 15:28, Grzegorz Niemirowski wrote:
> >> Nie. Zapewne dlatego wyciałeś cycta wyżej. Od tego może "zacząć C++
> >> używać".
> > Wyciąłem, bo pisząc o zaczęciu nie miałem na myśli wykonania kroku,
> > który tak naprawdę nic nie zmienia.
> Krok ten zmienia bardzo wiele. Nagle nie masz wymówki, że się nie da
> pisać lepiej.

Niestety da się również pisać gorzej.

> > Kolega KS zacznie używać C++ gdy
> > zacznie używać jego mechanizmy i porzuci nawyki z C.
> Nie. Mechniazmów C++ możesz używać dowolnych, w dowolnym momencie. Nikt
> nie porzuca C, nie ma takiej potrzeby. W C++ jest masa ułatwień, któe
> znakomicie przydadzą się w C bez potrzeby rezygnacji i dysonansu
> ideologicznego. std::size to jedno z setek, użytecznych w embedded,
> ułatwień, za darmo.

Wciąż nie możesz zrozumieć, że pisząc o C++ musisz mieć w świadomości,
że to jest cały C++, a nie tylko wybrane przez ciebie, ułatwiające życie mechanizmy.
Wtedy to były jakiś heby++.
Ale nie C++.
Może nie masz traumy ze studiów ze zmuszaniem do stosowania bzdur
jako sztuki dla sztuki.
Mnie to prześladowało jeszcze po studiach, jak kiedyś byłem na "rekrutacji"
(z bardzo fajną rekruterką - więc choćby dlatego warto było, pozdrowienia ;)
to dostałem da testy - z Javy i C++.
Możliwe, że jestem niedouczony, ale z Javy poszedł jak z płatka, a z C++
normalnie wytrzeszcz: "to tak można?!?!jeden!"

I mi brakuje właśnie czegoś takiego jak kompilowana java na uC.
Było coś w podobie zwanego JavaME - ale padło.

Jak piszesz samemu to możesz sobie dyscyplinę typu: "używam TYLKO tego, tego i tego z
C++" narzucić.
Ale w zespole zaraz zaczną odwalać bzdury, "bo w C++ tak można".
Tak jak kiedyś byłem na rozmowie o pracę z takimi dwoma, co mieli biuro w KC,
chodziło o J2ME i mocno komentowali o takich, co na J2ME alokują sobie tablice po
2MB...

do góry

czwartek, 18 maja 2023 o 16:01:56 UTC+2 heby napisał(a):
> On 18/05/2023 15:58, Dawid Rutkowski wrote:
> > Zmienić dwie literki - proste, ale nie wystarczy.
> > Może wystarczą następne kroki - ale one są już o wiele, wiele trudniejsze.
> A co jeszcze musisz zmienić *zanim* zaczniesz używać std::size, poza "++"?
>
> Możesz podać listę tych kroków?

Więcej nie ma, poza przekroczeniem Rubikonu - takim, że przestajesz
powoli mieć możliwość odwrotu do C, a możesz nie mieć tyle fartu co Juliusz Cezar.

To ja zapytam z drugiej strony - co rozwiąże używanie TYLKO std::size, poza bugami na
sizeof?
Ogólnie to średnio inteligentny matoł, który przesiedział trochę dupogodzin nad
bugiem
na sizeof (szczególnie na embedded, bo pod OS pierwsze użycie gdb to naprawdę jest
satori),
zapamięta to sobie na całe życie - inaczej się na programistę i tak nie nadaje,
a nie sądzę, byśmy mieli ich na tyle mało, że trzeba pytać ludzi z działu
wprowadzania danych,
czy chcą się nauczyć programowania.

A z trzeciej strony pozwolenie na C++ to otwarcie nowej Puszki Pandora.
Tu dopiero możesz się dowiedzieć, co to jest prawdziwy bug, a nie jakiś tam sizeof.

> > Zaś "zwyczajowo" - to samo raczej nic nie poprawi. Popsuć może.
> A co może popsuć?

Jak zwykle - "jeśli działa, nie naprawiaj". Sprawdzić, czy nie kobieta (poza
Kopernik, Einstein i Curie-Skłodowska ;).

do góry

On 18/05/2023 16:08, Dawid Rutkowski wrote:
>>> Wyciąłem, bo pisząc o zaczęciu nie miałem na myśli wykonania kroku,
>>> który tak naprawdę nic nie zmienia.
>> Krok ten zmienia bardzo wiele. Nagle nie masz wymówki, że się nie da
>> pisać lepiej.
> Niestety da się również pisać gorzej.

Tak, ale to już problem białkowy, a nie ograniczenia języka. Wystapuje w
każdym języku. No może poza perlem, tam pisanie bardzo dobrze jest
nieodróznialne od pisania najgorzej.

> Wciąż nie możesz zrozumieć, że pisząc o C++ musisz mieć w świadomości,
> że to jest cały C++, a nie tylko wybrane przez ciebie, ułatwiające życie
mechanizmy.

Bzdura do kwadratu.

Piszesz w C.

Masz problem, który można elegancko i czytelnie rozwiązać C++.

Używasz C++ w tym jednym miejscu.

Reszta dnia wolnego.

> Ale nie C++.

Czyli to problem ideologiczny. Nie możesz uwierzyć, że można pisać po
staremu i tam gdzie C++ się przydaje - użyć go. Musi być albo skrajna
prawica albo lewica. Recjonalizm zakazany.

> Może nie masz traumy ze studiów ze zmuszaniem do stosowania bzdur
> jako sztuki dla sztuki.

Po prostu ich nie rozumiesz i to całkowicie zrozumiałe. Jak zaczniejsz
używać, szczególnie jeśli ktoś pokaże Ci jak, zrozumiesz, że pewne
konstrukcje w C są najzwyczajniej niebezpieczne i prowadzą do sytuacji
niewykryanych przez kompilator, jak w tym watku.

Pisanie w C to pisanie w asemblerze, podługując się nieskopoziomowymi
instrukcjami.

Pisanie we współczesnym C++ polega na wyrażaniu potrzeb w sposób
wysokopoziomowy. Zamaist "potrzebuję wiedziec ile to zajmuje ramu i
potem se podziele" piszesz "potrzebuje wiedzieć jakie to jest duże". To
jest bezpieczniejsze.

Do tego stopnia, że w jednym z coding standardów jakie miałem okazję
czytać, używanie sizeof w pętli for jest wykrywane przez linter na
etapie review. Ktoś widocznie miał dośc poprawiania takich bzdur.

> Mnie to prześladowało

Więc to problem ideologiczny.

> Możliwe, że jestem niedouczony, ale z Javy poszedł jak z płatka, a z C++
> normalnie wytrzeszcz: "to tak można?!?!jeden!"

Czyli możesz się w wolnej chwili doedukować. Powiększawie warsztatu
programistycznego to tylko plusy. Tym bardziej, że za friko.

> I mi brakuje właśnie czegoś takiego jak kompilowana java na uC.
> Było coś w podobie zwanego JavaME - ale padło.

Nie chcesz tego. Semantyka referencji i zarządzanie pamięcią w Javie nie
nadaja się do mikrokontrolerów, szczególnie do zastosowań realtime, mimo
wielu prób wciśnięcia Javy do małych uC. Za to C++ jak najbardziej
pasuje, bo jest zdecydowanie bliżej sprzętu.

> Jak piszesz samemu to możesz sobie dyscyplinę typu: "używam TYLKO tego, tego i tego
z C++" narzucić.

Tak. To się nazywa coding standard, review, lint. Nie masz takiego
zestawu w firmie?

> Ale w zespole zaraz zaczną odwalać bzdury, "bo w C++ tak można".

Nie. Od tego jest code review + coding standard. Choć przyznaje, że to
pytanie/opinia czasem się pojawi, szczególnie jak zakaz idityczny. Na
przykład "nie wolno używać C++ bo go nie rozumiem".

> Tak jak kiedyś byłem na rozmowie o pracę z takimi dwoma, co mieli biuro w KC,
> chodziło o J2ME i mocno komentowali o takich, co na J2ME alokują sobie tablice po
2MB...

I znowu ten sam argument bez śladu sensu. To, że ktoś w C++ allokuje za
dużo, to wina biedy intelektualnej programisty, a nie wina C++. C++ to
tylko powiększenie składni o masę użytecznych rzeczy. Nie chroni przed
debilizmem. Ale czasem wrzaśnie na etapie kompilacji o jakimś fuckupie,
gdzie C przełknie bez popijania. I jak wstawisz w to zdanie "Java"
zamiast "C++" to dalej będzie prawda.

do góry

On 18/05/2023 16:16, Dawid Rutkowski wrote:
>>> Może wystarczą następne kroki - ale one są już o wiele, wiele trudniejsze.
>> A co jeszcze musisz zmienić *zanim* zaczniesz używać std::size, poza "++"?
>> Możesz podać listę tych kroków?
> Więcej nie ma, poza przekroczeniem Rubikonu - takim, że przestajesz
> powoli mieć możliwość odwrotu do C, a możesz nie mieć tyle fartu co Juliusz Cezar.

Po co chcesz wracać do C? Możesz podać 1 racjonalny powód?

> To ja zapytam z drugiej strony - co rozwiąże używanie TYLKO std::size, poza bugami
na sizeof?

Dokładnie to.

Jest masa innych rozwiązań innych problemów. Każdy znajdzie coś dla siebie.

Mój ulubuiony z gatunku "ło, to się tak da?", który jest z drugiej
strony, z kretaywnego wykorzystania C++:

Masz programistę C, ideologa, który prawie całe życie pisał miganie
diodami w 8051.

W efekcie czego masz taki kod:

#define FOO_FLAG 1<<6
#define BAR_FLAG 1<<3
#define OUT_FLAG 1<<2

i funkcję:

void setFlags( int flags, int extra_flags );

No i które flags przyjmują jakie define?

To przykład z typowego systemu embedded.

Czy wiesz, że dzięki magii C++ możesz napisać funkcję setFlags, bez
śladu narzutu w runtime, która uniemozliwi podanie nieprawidłwej flagi
do zmiennej i bedzie to wykrywane na etapie kompilacji?

Pomyłka używania flag z powodu używania idotycznych #define to znaczący
problem w embedded i możesz go elegancko rozwiązać w C++. Wymaga to
nieco kodu o dość skomplikowanej budowie, ale dla użytkownika końcowego
jest to trywialne w użyciu.

To jest raz napisane za darmo. Nagle niwelujesz masę problemów w różnych
miejscach.

Tego nie da się zrobic w C, chyba że będziesz używał jakiegoś
postprocessingu C.

> Ogólnie to średnio inteligentny matoł, który przesiedział trochę dupogodzin nad
bugiem
> na sizeof (szczególnie na embedded, bo pod OS pierwsze użycie gdb to naprawdę jest
satori),
> zapamięta to sobie na całe życie - inaczej się na programistę i tak nie nadaje,

Tutaj wlaśnie się różnimy. Dla mnie to siedzenie nad debuggerem razy
ilość trywialnych problemów załatwionych w C++ to koszta, które nie uczą
niczego innego, jak tylko masy iditycznych zakazów. To przypomina naukę
za pomocą bata. Może i skuteczna, ale koszty ponosi pracodawca, a
pracownik ma poczucie orania po polu pełnym min.

> A z trzeciej strony pozwolenie na C++ to otwarcie nowej Puszki Pandora.

Możesz podać przykład, co okromnego stanie się po pozwoleniu używania
C++ czego nie da się spierniczyć w C?

> Tu dopiero możesz się dowiedzieć, co to jest prawdziwy bug, a nie jakiś tam sizeof.

Nie, to najzwyczajniej nie prawda. Służę własną statystyką moją i
kilkudziesięciu ludzi jakich znam. Koszt szukania błedu w dużym systemie
w C jest dramatycznie droższy, od systemu w C++. Głównie z powodu
znacząco wyższej kultury pisania, opierajacej się o unit testy,
abstrakcje itp detale, których w C nie ma, a jak są, to są grubym
workaroundem zazwyczaj wynajdującym C++ za pomocą makr i asemblera.

Pracuję w C++ w ogromnym oprogramowaniu. Oprogramowanie to zawiera
również legacy C. Nie, nie chciałbyś tam debugować.

>>> Zaś "zwyczajowo" - to samo raczej nic nie poprawi. Popsuć może.
>> A co może popsuć?
> Jak zwykle - "jeśli działa, nie naprawiaj". Sprawdzić, czy nie kobieta (poza
Kopernik, Einstein i Curie-Skłodowska ;).

Czyli czysta ideologia. Masz za darmo siekiere, ale walenie patykiem o
drzewo też działa, wiec po co zmieniać.

do góry

czwartek, 18 maja 2023 o 16:25:03 UTC+2 heby napisał(a):
> On 18/05/2023 16:08, Dawid Rutkowski wrote:
> >>> Wyciąłem, bo pisząc o zaczęciu nie miałem na myśli wykonania kroku,
> >>> który tak naprawdę nic nie zmienia.
> >> Krok ten zmienia bardzo wiele. Nagle nie masz wymówki, że się nie da
> >> pisać lepiej.
> > Niestety da się również pisać gorzej.
> Tak, ale to już problem białkowy, a nie ograniczenia języka. Wystapuje w
> każdym języku. No może poza perlem, tam pisanie bardzo dobrze jest
> nieodróznialne od pisania najgorzej.

Czyli to, że w C można pisać gorzej, to problem języka,
a to, że w C++ można pisać gorzej, to tylko problem białka?

> > Wciąż nie możesz zrozumieć, że pisząc o C++ musisz mieć w świadomości,
> > że to jest cały C++, a nie tylko wybrane przez ciebie, ułatwiające życie
mechanizmy.
> Bzdura do kwadratu.
>
> Piszesz w C.
>
> Masz problem, który można elegancko i czytelnie rozwiązać C++.
>
> Używasz C++ w tym jednym miejscu.
>
> Reszta dnia wolnego.

Reszta dnia na kotrolowanie tego, czy ktoś inny nie użył więcej z C++ niż
odpuszczasz.

> > Ale nie C++.
>
> Czyli to problem ideologiczny. Nie możesz uwierzyć, że można pisać po
> staremu i tam gdzie C++ się przydaje - użyć go. Musi być albo skrajna
> prawica albo lewica. Recjonalizm zakazany.

Sklonuj się to się uda.
Ja zawsze chciałem mieć brata bliźniaka (niekoniecznie chciałbym mieć
przy tym na imię Jarosław) - to bardziej realne niż 4 ręce.

> > Może nie masz traumy ze studiów ze zmuszaniem do stosowania bzdur
> > jako sztuki dla sztuki.
> Po prostu ich nie rozumiesz i to całkowicie zrozumiałe. Jak zaczniejsz
> używać, szczególnie jeśli ktoś pokaże Ci jak, zrozumiesz, że pewne
> konstrukcje w C są najzwyczajniej niebezpieczne i prowadzą do sytuacji
> niewykryanych przez kompilator, jak w tym watku.

Pewne konstrukcje w C++ są jeszcze bardziej niebezpieczne.
I ogólnie C++ jest jeszcze bardziej niebezpieczne, bo zawiera wszystkie
niebezpieczeństwa C,
plus jeszcze dodatkowe z C++.

> Pisanie w C to pisanie w asemblerze, podługując się nieskopoziomowymi
> instrukcjami.
>
> Pisanie we współczesnym C++ polega na wyrażaniu potrzeb w sposób
> wysokopoziomowy. Zamaist "potrzebuję wiedziec ile to zajmuje ramu i
> potem se podziele" piszesz "potrzebuje wiedzieć jakie to jest duże". To
> jest bezpieczniejsze.

Byś może rozmawiamy o zupełnie różnych C++.

> Do tego stopnia, że w jednym z coding standardów jakie miałem okazję
> czytać, używanie sizeof w pętli for jest wykrywane przez linter na
> etapie review. Ktoś widocznie miał dośc poprawiania takich bzdur.

C++ minus to, co odwala linter, to już nie jest C++.
I tu dochodzimy do kosztów wprowadzenia C++ w firmie.
Np. taki linter. I nowy coding standard.
To koszty niezaprzeczalne. Zyski - możliwe, lecz niepewne.
Bliskie pracy zespolonej.

> > Możliwe, że jestem niedouczony, ale z Javy poszedł jak z płatka, a z C++
> > normalnie wytrzeszcz: "to tak można?!?!jeden!"
> Czyli możesz się w wolnej chwili doedukować. Powiększawie warsztatu
> programistycznego to tylko plusy. Tym bardziej, że za friko.

> > I mi brakuje właśnie czegoś takiego jak kompilowana java na uC.
> > Było coś w podobie zwanego JavaME - ale padło.
> Nie chcesz tego. Semantyka referencji i zarządzanie pamięcią w Javie nie
> nadaja się do mikrokontrolerów, szczególnie do zastosowań realtime, mimo
> wielu prób wciśnięcia Javy do małych uC. Za to C++ jak najbardziej
> pasuje, bo jest zdecydowanie bliżej sprzętu.

Hmm, a we "współczesnym" C++ nie ma czegoś w rodzaju std::garbageCollector?
Czym się różnią referencje w Javie i wskaźniki/referencje w C++?
Możliwością statycznej alokacji w C++?
To sobie w Javie stwórz i nie kasuj, będzie tam samo, a nawet lepiej,
bo jakbyś chciał zacząć kasować to odchodzi jedno z największych bugo-bagien.

> > Jak piszesz samemu to możesz sobie dyscyplinę typu: "używam TYLKO tego, tego i
tego z C++" narzucić.
> Tak. To się nazywa coding standard, review, lint. Nie masz takiego
> zestawu w firmie?

Ja sam sobie sterem, żeglarzem, okrętem.
Ale jeszcze raz - czy coding standard, review, lint są za darmo?
Może są, daj namiar na jakiś opensource czy GNU.

> > Ale w zespole zaraz zaczną odwalać bzdury, "bo w C++ tak można".
> Nie. Od tego jest code review + coding standard. Choć przyznaje, że to
> pytanie/opinia czasem się pojawi, szczególnie jak zakaz idityczny. Na
> przykład "nie wolno używać C++ bo go nie rozumiem".

I dobrze, w pełni się z tobą zgadzam - narzędzi trzeba umieć używać.
Ale to kosztuje.

> > Tak jak kiedyś byłem na rozmowie o pracę z takimi dwoma, co mieli biuro w KC,
> > chodziło o J2ME i mocno komentowali o takich, co na J2ME alokują sobie tablice po
2MB...
> I znowu ten sam argument bez śladu sensu. To, że ktoś w C++ allokuje za
> dużo, to wina biedy intelektualnej programisty, a nie wina C++. C++ to
> tylko powiększenie składni o masę użytecznych rzeczy. Nie chroni przed
> debilizmem. Ale czasem wrzaśnie na etapie kompilacji o jakimś fuckupie,
> gdzie C przełknie bez popijania. I jak wstawisz w to zdanie "Java"
> zamiast "C++" to dalej będzie prawda.

Kompilacji? Raczej lintowania.
I mając do wyboru C oraz C++ jako nadzbiór C - wybiorę jednak C,
mniejszy stopień komplikacji łatwiej badać.

No a jak będzie nowe pokolenie to już nie będą musieli sięmieścić w pojedynczych kB
RAM.
Trzeba im tylko jako spadek zostawić dobry OS, inaczej rakiety zaczną spadać.
Może to i się do pokoju światowego przyczyni, takie kacapy nie będą miały dostępu
do odpowiednio mocnych uC - takie z laktatorów nie wystarczą...

do góry

On Thu, 18 May 2023 16:00:27 +0200, heby <h...@p...onet.pl> wrote:
> Przeniesięnie się z subsetu do przestrzeni gdzie istnieje to
> rozwiązanie
> jest obarczone zerowym kosztem.

A koszt czasu nauki?

--
Marek

do góry

On 18/05/2023 16:54, Dawid Rutkowski wrote:
>>> Niestety da się również pisać gorzej.
>> Tak, ale to już problem białkowy, a nie ograniczenia języka. Wystapuje w
>> każdym języku. No może poza perlem, tam pisanie bardzo dobrze jest
>> nieodróznialne od pisania najgorzej.
> Czyli to, że w C można pisać gorzej, to problem języka,
> a to, że w C++ można pisać gorzej, to tylko problem białka?

Nie. W obu można pisac źle. W C++ jest to tak samo łatwe jak w C. Ale
jednocześnie w C++ istnieją techniki programowania, wymuszajace pisanie
dobrze i bez absuradlnych błedów, jak z watku. Nie da się ich stosować w
C, ale można je stosować w C++. Niektóe lintery je wymuszają.

Pierwsza z brzegu z technik wspomagających jakość, za darmo: RIIA.

Innymi słowy w każdym jezyku można pisać dziadowski kod, ale niektóre
języki aktywnie mogą temu przeciwdziałać lub przynajmniej mają do tego
narzędzia zamiast pistoletu na wodę C.

>> Używasz C++ w tym jednym miejscu.
>> Reszta dnia wolnego.
> Reszta dnia na kotrolowanie tego, czy ktoś inny nie użył więcej z C++ niż
odpuszczasz.

To się nazywa review i jesli pracujesz w firmie robiącej coś wiecej niż
miganie diodami, to na pewno jakaś formę review kodu masz. I
kontrolujesz kod współpracowników, czy on jest w C czy C++ w sposób
formalny już teraz.

Masz review, prawda?

>> Czyli to problem ideologiczny. Nie możesz uwierzyć, że można pisać po
>> staremu i tam gdzie C++ się przydaje - użyć go. Musi być albo skrajna
>> prawica albo lewica. Recjonalizm zakazany.
> Sklonuj się to się uda.
> Ja zawsze chciałem mieć brata bliźniaka (niekoniecznie chciałbym mieć
> przy tym na imię Jarosław) - to bardziej realne niż 4 ręce.

Nie rozumiem po co. Pisanie w C++ oszczędza również czas. Nie musisz co
chwile wynajdywać kwadratowych kół albo emulować C++ na makrach.

Bo zdecydowana większosc kodu embedded, którą widziałem w życiu, to
emulacja C++ na makrach, generatorach kodu i fikusnych konstrukcjach.

Dawniej uważałem to za śmieszne, ale dzisiaj, po doświadczeniu zawodowym
jakie mam, uważam to za poważny problem tej branży.

"Nie, bo nie, napisze to sam".

>> Po prostu ich nie rozumiesz i to całkowicie zrozumiałe. Jak zaczniejsz
>> używać, szczególnie jeśli ktoś pokaże Ci jak, zrozumiesz, że pewne
>> konstrukcje w C są najzwyczajniej niebezpieczne i prowadzą do sytuacji
>> niewykryanych przez kompilator, jak w tym watku.
> Pewne konstrukcje w C++ są jeszcze bardziej niebezpieczne.

Które?

> I ogólnie C++ jest jeszcze bardziej niebezpieczne, bo zawiera wszystkie
niebezpieczeństwa C,
> plus jeszcze dodatkowe z C++.

Podaj przykład takiej konstrukcji w C++, która jest niebezpieczna i czai
się jak mina na biednego asemblerowca z C.

>> Pisanie we współczesnym C++ polega na wyrażaniu potrzeb w sposób
>> wysokopoziomowy. Zamaist "potrzebuję wiedziec ile to zajmuje ramu i
>> potem se podziele" piszesz "potrzebuje wiedzieć jakie to jest duże". To
>> jest bezpieczniejsze.
> Byś może rozmawiamy o zupełnie różnych C++.

To wrażenie odnoszę zawsze, kiedy gadam z embedowcami. Był tu taki jeden
kiedyś, co mówił, że jak zmieni się gcc na g++ to od razu trzeba cały
kod przepisać na obiektowy.

Fascynujący przypadek medyczny, ale chyba już tu nie pisze.

To tylko niewiedza. Ja programuję w C++ od lat ~25. Programiści embedded
słyszeli o C++ od szwagra kolegi. Nie wszyscy, ale ciągle większość
czerpie opinie z absurdalnych źródeł.

>> Do tego stopnia, że w jednym z coding standardów jakie miałem okazję
>> czytać, używanie sizeof w pętli for jest wykrywane przez linter na
>> etapie review. Ktoś widocznie miał dośc poprawiania takich bzdur.
> C++ minus to, co odwala linter, to już nie jest C++.

Brednia.

> I tu dochodzimy do kosztów wprowadzenia C++ w firmie.

Zerowe.

> Np. taki linter. I nowy coding standard.

Bzdura. Jesli tylko nie masz firmy z dykty i paździerza, to oba
narzędzia już tam masz. W C są tak samo przydatne, jak w C++.

> To koszty niezaprzeczalne. Zyski - możliwe, lecz niepewne.

Coding standard, review, lintowanie, unit testy, bazy bugów i masa
innych elementów programowania funkcjonuje w firmach od dziesięcioleci.

Idź i zapytaj, czy zyski są niepewne.

Wiele z nich szlag by trafił bez tych narzędzi. Są krytyczne, dla
dowolnego języka programowania i komplikacji projektu.

>> Nie chcesz tego. Semantyka referencji i zarządzanie pamięcią w Javie nie
>> nadaja się do mikrokontrolerów, szczególnie do zastosowań realtime, mimo
>> wielu prób wciśnięcia Javy do małych uC. Za to C++ jak najbardziej
>> pasuje, bo jest zdecydowanie bliżej sprzętu.
> Hmm, a we "współczesnym" C++ nie ma czegoś w rodzaju std::garbageCollector?

Nie.

Istnieją zewnątrzne bibliteki oferujące taki bajer.

Prawda taka, że w typowym małym embedded posiadanie heapu jest ogólnie
nierozsądne, a posiadanie GC jeszcze bardziej. A jak już go masz (heap),
to C++ oferuje RIIA a na nim możesz zabudować wyższe poziomy abstrakcji,
takie jak poole czy liczenie referencji.

C++ to narzędzie oferujace pewien zakres rozwiązań problemów, ale nie
forsuje jakiegoś konkretnego rozwiązania. Java forsuje GC, choć są
wersje bez.

Używałem GC w C++ do pewnego specyficznego zagadnienia. Mogę. Ale prawda
taka, że większośc softu w C++ stosuje raczej metody zarządzanie heapem
typu liczenie referencji albo ownership.

A w małych systemach nic nie stosuje. Bo i użycie malloc/new nie ma tam
sensu.

> Czym się różnią referencje w Javie i wskaźniki/referencje w C++?

Pominąłeś coś: *semantyka* referencji jest inna.

To oznacza, że w javie:

a = b

i w C++

a = b

oznaczają dwie kompletnie rózne rzeczy. Java przenosi uwspólniony
ownership, C/C++ kopiuje. C/C++ preferuje kopie, Java preferuje
uwspólnianie właśności.

Java robi to dlatego, że ma Garbage Collector i może.

W C++ jest kopia, bo to zgodne z semantyką C i nie ma w C++ tak naprawdę
żadnej pamięci allokowanej dynamicznie - allokacja jest dostarczana
przez zewnętrzne bibliteki, wględem samego języka. I może jej nie być,
co nie jest niczym dziwnym w embedded.

> Możliwością statycznej alokacji w C++?

W javie statyczna allokacja to po prostu statyczny obiekt. Allokowany
przy pierwszym użyciu.

Java jest znacznie mniej elastyczna.

W c++ to po prostu to samo co w C, powiększone o klasy, jak komuś potrzebne.

> To sobie w Javie stwórz i nie kasuj, będzie tam samo, a nawet lepiej,
> bo jakbyś chciał zacząć kasować to odchodzi jedno z największych bugo-bagien.

Allokacja w runtime nie jest za darmo: ryzykujesz fragmentację i w ogóle
potrzebujesz jakiegoś heapu.

To podstawowy powód średniego nadawania się Javy do embedded, nawet po
wycięciu jej z Garbage Collectora, semantyka języka jest mocno
niewygodna do obsługi ciasnej pamięci a bezustannie ją preferuje.

>>> Jak piszesz samemu to możesz sobie dyscyplinę typu: "używam TYLKO tego, tego i
tego z C++" narzucić.
>> Tak. To się nazywa coding standard, review, lint. Nie masz takiego
>> zestawu w firmie?
> Ja sam sobie sterem, żeglarzem, okrętem.

Przecięz przed chwilą mówiłeś, że powodem nieużywania C++ jest to, że
kolega może coś napisać i bedzie dramat.

Skoro jesteś sam, to te argumenty przestaja mieć sens.

> Ale jeszcze raz - czy coding standard, review, lint są za darmo?

Tak.

> Może są, daj namiar na jakiś opensource czy GNU.

Coding standard (jest ich wiele):
https://google.github.io/styleguide/cppguide.html

Review (jest ich wiele, są komercyjne):
https://www.reviewboard.org/

Linter (darmowych jest mało):
https://clang.llvm.org/extra/clang-tidy/

>>> Ale w zespole zaraz zaczną odwalać bzdury, "bo w C++ tak można".
>> Nie. Od tego jest code review + coding standard. Choć przyznaje, że to
>> pytanie/opinia czasem się pojawi, szczególnie jak zakaz idityczny. Na
>> przykład "nie wolno używać C++ bo go nie rozumiem".
> I dobrze, w pełni się z tobą zgadzam - narzędzi trzeba umieć używać.
> Ale to kosztuje.

Nie. Nic nie kosztuje. Ta wiedza ma wręcz ujemny koszt. Zyskujesz więcej
niż tracisz.

>> debilizmem. Ale czasem wrzaśnie na etapie kompilacji o jakimś fuckupie,
>> gdzie C przełknie bez popijania. I jak wstawisz w to zdanie "Java"
>> zamiast "C++" to dalej będzie prawda.
> Kompilacji? Raczej lintowania.

Kompilacji i lintowania. Oba wykrywają inne przestrzenie problemów.

> I mając do wyboru C oraz C++ jako nadzbiór C - wybiorę jednak C,
> mniejszy stopień komplikacji łatwiej badać.

To nie jest prawda od bardzo, bardzo dawna.

Typowy kod w C to asembler o sładni klamrowej, gdzie jest pełno void*,
intów i ch... wie co jeszcze.

W C++ masz więcej wysokopoziomowych typów i statyczne typowanie.

To dla lintera jest znaczące ułatwienie analizy składni.

> No a jak będzie nowe pokolenie to już nie będą musieli sięmieścić w pojedynczych kB
RAM.

Jak masz kB RAM to C++ jak znalazł. Dzięki kilku sztuczkom można sobie
prześlicznie i bezpiecznie pisać kod w ciasnym RAM.

To, że wspomniałeś tutaj małą ilośc RAMu oznacza, że komplenie nie
rozumiesz czym jest C++.

On niczego nie zmienia w ilosci RAMu ani kodu wynikowego, w większości
swoich fajnych funkcji. Prawie całe dobro płynące z C++ to tylko
metajęzyk, generujący bezpieczniejszy, a czasami lepszy kod wynikowy.

> Trzeba im tylko jako spadek zostawić dobry OS, inaczej rakiety zaczną spadać.

Jak Ci, co pisali w asemblerze, w "bezpiecznym" Ada i spowodowali spadek
Ariane 5?

Fuckup wszędzie jest możliwy.

> Może to i się do pokoju światowego przyczyni, takie kacapy nie będą miały dostępu
> do odpowiednio mocnych uC - takie z laktatorów nie wystarczą...

Popełniasz własnie ten bład, co prawie kązdy embedowiec - nie masz
pojęcia jak działa C++ ,więc zakłądasz, że wymaga ogromnych ilosci RAMu,
bo tam są obiekty a to prawie jak Java.

Nie wymaga. Generuje ten sam kod co C. ALe pozwala ten kod napisać
bezpieczniej, czytelniej, testowalniej. I zje tyle ramu, na ile styknie
IQ programisty.

do góry

On 18/05/2023 17:29, Marek wrote:
>> Przeniesięnie się z subsetu do przestrzeni gdzie istnieje to
>> rozwiązanie jest obarczone zerowym kosztem.
> A koszt czasu nauki?

Około 10 sekund na przeczytanie posta na usenecie, że jest std::size
zamiast sizeof.

Zyski? Pewnie kilka godzin debugowania teraz i w nastepnych przypadkach.

Mi wychodzi koszt ujemny.

do góry

On Thu, 18 May 2023 17:37:41 +0200, heby <h...@p...onet.pl> wrote:
> Około 10 sekund na przeczytanie posta na usenecie, że jest
> std::size
> zamiast sizeof.

A z jakiego powodu ktoś miałby w ogóle wpaść na to żeby zamieniać
sizeof. Trochę naciągnane.
jeśli ktoś w ogóle miałby świadomość że w C plus plus jest "lepiej"
to używał by tego od samego początku.
Žeby mieć taką świadomość użycia to niestety wcześniej musiałby się
tego trochę nauczyć. Więc kosz nauki nie jest tutaj zerowy a tym
bardziej ujemny.

--
Marek

do góry

On Thu, 18 May 2023 16:40:43 +0200, heby <h...@p...onet.pl> wrote:
> #define FOO_FLAG 1<<6
> #define BAR_FLAG 1<<3
> #define OUT_FLAG 1<<2
> i funkcję:
> void setFlags( int flags, int extra_flags );

A może zaczniemy od tego by tak diodami nie migać, co?
bo jak ktoś tak miga diodami to później sam sobie tworzy
(niesitniejace w innych sposobach) problemy, które później dzielnie
musi rozwiązywać niczym socjalizm.

--
Marek

do góry