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