On 07/12/2025 22:00, Marek wrote:
>> To ekspert. Jak by nie był ekspertem, to by o to zapytał kogoś. A że
>> nie zapytał, tylko od razu odpalił nagrywanie, to niewątpliiwe
>> ekspert, który już wiedzy nie potrzebuje, za to zapałał potrzebą
>> dzielenia się swoimi przemyśleniami mając całośc wiedzy.
> Zamiast ironizować mógłbyś zrobić film "w odpowiedzi na". Byłoby ciekawiej.

Ale ja się na C++ nie znam. Jestem w minimum lokalnym krzywej
Dunninga-Krugera.

>> Tak, autor myśli że porównanie JS do C++ to dobry pomysł.
> Częste ironizowanie prowadzi do nabytej ignorancji lub braku rzetelnej
> oceny faktów. Autor filmu nie zawsze i nie wszędzie każdy problem
> kończył porównaniem do JS

Nigdzie nie napisałem, że każdy problem porównał do JS. Porównał jakieś
problemy. Ze szczególnym uwzględnieniem tych najbardziej absurdalnych,
albo z głupoty, albo z clickbaitu.

Choć jeden z nich to dyskwalifikacja całości bredzenia.

> a porównania jak już były dotyczyły wąskiego
> kontekstu danego zagadnienia. Nie jestem apologetą JS ale przywołując
> jedno porównanie z pamięci: jeśli w JS robi się coś w jedną prostą
> jednoznaczną instrukcją gdy to samo w C++ osiąga się skomplikowanum
> niejednoznacznym ciągiem wielu instrukcji podatnych i tak na złe użycie
> to w kontekście tego konkretnego rozwiązania co jest lepsze JS czy C++?
> Tylko tak bez filozofowania.

Koszt "łatwo w JS" zapłacisz w cyklach zegara.

Tam, gdzie template find_if z C++ zredukuje się do prostej pętli w
asemblerze mającej kika cykli, w JS może się skończyć setkami instrukcji
interpretowanych dynamicznie, bo JS nie wie z jakim typem ma do
czynienia i musi to rozkminiać za każdym razem.

Więc jesli chcesz pokazać, ze JS jest łatwiejszy, to jak znalazł.

Ale jesli nie zajmujesz się dicking-around, tylko zależy Ci na
prędkości, rozwiązanie z template generuje lepszy kod do tego jednego
rozwiązania, niż uniwersalny z JS.

Argument, że JS jest lepszy, bo jest łatwiejszy nie ma sensu: ktoś już
wybrał C++ w danym zastosowaniu, bo jest szybszy i zazwyczaj obecnośc
C++ oznacza, że był to właśnie główny powód pisania w C/C++. Nie zawsze,
ale bardzo często. Więc można się tylko popukać w głowę, że co mi po
ładniejszym zapisie, jak potrzebujemy maksymalnej, wręcz optymalnej,
prędkości.

To jak porównanie BMW do traktora. Jednym i drugim zaorasz pole, ale
traktorem wydajniej, choć BMW minimalnie ładniejsze.

>> Dziwne że nie widzisz, skoro bardzo duże i bardzo drogie aplikacje,
>> przy których kod windowsa czy linuxa jest śladowy, napisano w C++. I
>> nie było wyjścia, ze względu na potrzebę ekstrakcji każdego cyklu cpu.
> Nie pytam o wielkość ani o cenę ale o user experience. Jak coś jest już
> wielkie to najczęściej ma słaby user experience.

User experience w mojej branży to np. to, czy symulacja zakończy się po
4 tygodniach, czy po 3.5 tygodnia.

Nie wiem jaki user-experience masz na mysli, ale ja pracuje w branży,
gdzie jest prawdopodobnie biegunowo odległy od Twojego.

Zdefniuj user experience.

>> Jeśli potrzebujesz konkretnego przykładu, to modelsi.Nie da się go
>> napisać
> "Nie da się go napisać" to nie odpowiedź na ocenę czy jest zajebiste wg
> user experience.

Nie jest. Specjalnie go wybrałem. To jeden z najtoporniejszych programów
jakie kiedykolwiek będziesz używał. Nie da się z nim nic porównać, to
nie jest experience, to trauma rozrywająca aż do kości.

I ludzie korzystają.

Bo to, czy to się wygodnie czy nie wygodnie używa, nie ma praktycznego
znaczenia. Ważne, czy przesymulujesz coś w tydzień czy dwa. Jak by go
napisali w JS to byś przesymulował w rok. Może.

Taka nisza.

User experience mierzony jest czasem pracy symulatora.

Taki user-experience masz na myśli? Czy znowu jakieś nieporozumienie?

> Manipulujesz pisząc prawdę i półprawdy.
> Tak wideo jest o C++ i nie porównuje wszystkiego do JS. Jest też dużo o
> całym ekosystemie wokół, bibliotekach, ABI, problemów z .h i

Wszystkie te "problemy" wymagają głębszego omówienia, bo niektóre z nich
dziwnym trafem brzmią przy bliższym poznaniu jak ficzery i zalety. Tylko
trzeba wiedzieć jak z nich korzystać.

Przejdź na pl.c.l.c i zrób wątek o każdym. Bedzie lepszy fokus.

> zaśmiecaniem  podpowiedzi w IDE (zawsze mnie mierziło, że programista
> potrzebuje jakieś podpowiedzi nazw, to on jest programistą i powinien
> wiedzieć co chce napisać) i dużo innych ciekawych rzeczy, może byś się
> odniósł do reszty?

Ale do czego konkretnie?

IDE jest absolutnie niezbędne. Jesli masz milion lini kodu, szczególnie
OOP, to nie jesteś w stanie spamietać wszystkich nazw metod, zwracanych
typów, namespaces. To jest ficzynie niemożliwe, ponadto nie piszesz sam.
Copilot też nie ogarnia, zmyśla metody, bo sam nie wie. Cursor to samo.
Dlatego powstały techniki jak intelisense i cośtam z clanga. To
absultnie niezbędne aby w sytuacji gdy masz projekt składający się z
gigabajta plików źródłowych mieć narzedzie pozwalające na podpowiadanie
nazw. Działą średnio, ale z doświadczenia powiem, że jakośc działania
InteliSense jest proporcjlnana do jakosci architektury kodu. W kodzie
spieprzonym nie działa. A potem często słyszę kwiczenie, jake to IDE bez
sensu.

> Istotne są wnioski z dyskusji a nie jej powód.
Pod warunkiem, że ustalimy już o czym jest dyskusja.

To najłatwiej zrobić otwierając nowy post na grupie i dla zmyłki dać
taką treść, jaką chcemy aby dyskusja przypominała.

do góry

W dniu 7.12.2025 o 18:00, heby pisze:
> Co do ipp, to oczywiście boost.

Właśnie o przykład do ipp pytam, a nie o "explicit instantiation" - bo
mówię, że to drugie łapię.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska??, EU??;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<j...@e...gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

do góry

On 08/12/2025 01:44, ??Jacek Marcin Jaworski?? wrote:
> Właśnie o przykład do ipp pytam, a nie o "explicit instantiation" - bo
> mówię, że to drugie łapię.
ipp to cpp, ale napisany z myślą, aby było mozliwe #include "foo.ipp" w
innym pliku ipp lub cpp.

W przypadku templates zawiera definicje metod. Użwa się tak:

foo.cpp:
#include "bar.ipp"
class Foo {[...]};
[...]
Bar<Foo> bar;

spam.cpp:
#include "bar.ipp"
class Spam {[..]};
[...]
Bar<Spam> bar;

W ten sposób foo.cpp i bar cpp dostają własne specjalizacje, nic o sobie
nie wiedzą, a nagłówek bar.hpp nie zawiera definicji.

Programista C będzie zaś używał tak:

fancy.cpp:
#define SIZE 10
#include "fixed_size_container.ipp"
#define SIZE 20
#include "fixed_size_container.ipp"

I dzięki następnym machlojom z makrami dostanie w wyniku tego jakieś dwa
typy z 10 i 20 w nazwie, włącznie z definicjami funkcji "dostosowanymi"
do SIZE, takie jak np. get_container_element_10(void *container, int
index) itp używając jakiś sztuczek z ##.

do góry

On Sun, 07 Dec 2025 11:07:02 +0100, Marek wrote:
> Oczywiście, że C++:
> https://www.youtube.com/watch?v=7fGB-hjc2Gc
>
> Ja myślałem, że da się problemy wskazać w max 15 min i pozamiatane
> ale żeby przedstawić wszystkie nonsensy i głupoty tego języka
> potrzebne jest 2h literalnego wymieniania to się nie spodziewałem...

W przypadku innych języków omówienie ich całych zajmuje 2h ? :-)

Czekamy na odcinek na Javie, JS, C#, Python.

Occam, Ada, Fortran, Cobol, PL/1 ...

Fortran ciagle darzę jednak pewnym szacunkiem.

J.

do góry

W dniu 8.12.2025 o 08:16, heby pisze:
> On 08/12/2025 01:44, ??Jacek Marcin Jaworski?? wrote:
>> Właśnie o przykład do ipp pytam, a nie o "explicit instantiation" - bo
>> mówię, że to drugie łapię.
> ipp to cpp, ale napisany z myślą, aby było mozliwe #include "foo.ipp" w
> innym pliku ipp lub cpp.
>
> W przypadku templates zawiera definicje metod. Użwa się tak:
>
> foo.cpp:
> #include "bar.ipp"
> class Foo {[...]};
> [...]
> Bar<Foo> bar;
>
> spam.cpp:
> #include "bar.ipp"
> class Spam {[..]};
> [...]
> Bar<Spam> bar;
>
> W ten sposób foo.cpp i bar cpp dostają własne specjalizacje, nic o sobie
> nie wiedzą, a nagłówek bar.hpp nie zawiera definicji.

Już chyba kumam ideę! W pliku foo.h++:
#include "Bar.h++" // Z deklaracją kl. szablonowej
class Foo {...}; // Deklaracja kl. Foo
extern Bar<Foo>; // Bar<Foo> jest konkretyzowany "gdzie indziej"

W pliku foo.c++:
#include "Foo.h++"
#include "Bar.i++" // Def. f. kl. szablonowej Bar
Bar<Foo>; // Tu jest to "gdzie indziej"
// Tu def. f. kl. Foo

W pliku Bar.i++:
#include "Bar.h++" // Z deklaracją kl. szablonowej
// Tu def. f. szablonowych kl. Bar

W ten sposób nie zachodzi konieczność konkretyzacji Bar<Foo> w każdej
jednostce translacji, która go używa (czyli w plikach *.o tworzonych z
*.c++).
Czy coś takiego miałeś na myśli?

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska??, EU??;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<j...@e...gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

do góry

On Mon, 8 Dec 2025 10:00:26 +0100, "J.F"
<j...@p...onet.pl> wrote:
> Czekamy na odcinek na Javie, JS, C#, Python.
> Occam, Ada, Fortran, Cobol, PL/1 ...

W filmie @1:58:48 autor przedstawia wykres odnoszący się do tego.

--
Marek

do góry

On 08/12/2025 11:55, ??Jacek Marcin Jaworski?? wrote:
> Czy coś takiego miałeś na myśli?

Coś w ten deseń.

Przy czym technika z ipp jest alternatywą, a nie koniecznością, jesli
używasz explicit instantiation.

do góry

Marek <f...@f...com> wrote:
> On Sun, 7 Dec 2025 20:15:38 +0100, heby <h...@p...onet.pl> wrote:
>
>> Jakich chcesz dowodow i na co?
>
> Dowodów w postaci zajebistego softu w ocenie końcowego użytkownika
> softu. Mnie nie interesują programiści, jacy są i czy język jest
> zajebisty bo umożliwia to czy tamto. Ja
> chcę zachwycić się nad softem, który spełnia moje oczekiwania, jest
> szybki (i mały objętościowo) i po prostu działa (najchętniej bez
> ciągłej schizofrenicznej aktualizacji).

Soft może być mały tylko wtedy jak rozwiązuje prosty problem.
Jak chcesz przykład relatywnie małej rzeczy z szablonami to
możesz popatrzeć na biblitekę NTL. Jest szybka w sensie że
zrobienie czegoś co działa z porównywalną szybkością to dużo
roboty (z której większość to nie jest programowanie, po prostu
trzeba zrozumieć potrzebne algorytmy). Jest bibliteka w C
z podobnymi funkcjami (flint) i szybkością. flint zamiast
szablonów używa makra preprocesora C. Tak że w przypadku
NTL nie działa argument "nie da się zrobić w innym języku".
Ale to są małe rzeczy. Jak wejdziesz na 10 mln linii kodu,
to nawet jakby się dało zrobić w innym języku to nikt
nie będzie ryzykował konwersji C++ na powiedzmy C. Konwersje
z C na C++ są dość powszechne. heby może pisać że to daje
marny C++, ale główna motywacja takich kowersji to dostępność
w C++ mechanizmów których nie ma w C, a po konwersji używa
się tych mechanizmów.

Jak rozumiem projekt Carbon chce być "lepszym C++", w
szczególności chcą żeby kowersja z C++ na Carbon była
w dużym stopniu automatyczna. Ale jak/jeśli Carbon
stanie się poważną alternatywą dla C++ to większość
twojej krytyki powinna się dalej stosować, tzn.
udany nowy język będzie się mocno zmieniał, będzie
używany do dużych i trudnych projektów (czyli duży
kod wynikowy i duży czas wykonania). Zgodność z
C++ będzie powodowała komplikacje i nieoptymalną
semantykę (tak jak zgodność z C psuje C++).

> Niestety jak na razie ja
> takowego nie widzę, a to co widzę to w ogromnej większości bloat
> I/lub crap. Dlatego pytam. A zauważyłem dość ciekawą często (jak nie
> zawsze) relacje, że jak syf to się okazuje napisany w C++.

Nie wiem na co typ patrzysz, ja widę sporo syfu, ale w różnych
językach. Powiedziałbym że PHP i JS przodują, Python z nimi
mocno konkuruje. C++ też, ale biorąc pod uwagę że soft w
C++ jest często używany, to propocja "złych" programów może
być dużo mniejsza.

> Wiec wybacz, ale na końcową ocenę użytkownika nie wypłynie
> zajebistość C++ z pkt. widzenia programisty.
> Punkt widzenia użytkownika to nie tylko ocena końcowego produktu
> (efektu).
> Przykład sprzed paru dni.
> Mam klaster kilkunastu maszyn, które od 25 lat coś tam liczą. Do tego
> liczenia nie potrzeba aktualizacji, zmian w sofcie. Liczy się tylko
> liczenie i dostępność i od lat nie wolno tego ruszać. Ostatnio
> chciałem coś przećwiczyć w llamie i wykorzystać klaster jedynie jako
> bazę uruchomieniową bimarek bo tam jest dużo ram. Oczywiście trzeba
> skompilować, ściągam patrzę w źródła "o ja pierdole C++ będzie cyrk".
> I był, całkiem podobny jak w pythonie. Zaczynając od problemów z
> kompilacją (nietypowe wymogi) a kończąc na problemach z uruchomieniem
> (invalid instruction).
> Tak wiem, tego typu problemy to nie wina C++ ale i tak niesmak
> pozostaje.

Jeśli masz ten sam soft co 25 lat temu to nie myśl o kompilowaniu
współczesnych źródeł sciąganych z sieci. Nawet w C są nowe
konstrukcje i nikt nie będzie ich unikał. Przy tym jakieś 20
lat temu to faktycznie był z C++ problem, tzn. pod rząd pojawiało
się kilka wersji g++, każda niezgodna binarnie z poprzednią.
Na poziomie źródłowym też były zmiany i mogło się okazać że
programu w praktyce nie da się użyć bez dużego cyrku w stylu
nowych bibiotek + specjalnych scieżek dostępu by je użyć.
Ale to (chyba) mineło.

Ja mam sporo sympati do używania starego softu. Ale musisz
się liczyć z tym że rynek na wieloletnią zgodność wstecz
jest mały, jak chesz to dostać to musisz płacić naprawdę
dużo a towar będzie powiedzmy "niezupełnie świeży", tzn.
mogą być problemy które są rozwiązane w nowszym sofcie.

--
Waldek Hebisch

do góry

W dniu 9.12.2025 o 04:49, Waldek Hebisch pisze:
> Soft może być mały tylko wtedy jak rozwiązuje prosty problem.

Nie tylko. Zgodnie z koncepcją Uniksa należy kodować proste prog., które
można używać razem z innymi prostymi prog. w celu realizacji złożonych
zad. Natomiast takie potwory jak bibl. Qt i Qt Creator są zaprzeczeniem
tych zasad. Dlatego ja postuluję by społeczność zrobiła rozwidlenie (w
j. ang. fork) proj. bibl. Qt i oczyściła ją z całego zbędnego syfu
(szczególnie ze szpiegującego SI). Piszę o tym w "7. Raport
Totaliztyczny: Sprawa Qt Group", dostępnym całkowicie za darmo na mojej
s. WWW:

<https://energokod.gda.pl/raporty-totaliztyczne/7.%2
0Sprawa%20Qt%20Group.pdf>

Co do Qt Creatora nie da się go naprawić, do uruchamiania ze śledzeniem
można by używać DDD, jednak nie da się w nim ustawiać punktów
wstrzymania (w j. breakpoint) z linii komend, a jest to konieczne gdy
chcesz wysterować go z własnego edytora programisty. Ta wada DDD jest
też zaprzeczeniem koncepcji prog. Uniksowych i jest to dla mnie
niezrozumiałe, bo jego koncepcja jest b. dobra.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska??, EU??;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<j...@e...gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

do góry

On 09/12/2025 04:49, Waldek Hebisch wrote:
> nie będzie ryzykował konwersji C++ na powiedzmy C. Konwersje
> z C na C++ są dość powszechne. heby może pisać że to daje
> marny C++

heby napisze, że daje znakomity C++. C to bardzo dobry C++, bo już
napisany i przetestowany, nie trzeba nic zmieniać ani o nic się martwić.

Inymi słowy, ważna jest ewolucja a nie rewolucja. Tym bardziej, że w
99.9% wypadkach polega na zamianie .c na .cpp i reszta dnia wolnego.

do góry