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