Biblioteki łatające dziury standardu C++

nie zawsze można w czasie kompilacji określić co będzie wypisywane

Nawet jeśli, to i tak algorytmy będą w większości przypadków podobne (niezależnie od kodowania), a wtedy całość sprowadzi się do korzystania z funkcji działających na ciągach bajtów i nie będziesz się zagłębiał w to, jakie dokładnie bajty tam się znajdą.

Ciekawie by było, gdyby z std::cout  zrobili template variable.

Może lepiej powiedz, co chcesz uzyskać. Chociaż w sumie to mieliśmy nie wchodzić w kodowanie znaków, więc może lepiej to na razie zostawić.

W ogóle mam wrażenie, że C++ tak bardzo chce być "do wszystkiego", że przez to zostaje w tyle.

Z jednej strony masz rację, ale właśnie dzięki temu możesz do takiego  wysyłać cokolwiek, więc jeśli podasz tam właściwe bajty (bez względu na to, jak to zrobisz, to samo dotyczy ), to uzyskasz oczekiwany efekt końcowy. Dobra, starczy o kodowaniach, trzeba szukać materiałów do reszty pytań...

Raczej chodziło o to, aby mając jeden, poskładany i zoptymalizowany plik binarny w wersji Release, użytkownik mógł dostarczyć własną implementację jakiejś biblioteki (jeśli jakaś licencja tego wymaga) i otrzymać jeden plik binarny, analogiczny do tego, gdyby sam skompilował wszystko statycznie od zera. Ale jak już wspomniałem, to jest dość wydumane i raczej nieopłacalne (chyba że znasz jakiś prosty sposób, aby to zrobić).

Właśnie do tego można użyć linkera. Podając plik obiektowy twojego programu (tak, w liczbie pojedynczej, bo używając tajnego narzędzia zwanego linkerem można połączyć milion plików obiektowych w jeden) i biblioteki, dostajesz program, n'est-ce pas?

Ten kod z dolarami trochę mi przypomina PHP. Jeśli o to chodzi, to nie powinno być problemu z zagnieżdżaniem PHP w kodzie C++ i napisaniem plików makefile tak, aby całość zadziałała, ale mieszanie różnych języków w długoterminowej perspektywie może się okazać nieco męczące (zwłaszcza, że C++ ma na tyle rozwinięte metaprogramowanie, że różne ciekawe rzeczy można załatwić od razu w czasie kompilacji).

No właśnie jest to możliwe... tylko jakim nakładem pracy.

To zależy. Jedna z reguł mówi, że jeśli coś się powtarza, to można to uprościć. Możliwe, że dałoby się użyć jakiegoś prostego metajęzyka (krok po kroku pewnie dojdziemy w ten sposób aż do UML i OCL), a następnie w którymś momencie zrzucić całą robotę na różnego rodzaju narzędzia. Podobno Visual Paradigm potrafi generować kod w C++, Javie, C# i innych językach na podstawie takich diagramów. Trochę to dopieścić i może nawet refleksję dałoby się w ten sposób załatwić (zapisując jakieś reguły na przykład w OCLu lub w jakiejś innej składni, nieco bliższej C++).

Może to troche abstrakcyjne, ale jakie fajne! I wyobraźcie sobie jak takie ficzery ułatwiłyby np. logowanie błędów.

Każdy kij ma dwa końce. Pamiętaj, że dorzucenie kolejnego ficzera oznacza, że liczba przypadków użycia rośnie kwadratowo (każdy z każdym, chyba że jawnie zabronisz określonych połączeń lub czegoś nie będzie się dało zrobić z logicznego punktu widzenia), więc to oznacza więcej problemów i więcej zastanawiania się, czy istniejące rzeczy z tym nie kolidują.

Właśnie do tego można użyć linkera. Podając plik obiektowy twojego programu (tak, w liczbie pojedynczej, bo używając tajnego narzędzia zwanego linkerem można połączyć milion plików obiektowych w jeden) i biblioteki, dostajesz program, n'est-ce pas?

Tak, chyba faktycznie się tutaj nieco zagalopowałem, jak niektórzy z kodowaniami i rozwiązanie jest prostsze niż się wydawało.

Moja intuicja mi podpowiada, że problemem obecnego C++ nie jest dostępna składnia tylko dostępne biblioteki. Przykładowo chciałbym napisać program, który odczytuje z webserwisu json-a i parsuje go do obiektu. W C# to jest 10 minut roboty. W C++ jest to szukanie i kompilacja bibliotek, wybieranie racjonalnej licencji (nie GPL i nie LGPL), potem przebijanie się przez API zazwyczaj w C, zrobienie użytecznego wrappera w C++ i dopiero zabranie się za właściwe implementowanie problemu.

Jak do tej pory słyszałem dwa względnie racjonalne argumenty za C#:
- szybciej napiszesz w nim aplikację niż w C++ (bo są po prostu biblioteki na licencjach, które nie blokują tworzenia komercyjnych aplikacji z zamkniętym kodem i są napisane obiektowo, bo sam język to wymusza).
- łatwiej nauczyć się C# niż C++, więc łatwiej też pozyskać deweloperów do projektu

W C++ niemalże każdy projekt zaczynasz z procą w ręku, którą szybko budujesz sobie podczas zbierania wymagań do nowego projektu.

Chciałbym np. w C++ postawić webserwis -> i tu znowu pojawia się problem licencji. Albo masz jakiegoś GPL-a, albo masz jakiś ciekawy projekt, ale np. nie jest cross platformowy albo ma on jakieś ograniczenia typu brak wsparcia SSL albo jest to napisane w C i trzeba poświęcić n-dziesiąt godzin na ucywilizowanie jej poprzez zrobienie wrappera, albo... wykładasz dolary na stół i płacisz stosunkowo wysoką cenę za licencję, która narzuca na Ciebie różne dziwne ograniczenia. W C# znowu masz to z pudełka i to za darmo...

Kodowanie było już wałkowane, więc tylko powiem tyle: w C++ łopata w dłoń, w C# pudełko już jest.

Przykłady można jeszcze długo wyliczać i nie będą to małe zadania.

namespace foo::bar::baz {     void hey()     {         $f = $this_function();         for($ns : $namespace_iterator( f ))         {             std::cout << $ns.name() << "::";         }         std::cout << $f.name() << std::endl;     } } // Wynik: // "foo::bar::baz::hey"

Zaraz zaraz, chcesz wypisać nazwy wszystkich funkcji w jakiejś przestrzeni nazw? Hmm, przecież istnieje makro  pozwalające na uzyskanie obecnie używanej nazwy funkcji, a co do reszty, to spodziewam się, że jakaś magia preprocesora i nieco boosta lub innych narzędzi pozwoli na otrzymanie czegoś takiego. Można również przepuścić kod źródłowy przez jakieś narzędzia typu doxygen, kawałki pluginów Code::Blocksa lub inne analizatory kodu, powyciągać nazwy wszystkich funkcji z danej przestrzeni nazw i zapisać je tak, aby dało się to jakoś załadować do pliku wykonywalnego w czasie kompilacji.

Moja intuicja mi podpowiada, że problemem obecnego C++ nie jest dostępna składnia tylko dostępne biblioteki.

Problemy C++ i alternatywne języki to chyba już lekkie wychodzenie poza ramy tego tematu (tak, wiem, sam też się zagalopowałem). Myślę, że aby to dalej tutaj ciągnąć, to należałoby zgodnie z tytułem szukać kolejnych bibliotek i podawać ich wady i zalety. Nie wiem, czy robienie tutaj takiego ogólnie rozumianego składu bibliotek ma sens, ale chyba jest to zgodne z tematem.