On Saturday, August 12, 2017 at 11:07:20 PM UTC+2, g...@g...com wrote:
> W dniu sobota, 12 sierpnia 2017 15:59:27 UTC+2 użytkownik s...@g...com
napisał:

> I z pewnością, żeby odpowiedzieć na to pytanie, najpierw
> należałoby ustalić nasze oczekiwania względem danego języka,
> żeby można było zastosować jakieś kryteria, a nie prowadzić
> dyskusji na poziomie "język X jest zły, bo nie ma ficzera Z",
> albo "język X jest zły, bo nie jest językiem Y".
Kryterium porównawcze to dobra rzecz.



> Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście
> środków do tego, żeby mógł go używać stosownie do swoich
> upodobań -- oczywiście w niektórych kontekstach można by to
> było uznać za zaletę, jednak "w ogólności" wydaje się to raczej
> wadą.
Tutaj pozwolę sobie trochę się nie zgodzić. W C++ generalnie
jest dużo środków i można w nich przebierać. No chyba chodzi o
biblioteki, w przypadku bibliotek trzeba brać albo taką jaka
jest, albo se napisać swoją. Właśnie kolekcje do uporządkowanych
zbiorów mi nie odpowiadają ani w QT, ani w STD, więc napisałem
swoją. Ale to jest wada każdego języka. Chociaż taka Java od
razu była nastawiona na prostotę i standaryzację ogromnej
biblioteki...



> Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++
> były domyślnie zadeklarowane jako "const", i tylko te, które
> zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"),
> C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego
> zachowania.
Ale takiego efektu w żadnym języku nie można uzyskać, o ile
zrozumiałem co masz na myśli. Jeśli zostanie przewidziane
przed pisaniem kodu, to można sprytne define zrobić, jeśli nie,
to w żadnym języku tak się nie da.


> Podobnie, interfejsy dostarczane przez STL są bardzo dziwne.
> Jest sobie chociażby taki kontener "stack". Jak można się spodziewać,
> stack<T> ma funkcję push(T element), która kładzie element na stosie,
> oraz pop(), która zdejmuje element ze stosu.
Idzie z tym żyć. Ja na tę sprawę mam inny pogląd. W innych językach,
jest mniej możliwości. Naturalne dla innych języków jest to, że
biblioteka zazwyczaj jest taka jaka powinna być w danym języku. A w
C++ jest bardzo dużo środków wyrazu. Zazwyczaj z biblioteką taką jak
STL czy QT można żyć. Problem w tym, że czasami chce potrzeba
biblioteki "skrojonej na miarę" do danego programu. Przy czym
skrojona na miarę oznacza albo wygodę programowania, albo
bezpieczeństwo, albo przejrzysty kod, albo ekstremalną wydajność.
W innych językach nie tylu środków wyrazu, więc inne języki
nie dają okazji do dzielenia włosa na czworo. W Javie nigdy w
życiu nawet bym nie pomyślał o pisaniu swojego kontenera, bo
po co? W C++ zazwyczaj używam swoich drzew, tablic hashujących, itd,
ponieważ (w moim przypadku najczęściej) to skraca czas obliczeń.



> Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu.
> Uzasadnienie autorów biblioteki jest takie, że w ten sposób można
> uzyskać większą wydajność, i że STL jest projektowany w taki sposób,
> żeby "nie płacić za to, czego się nie używa" -- jednak brak
> ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy
> programiści przyzwyczają się, że zepsute interfejsy to norma.
Zazwyczaj jest bardzo wysoka cena za bardzo małe zwiększenie wydajności.
Stos ma metodę top która zwraca. Można wywołać top a potem pop. I
pewnie w konkretnym przypadku będzie efekt przeciwny do zamierzonego,
pewnie wydajność będzie gorsza dla dwóch wywołań niż dla jednego z
odpowiednim typem zwracanym. A jakby dziedziczyć po stosie i sobie
napisać taką metodę pop? W QT chyba nazywa się taka metoda take.



> Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest
> ten gość, Scott Meyers, który najpierw pisał dużo książek o C++,
> a później zaczął jeździć po konferencjach, narzekając na dziwność
> interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy
> w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno
> było ich używać niepoprawnie), i teraz zdaje się zajmuje się
> rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć
> np. tutaj
Nie, mam dosyć swojego narzekania ;-)

> Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne
> również są pewną ceną, którą programiści C++ muszą płacić.
Kompilacje można zrównoleglać w make. Komunikaty diagnostyczne...
nie wiem.. zazwyczaj wiem co kompilator do mnie mówi, czasami
tylko muszę chwilę się zastanowić.


> W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony,
> to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie
> duży stopień komplikacji tego języka (np. skomplikowana
> składnia i różne założenia utrudniające formułowanie wniosków
> dotyczących programów napisanych w C++) są na tyle poważnym problemem,
> że jeśli nie muszę, raczej staram się z niego nie korzystać.
Dla mnie to co nazywasz komplikacją, jest bogactwem możliwości.
Ale jeśli nie muszę, to też wolę np. Jave, PHP.

Pozdrawiam