Najgorszy język programowania

Dec 07, 2025 Last reply: 7 months ago 46 Replies

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

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.

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?

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

Coś w ten deseń.

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

W dniu 9.12.2025 o 04:49, Waldek Hebisch pisze:

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:

formatting link

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.

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.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required