On 19/05/2023 11:51, JDX wrote:
>> 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.
> No nie, zupełnie nie za darmo. Trzeba poświęcić sporo czasu na
> dokształcanie, aby efektywnie używać nowego języka.

Ludzi czytających ten wątek kosztowało 10 sekund pozbycie się złego
nazywku liczenia długości przez sizeof.

> Aby np. dowiedzieć
> się, że w ogóle istnieje coś takiego jak std::size()

I to w zupełności wystarcza, aby wykonać jeden krok do przodu. natępne
przyjdą same, jako że ten pierwszy był najtrudniejszy.

>. Bo sama zamiana,
> bez podstaw ,,teoretycznych"

Te podstawy mieszczą się na 1 stronie dokumentacji, a w zasadzie
mieszczą się w 10 linijkach exampla na końcu. Nie trzeba wiedzieć, jak
to działa aby z tego korzystać. To zabawne, ale w zasadzie wiele
elementów w C++ jest znacznie łatwiejszych w użyciu, niż ręczne
dziobanie w C, a efekt ten sam.

>, kompilatora C na kompilator C++ nie ma
> większego sensu. Chodzi o to, aby używać C++, a nie ,,C z klasami".

Nie.

Chodzi o to, aby używać ułatwień. W C i C++.

Nie ma absolutnie wymogu używania C++ w sensie klas, new/delete,
templates. Nie musisz nawet wiedzieć, że to jest w C++. Używasz tego,
czego potrzebujesz, jak st::size albo RIIA. I nie ma problemu.

do góry

On 19/05/2023 12:07, JDX wrote:
>> jest kontekst i cel użycia. To jest pierwotna potrzeba. sizeof to
>> tylko workaround sprzed 30 lat na brak size. Przyznaje, popularny do
>> dzisiaj.
> No Panie, ale jak za pomocą std::size() otrzymać rozmiar tablicy w
> bajtach? :-)

Do tego jest sizeof.

Dla rozmairu w *elementach* jest std::size()

W examplu z błedem programista chciał poznać rozmiar tablicy w
elementach, nie bajtach.

Użył workaroundu i jak to z workaroundami bywa, pomylił się.

Jeśli piszesz w C++ prawidłowo, ilość użyć sizeof jest znikoma i dotyczy
głównie kodu pracujacego na poziomie allokatorów czy sprzętu. Normalny,
algorytmiczny, kod prawie nigdy nie wymaga wiedzy o rozmiarach czegośtam
w bajtach.

do góry

On 19.05.2023 12:16, heby wrote:
> On 19/05/2023 12:07, JDX wrote:
>>> jest kontekst i cel użycia. To jest pierwotna potrzeba. sizeof to
>>> tylko workaround sprzed 30 lat na brak size. Przyznaje, popularny do
>>> dzisiaj.
>> No Panie, ale jak za pomocą std::size() otrzymać rozmiar tablicy w
>> bajtach? :-)
>
> Do tego jest sizeof.
>
> Dla rozmairu w *elementach* jest std::size()
>
> W examplu z błedem programista chciał poznać rozmiar tablicy w
> elementach, nie bajtach.
>
> Użył workaroundu i jak to z workaroundami bywa, pomylił się.
>
> Jeśli piszesz w C++ prawidłowo, ilość użyć sizeof jest znikoma i dotyczy
> głównie kodu pracujacego na poziomie allokatorów czy sprzętu. Normalny,
> algorytmiczny, kod prawie nigdy nie wymaga wiedzy o rozmiarach czegośtam
> w bajtach.
>

do góry

On 19.05.2023 12:16, heby wrote:
> On 19/05/2023 12:07, JDX wrote:
>>> jest kontekst i cel użycia. To jest pierwotna potrzeba. sizeof to
>>> tylko workaround sprzed 30 lat na brak size. Przyznaje, popularny do
>>> dzisiaj.
>> No Panie, ale jak za pomocą std::size() otrzymać rozmiar tablicy w
>> bajtach? :-)
>
> Do tego jest sizeof.
No, czyli, służą do czego innego, więc jedno nie jest workaroudem na
brak drugiego.

do góry

JDX <j...@o...pl> napisał(a):
> No, czyli, służą do czego innego, więc jedno nie jest workaroudem na brak
> drugiego.

Jest, bo na tym polega workaround, że używasz czegoś nieprzeznaczonego do
danego celu. sizeof() nie służy do zwracania liczby elementów ale czasem
może dać poprawny wynik (dla typu jednobajtowego). Przy typie wielobajtowym
trzeba podzielić przez sizeof(typ_wielobajtowy). Można też w ogóle nie
używać sizeof() ale mieć stałą definiującą rozmiar i używać jej zarówno do
deklaracji tablicy jak i do dostępu do tej tablicy. Szczególnie przydatne
jak ta tablica jest potem gdzieś przekazywana i ktoś przez roztargnienie
mógłby zrobić sizeof() na wskaźniku i dostać (zwykle) 4 lub 8 zależnie od
architektury zamiast rozmiaru tablicy.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 19.05.2023 12:12, heby wrote:
[...]> On 19/05/2023 11:51, JDX wrote:

>> , kompilatora C na kompilator C++ nie ma większego sensu. Chodzi o to,
>> aby używać C++, a nie ,,C z klasami".
>
> Nie.
>
> Chodzi o to, aby używać ułatwień. W C i C++.
>
> Nie ma absolutnie wymogu używania C++ w sensie klas, new/delete,
> templates. Nie musisz nawet wiedzieć, że to jest w C++. Używasz tego,
> czego potrzebujesz, jak st::size albo RIIA. I nie ma problemu.
Jak nie ma wymogu, to po co zmieniać kompilator? No i kwestia
zasadnicza. Wiem, że w C nie ma tego, czego potrzebuję. Aby dowiedzieć
się, czy w C++, a w zasadzie w STL , jest to, czego potrzebuję, to muszę
poświęcić czas. Nie twierdzę, że nie warto przejść z C na C++. Twierdzę,
że nie jest to ani za darmo ani przynajmniej jakoś specjalnie tanie.
Trochę czasu na czytanie i ćwiczenia praktyczne z kompilatorem trzeba
zainwestować...

BTW. AFAIR w C, korzystając z rozszerzeń gcc, również można
wykorzystywać RIIA. :-)

do góry

On Thu, 18 May 2023 12:44:11 +0200, Janusz wrote:
> W dniu 18.05.2023 o 12:18, Marek pisze:
>> On Thu, 18 May 2023 08:55:51 +0200, Janusz <j...@o...pl> wrote:
>>> Dla mnie trochę dziwny jest ten fragment, reason-nie wykorzystana
>>> zmienna a komunikat (z tablicy)  dwa razy wywołujesz ten sam, zmienna
>>> status.
>>
>> Kod na potrzeby posta trochę uprościłem. Znalazłem dziada:
>>
>> unsigned short BT[300];
>> int i;
>>
>> for (i=0; i<sizeof(BT);i++)
>>   BT[i] = getval(i);
>>
>> Analizując mapę linkera widać, że BT była umieszczona tuż przed tamtą
>> tablicą ze wskaźnikami do stringów.
> No i co z tego, przecież to dwie osobne tablice i osobno się adresują i
> chyba kompilator czy linkier nie ma tu błędu w adresacji?

Tablice moze i osobne, ale jak przekroczysz rozmiar BT, to trafi nie
wiadomo gdzie.

>> Na starość to trzepać worki po cemencie a nie programować....
> Eee tam, ja mam już prawie 63 i dalej piszę programy i naprawiam
> elektronikę.

Ale potem takie krzaczki jak powyzej wychodzą :-)

J.

do góry

On 19/05/2023 12:57, JDX wrote:
>> Nie ma absolutnie wymogu używania C++ w sensie klas, new/delete,
>> templates. Nie musisz nawet wiedzieć, że to jest w C++. Używasz tego,
>> czego potrzebujesz, jak st::size albo RIIA. I nie ma problemu.
> Jak nie ma wymogu, to po co zmieniać kompilator?

Aby dostać darmowe udogodnienia.

Z tych samych przyczyn jak legacy programmers lat temu 40 zmieniali
asembler na C.

Też dało sie wszystko w asm napisać. A jednak zmienili. Dziwne, nie?

> No i kwestia
> zasadnicza. Wiem, że w C nie ma tego, czego potrzebuję. Aby dowiedzieć
> się, czy w C++, a w zasadzie w STL , jest to, czego potrzebuję, to muszę
> poświęcić czas.

Tak. Zmienić kompilator na g++. Zazwyczja to wszystko, czasami kilka
detali więcej jeśli piszesz coś wyjątkowo dziwacznego (np. wyłaczenie
wsparcia wyjątków itp).

> Nie twierdzę, że nie warto przejść z C na C++. Twierdzę,
> że nie jest to ani za darmo ani przynajmniej jakoś specjalnie tanie.

Nic nie kosztuje, w większości wypadków. Jeśli przejście coś kosztuje,
to znaczy że masz jakiś niezły fuckup w C. Tak, są bardzo interesujące
projekty, które w C++ się nie kompilują, a właściciele będą bronić tego
guano jak niepodległości. Miałem do czynienia kilka razy. To stan umysłu.

> BTW. AFAIR w C, korzystając z rozszerzeń gcc, również można
> wykorzystywać RIIA. :-)

Nikt nie broni, tylko po co w C?

do góry

W dniu 19.05.2023 o 09:45, JDX pisze:
> On 18.05.2023 21:12, Janusz wrote:
> [...]
>> wklepywało się te kilka komend w asemblerze. Owszem był jakiś
>> kompilator asemblera obsługujący monitory ale to do czegoś wiekszego
>> się nadawało a
> Nigdy nie było żadnego kompilatora assemblera na jakąkolwiek platformę... :-)
Eee tam czepiasz się, nazwijmy to translator który tłumaczył mnemoniki i
liczył adresy, teraz lepiej?

--
Janusz

do góry

On 19/05/2023 14:36, Janusz wrote:
> nazwijmy to translator

Nazwijmy to asembler.

do góry