On 07/12/2025 17:46, ??Jacek Marcin Jaworski?? wrote:
> Dzięki za wyjaśnienia. Jednak widzę, że podane przez Ciebie linki nie
> prowadzą do art. które opisują tą sprawę wyczerpująco, bo wspominasz o
> ipp, który one nie omawiają.

ipp nie są tylko do templates, ale do innych zastosowań. Możesz je
traktować jako alternatywę dla explicit instantiation ale również do
modularyzacji kodu dużych klas.

https://jmmv.dev/2013/12/header-files-c-ipp-files.ht
ml

Hardkorzy od C używali czasem, w powiązaniu z makrami, do emulacji C++,
z przyczyn religijnych (i do dzisiaj używają, to już kult).

> Jednak puki co bez przykładowego, DZIAŁAJĄCEGO kodu ta sztuczka dla mnie
> pozostaje to jedynie ciekawostką.
Boost jest przykładem działającego przykładu.

Tu masz jakiś mikro dla explicit instantiation:

https://gist.github.com/jdtournier/2afaeac3b94bf2fe1
dc9160d4a61356c

Tu masz jakąs biblitekę korzystającą z explicit instantiation:

https://github.com/hliberacki/cpp-member-accessor

Co do ipp, to oczywiście boost.

do góry

On 07/12/2025 13:20, io wrote:
> języki
> programowania służą do wyrażania kodu zrozumiałego dla wszystkich.

A nie do optymalnego rozwiązania problemu? Czyli zarówno czytelności,
prędkości, objętości, dostepności dev, przenośności itd itp? Tylko do
wyrażania kodu zrozumiałego dla wszystkich?

do góry

W dniu 7.12.2025 o 13:20, io pisze:

> Tak elastyczny, że ciężko zrozumieć co ktoś inny nagrzmocił. Gdyby to
> służyło do jednorazowej komunikacji z komputerem to ok, ale języki
> programowania służą do wyrażania kodu zrozumiałego dla wszystkich.

Skoro czegoś nie rozumiesz, to nie jest to wina języka. To twoja wina :]


--
Pixel(R)??
Albo PiS albo Polska

do góry

On Sun, 7 Dec 2025 15:00:52 +0100, heby <h...@p...onet.pl> wrote:

> 3) C++ się zmienia i to straszne. Nikt nie wie w jakiej wersji
> pisze.

Ależ zarzut jest raczej taki, że zmienia się tak bardzo, że to
powoduje zamęt. Przynajmniej u zwykłych praktyków bo przecież nie u
omnipotentów wszystkowiedzących jak Seba.


> 4) Nie umiem pisać duzych projektów w C++ więc nikt nie umie.

Akurat w filmie kilka razy autor podkreśla, to że właśnie ma
doświadczenie z dużymi projektami i jego punkt widzenia wynika z tego
doświadczenia. Gdy się przyjrzy dobrze apologetom C++ to się okazuje,
że ich doświadczenie to najczęściej Hello World!.


> 10) W C++ nie ma GUI! Na szczęscie takie GUI istnieje w Pythonie na
> przykład, który (tylko niech nikt się o tym nie dowie) korzysta
> m.in. z
> Qt w C++.

Dość komiczna argumentacja, czyli nie ma guja w C++ bo jest przecież
w pythonie, który korzysta z qt który z kolei korzysta z (podobno)
przestarzałego C++...
Już pomijając awersję do pythona, że z mojego punktu widzenia jako
zwykłego usera jakiekolwiek narzędzie, które było pilnie do
uruchomienia na szybko a na nieszczęście zostało napisane w pythonie
(po jaki *uj?) to nie działało. Albo python za stary, albo brak jakiś
modułów a pip install module nie działa bo to coś tam koliduje z
systemowym pakietowaniem.
Za każdym razem jak widzę coś w pythonie to mnie krew zalewa bo już
wiem za na 99% nie zadziała bo zgodnie z aktualną modą każdy nowy
program w pythonie będzie wymagał zawsze jakieś egzotycznej
biblioteki/modułu której akurat się nie mam. Widać python działa wg
zasady że jak chcesz się napić piwa to musisz kupić cały browar.
Kiedyś znajomy podzielił się podobną opinią mówiąc "dziwni ci
programiści pythona, bo żaden niczego sam nie umie napisać by
działało "standalone" tylko muszą korzystać z innych (modułów) co
jest irytujące.".
Ja wiem na pierwszy rzut ucha można machnąć rękami, że ktoś nie
rozumie idei biblioteki. Co do zasady - tak. Ale z pkt. widzenia
użytkownika to on nie potrzebuje pythona, użytkownik potrzebuje
spełnienia tzw. paradygmatu exe: potrzebuje narzędzia *działającego*
as is a dokładniej to nawet nie potrzebuje narzędzia tylko ważny jest
efekt (jak widać teoria Levitt'a, że user potrzebuje efektu a nie
narzędzia nie ogranicza się tylko do marketingu). Jak idę do sklepu
kupując auto to chcę auto kompletne, jeżdżące. A nie, że sprzedawcą
mówi, że u nas są tylko budy, silnik musi pan ściągnąć z... Koła
z...

--
Marek

do góry

On Sun, 7 Dec 2025 17:32:24 +0100, heby <h...@p...onet.pl> wrote:
> Tak. Przy czym z małym twistem: jest niezwykle mało programistów
> C++
> majacych o niej pojęcie.

Zadziwiające, że ten argument zawsze pada bezrefleksyjnie.
Po co zatem narzędzie, który ogarnia tylko niewielki ułamek
użytkowników a ogromna większość tylko psuje nim większość co zrobi
dyskwalifikuje narzędzie a nie userów.

--
Marek

do góry

On Sun, 7 Dec 2025 18:14:29 +0100, heby <h...@p...onet.pl> wrote:
> A nie do optymalnego rozwiązania problemu?

Jeśli problem zawęża się *tylko* do rozwiązania problemu i ma spełnić
jedynie paradygmat exe to tak. Ale gdy kod wchodzi w skład projektów
ciągle rozwijanych i modyfikowanych to czy kwestia prawidłowego
zrozumienia nie jest kluczowa?

--
Marek

do góry

On 07/12/2025 18:58, Marek wrote:
>> A nie do optymalnego rozwiązania problemu?
> Jeśli problem zawęża się *tylko* do rozwiązania problemu i ma spełnić
> jedynie paradygmat exe to tak. Ale gdy kod wchodzi w skład projektów
> ciągle  rozwijanych i modyfikowanych to czy kwestia prawidłowego
> zrozumienia nie jest kluczowa?
Wuciąłeś dokładnie to, o czym pisałem. Wybór języka programowania jest
zbiorem decyzji z różnych dziedzin. Samo pojmowanie języka nie jest
dostatecznie dobrym argumentem, jest wręcz najgorszym. Inaczej
mielibyśmy kernele pisane w BASICu.

do góry

On Sun, 7 Dec 2025 19:01:57 +0100, heby <h...@p...onet.pl> wrote:
> Wuciąłeś dokładnie to, o czym pisałem. Wybór języka programowania
> jest
> zbiorem decyzji z różnych dziedzin.

Czyżby?
Wielokrotnie (w projektach skali korpo) spotkałem się z wyborem typu
Heniek wybrał [tu pada język lub architektura] bo tylko on na tym się
zna (czyli kernel w Basicu).
Drugi rodzaj wyboru to: nikt nie wie dlaczego tak wybrano, bo
technologia przyszła z dobrodziejstwem inwentarza spółki jaką się
kupiło.
Życie pokazuje zupełnie coś innego.

--
Marek

do góry

On 07/12/2025 18:53, Marek wrote:
>> Tak. Przy czym z małym twistem: jest niezwykle mało programistów C++
>> majacych o niej pojęcie.
> Zadziwiające, że ten argument zawsze pada bezrefleksyjnie.

Refleksja jest dostateczna. Pewne techniki pisania w C++ są mało znane.
To datego, że większośc programistów na rynku C++ to tak naprawdę C+.
Jakieś klasy ale nie za dużo, templaty unikają jak ognia, zero pojęcia o
arachitekturze dużej skali, linkowanie ogarnia jedyny w firmie senior z
brodą, a że on należy do kultu C, to klnie przy tym i potem wychodza z
tego takie debilizmy jak wspomniany film na YT.

Niewiele tu pomaga literatura, ksiązki które omawiają takie problemy
praktycznie nie istnieją. Prościej napisać kolejną o Node.js niż o boost.

Bez przejścia przez szkołę zycia w firmie, która te techniki uzywa na
codzień, nie masz szans sie z nimi zapoznać.

Ja mialem okazję np. ogarnąć closures w parsere spirit, bo taki kod
musiałem rozwijać. Google kiedyś prezentowało na ten temat 0 wyników.

> Po co zatem narzędzie, który ogarnia tylko niewielki ułamek użytkowników

To powoduje, ze pisanie w C++ nie jest dla każdego. Wręcz, z biegiem
lat, coraz mniej programistó migrujacych z różnych gówien, jak JS,
nadaje się to pisania kodu w C++. Nawet nie z powoduj języka, tylko
braku śladu pojęcia o architekturze komputerów. Tłumaczenie
programiście, przez 5 godzin, czym jest wskaźnik już przerabiałem. To
nie ma znaczenia, czy w C czy C++. On tego nie pojmuje. To całkiem
niezły programista jest, zna frameworki o których nie słyszałem i nie
potrfiłbym ich uzyć.

Pokolenie wychowane na Z80/6502 czy Amidze powoli wykrusza się do
stanowisk managerskich, nowi nie mają pojęcia jak działa hardware. W
efekcie czego na koniec nie będzie komu tego utrzymywać, jak w COBOLu.
No dobra, przesadzam, AI będzie. I niewątpliwie przepisze kernel Linuxa
do JS. Idę o zakłąd, że da radę, bo już próby były. Ależ ciekawe czasy
przed nami.

> a ogromna większość tylko psuje nim większość co zrobi dyskwalifikuje
> narzędzie a nie userów.

Nie, z powodu, że większość społeczeństwa nie potrafi kierować
ciągnikiem sidłowym nie wynika, że ciągniki siodłowe są do zaorania.
Znaczy są do orania, ale ... no ...

do góry

On 07/12/2025 18:48, Marek wrote:
>> 3) C++ się zmienia i to straszne. Nikt nie wie w jakiej wersji pisze.
> Ależ zarzut jest raczej taki, że zmienia się tak bardzo, że to powoduje
> zamęt.

Czyli jaki zamęt? Jak napiszesz kod w jakiejś wersji C[++] i odpalisz na
nowszej wersji to połowa nie zadziała?

Gdzie ten zamęt? Bo się jedna linia na milion nie skompilowała? Ona się
zazwyczaj nie kompiluje z powodu błedu.

> Przynajmniej u zwykłych praktyków bo przecież nie u omnipotentów
> wszystkowiedzących jak Seba.

Ale pokaż mi praktyki, gdzie Ci się zasiał zamęt, że ktoś zmienił
kompiltor z C++XX na C++XX++.

>> 4) Nie umiem pisać duzych projektów w C++ więc nikt nie umie.
> Akurat w filmie kilka razy autor podkreśla, to że właśnie ma
> doświadczenie z dużymi projektami i jego punkt widzenia wynika z tego
> doświadczenia. Gdy się przyjrzy dobrze apologetom C++ to się okazuje, że
> ich doświadczenie to najczęściej Hello World!.

Dziwne, mam doswiadczenie z zajebiście duża bazą kodu w C++ i jakoś nie
widzę problemów z utrzymaniem tej bazy. To wynika z dyscypliny.

Natomaist to nie są jedyne moje doświadczenia. W wielku firmach mają
podejście "zlinkujmy to wszystko w chuj" i potem na bazie tego generują
się jakieś debilne opinie o tym jaki C++ jest nienadający się do niczego.

Nie, to "lokalni architekci" nie nadają się do niczego. Nie mają pojęcia
jak projektować, modularozować, ciąć abstrakcjami, dynamizować bazę
kodu. Bo oni 20 lat temu pisali aplikację ktora miała 10tyś lini kodu, a
teraz ma 10mln lini kodu i dalej wymusząją te techniki, bo obecnie są
architektami z władzą decyzyjną.

No i ta fobia, na widok słowa "refaktoring", która powoduje że
menagement dostaje ataku sraczki.

>> 10) W C++ nie ma GUI! Na szczęscie takie GUI istnieje w Pythonie na
>> przykład, który (tylko niech nikt się o tym nie dowie) korzysta m.in.
>> z Qt w C++.
> Dość komiczna argumentacja, czyli nie ma guja w C++ bo jest przecież w
> pythonie, który korzysta z qt który z kolei korzysta z (podobno)
> przestarzałego C++...

Nie, argumentacja jest taka, że pod spodem tych wszystkich biblitek
graficznych nowoczesnych jezyków bardzo często jest sobie GUI w C/C++.

Jakie to ironiczne. Język, kóry nie ma GUI jest bazą kodu dla biblitek GUI.

> Widać  python działa wg
> zasady że jak chcesz się napić piwa to musisz  kupić cały browar.

Z grubsza dotyczy to wszystkich języów programowania z systemami
pakietowymi. Ostatnio z przyczyn pozalogicznych, zajmuje się Node.js.
Takiej ilosci konfliktów systemu pakietowego nie widziałem nigdy. To się
nie mieści w głowie. Aż napisałem skrypt który instaluje kazdy pakiet
osobno w konkretnej wersji, bo drugi raz przez to piekło nie chcę
przechodzić. Zapytałem znajomego jak oni z tym żyją. Powiedział, że raz
ustawionego środowiska się nie rusza, tylko dyski klonuje. Aha.

do góry