Lista zyczen: Braki w bibliotece standardowej C++

Tak sobie pomyslalem piszac poprzedniego posta, ze wlasciwie czemu by nie spisac brakujacych rzeczy w bibliotece standardowej C++.
Oczywiscie wszystko co ponizej napisalem mozna znalezc w roznych bibliotekach, czesto jednak ze soba niekompatybilnych i pisanych w "roznym stylu", wiec to sie nie liczy.

1. Klasy do wygodnej obslugi plików/katalogów.
2. API dla wielowatkowosci i synchronizacji watkow.
3. Mechanizm "Reflection" tak jak w PHP i w Javie.
4. Wbudowane mechanizmy serializacji obiektow (patrz p. 3.)
5. Wsparcie dla automatycznego zarzadzania pamiecia (moze skrocic prawie o polowe czas produkcji oprogramowania)
6. Klasy do obslugi grafiki (ile razy ktos pyta na forum jak stworzyc glupia bitmape)
7. Klasy/funkcje do obslugi polaczen sieciowych, w tym protokolow wyzszych warstw jak HTTP, FTP.
8. Mechanizmy logowania zdarzen (cos ala log4j)
9. Obsluga Unicode.
10. Obsluga wyrazen regularnych.
11. Parsery/generatory XML.
12. Mechanizm wywolan zdalnych (CORBA/RMI)
13. Okienka
14. Serwlety i biblioteki do budowy aplikacji WWW (w ogole nie ma zadnych dobrych, ale wlasnie pisze, wiec beda)

Na razie tyle przyszlo mi do glowy. Nie znam zadnej biblioteki, ktora realizowalaby chociaz polowe z tych punktow na raz, a wiekszosc to przeciez bardzo typowe zadania nawet w malych programach. Ktos slusznie zauwazyl, ze na forum nie ma prawie w ogole pytan o Jave - Java ma to wszystko i jeszcze 10 razy wiecej i na dodatek tak poukladane, ze latwo sie z tego korzysta. Dlatego wszyscy migruja na Jave i prawie w ogole nie pisze sie juz powaznych systemow w C++... :( Smutne, ale prawdziwe.

wedlug mnie masz racje tylko w kilku punktach... nigdy nie bedzie tak ze nie bedzie wielkich roznic miedzy platformami i samym api, a w koncu biblioteka standardowa C i C++ ma byc jak najbardziej przenosna i dostatecznie szybka...

1. Prawda w stdc++ zrobili to do d**y
2. niemozliwe do zrealizowania na wieksza skale
3. nie znam sie
4. patrz wyzej
5. prawda
6. niedo zrobienia ze wzgledu na roznice miedzy sposobami wyswietlania samej grafiki, jedynie obsluge samego formatu mozna zrobic w 100% przenosna
7. hmm tu bym polemizowal, bo przecieŻ kazdy szanujacy sie system ma api sieciowe oparte na tym z BSD tak wiec roznice sa niewielkie (np: unix kontra windows - roznice jedynie w mozliwosciach)
8. wedlug mnie zbedne, kazdy moze to latwo zrobic samemu zaleznie od potrzeb
9. nooo przydalobysie
10. jak najbardziej (<ort>na razie</ort> jest tylko formatowanie printf/scanf)
11. bo ja wiem czy takie potrzebne, nie kazdy musi byc skazany na xml
12. nie wiem czy dalobysie to zrobic przenosne
13. calkowicie niemozliwe - to tak jakby kazac unixowcom od XFree86 pisac w stylu WinAPI
14. wedlug mnie nie potrzebne do biblioteki standardowej...

No dobrze, ale w Javie jakos zrobili to przenosnie, nawet okienka i wywolania zdalne. Zreszta biblioteka standardowa tez nie jest i nie musi byc w 100% przenosna (nie tak jak czyste C++ bez STLa). Mozna by ewentulanie podzielic to na jakies warstwy przenosnosci np. wyr. regularne w 100% przenosne, a okienka tylko na najpopularniejszych platformach.

Poza tym nie mozna kazac ludziom pisac wszystkiego za kazdym razem od nowa (napisanie sprawnego systemu logowania to co najmniej 3 dni pracy dobrego programisty, czyli koszt ok. 1000 zl). I ja sie nie dziwie, ze wszyscy migruja na Jave... Sprobuj przepisac jakikolwiek wiekszy kawalek kodu z Javy na C++. A wydajnosc prawie nie ma znaczenia, wiec jest to marna zaleta C++, zwlaszcza, ze programy pisane w C sa obecnie co najwyzej 1,5 - 2 razy szybsze niz Java (mikro-benchmarki pokazuja nawet, ze Java jest tak samo szybka). Wiec po co komu C++?

po co ? bo jest fajny , ja go tam lubie ( oki na razie nie znam jeszcze javy :)
A poza tym wirtulane maszyny musza byc w czyms napisane, a chyba nikt nie cche ich piosac w assemblerze.

Nie pisalem tego serio, ze do niczego nie jest potrzebny. Sam go uzywam i generalnie jest fajny. Ale czasem doprowadza mnie do szalu. Np. po co ciagnie za soba ten niskopoziomowy, podatny na bledy system wspomagania tworzenia programow wielomodulowych oparty o wlaczanie naglowkow? Nie mozna bylo zrobic eleganckiego systemu pakietow jak w Javie, albo "uses" jak w Pascalu? No niby dorzucili przestrzenie nazw (imho bardzo dobry mechanizm), tylko ze to powoduje taki brzydki dualizm:

#include <nazwa_bibl/pakiet1/pakiet2/naglowek1.h>
#include <nazwa_bibl/pakiet1/pakiet2/naglowek2.h>
using namespace nazwa_bibl::pakiet1::pakiet2;

Nie lepiej tak?:

import nazwa_bibl.pakiet1.pakiet2.*;

Oczywiscie projektanci bibliotek przez to olewaja rowno istnienie namespace'ow i zwykle wszystkie naglowki laduja w jednym katalogu, a na dodatek wszystkie deklaracje trafiaja do globalnej przestrzeni nazw. Okropnosc.

P.S. Wiadomosc z ostatniej chwili: Java znowu wywalila mi OutOfMemoryException. I to na komputerze, ktory ma 1GB ramu. :((( Dlaczego wszystko musi byc takie do d****?