boost::serialization i dziwne błędy kompilacji

Błędy kompilacji kodu używającego biblioteki boost::serialization są trudne do zrozumienia.

Jednym z nich jest błąd:

/usr/include/boost/archive/detail/iserializer.hpp:570: error: no matching function for call to ‘load_wrapper(boost::archive::text_iarchive&, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::serialization::is_wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >)’

Przyczyna jest prozaiczna: serializowalne pola nie mogą być const.
Jest to oczywiste, gdy wiemy że serializacja musi utworzyć "pusty" obiekt i potem wypełnić wartościami jego pola.

Dlatego też serializowalna klasa musi mieć:

• konstruktor bezparametrowy
  
• pola modyfikowalne (bez const)
  

Oczywiście z komunikatu o błędzie nie możemy tego wywnioskować... takie to już są uroki bibliotek wykorzystujących template-y...

Deklaracje zapowiadające w celu przyspieszenia kompilacji projektu

W projektach pisanych w C++ lubię korzystać z biblioteki boost.
Niestety ma ona jedną uciążliwą wadę: kod wykorzystujący boosta strasznie wolno się kompiluje. Przyczyną tego jest fakt, iż boost w dużym stopniu wykorzystuje template-y i to w bardzo zaawansowany sposób. Metaprogramy to dla kompilatora c++ nie lada wyzwanie!

W projektach składających się z kilkudziesięciu plikow źródłowych czas kompilacji całości przekracza kilka minut! Nawet przy kompilacji przyrostowej z użyciem make, po zmianie jednego z headerów w projekcie kompilacja może trwać powyżej minuty!

Jedną z technik przyspieszających kompilację jest unikanie dodawania #include do własnych headerów. Jeżeli tylko można należy wstępnie zadeklarować klasę w headerze, a właściwy #include dodać dopiero do pliku cpp.

Poniżej przykład:
Piszemy klasę Database, w której chcemy skorzystać z klasy XmlDocument. Ściślej: obiekty klasy XmlDocument będą przekazywane jako parametr w metodach klasy Database.

Jak zatem powinniśmy napisać header klasy Database.hpp:

class XmlDocument;

class Database
{
    void init( XmlDocument &document );
}

A co jeśli do obiektu XmlDocument chcemy mieć dostęp nie przez referencję, ale przez smart pointer (boost::shared_ptr)?

Żeby zdefiniować smart pointer wcale nie jest potrzebny header klasy. Także tutaj wystarczy jej deklaracja zapowiadająca:

class XmlDocument;
typedef boost::shared_ptr<XmlDocument> XmlDocumentPtr;

class Database
{
    void init( XmlDocumentPtr document );
}

Dodatkowa wskazówka: aby uniknąć duplikowania kodu, dla klas z których chcę korzystać poprzez smart pointer, tworzę osobny - dodatowy header KlasaXXXPtr.hpp

Dla przykładu header taki dla klasy XmlDocument będzie wyglądał tak:

#ifndef XMLDOCUMENTPTR_HPP_
#define XMLDOCUMENTPTR_HPP_

#ifndef XMLDOCUMENT_H_
class XmlDocument;
#endif // XMLDOCUMENT_H_

#include <boost/shared_ptr.hpp>
typedef boost::shared_ptr<XmlDocument> XmlDocumentPtr;

#endif /* XMLDOCUMENTPTR_HPP_ */

Wszędzie, gdzie chcę zadeklarować smart pointera na XmlDocument po prostu wpisuję #include "XmlDocumentPtr.hpp", natomiast w pliku cpp (np. Database.cpp) muszę jeszcze dodać #include "XmlDocument.hpp".

Serwer ssl wykorzystujący boost::asio zawsze korzysta z jednego wątka

Napisałem serwer wykorzystujący boost::asio::ssl, który zawierał pulę 10 wątków obsługujących żądania klientów.
Szybko jednak okazało się, że żądania od klientów zawsze są obsługiwane w jednym wątku roboczym:
jeśli wątek ten wykonywał długą operację, to request od innego klienta czekał aż operacja w pierwszym wątku zakończy się.

Dokładną przyczynę tego błędu opisałem na grupie boost-users w poście:
"[asio] SSL enabled http server3 example is blocking"

Rozwiązanie problemu jest dość proste:
nie wykonywać długich operacji bezpośrednio w handlerze wywoływanym przez async_read(), async_write(). Zamiast tego handler powinien wysłać tę operację do io_serwis, aby wykonała się asynchoriniczie.

Przykład handlera wywyoływanego po asynchronicznym odczycie danych (requestu od klienta):

void Request::readHeaderHandler( const boost::system::error_code
&error, std::size_t bytesTransferred )
{
m_ioService.post( boost::bind
( &Request::executeCommandHandler::executeCommandHandler,
shared_from_this() ) );

}

void Request::executeCommandHandler()
{
// long running operation
char c;

}

Jak serwer ssl z obiektu boost::asio::stream może uzyskać adres IP klienta?

// definicja stream-u ssl opartego na sockecie tcp
typedef boost::asio::ssl::stream ssl_socket;

// kod inicjujący nasłuch serwera na sockecie zakończony wywołaniem: async_accept() / accept()

// jak już klient się połączył, to mamy obiekt ssl_socket:
ssl_socket m_socket;

// z, którego można pobrać IP klienta:
const boost::asio::ip::tcp::endpoint &endpoint = m_socket.lowest_layer().remote_endpoint();
const boost::asio::ip::address &addr = endpoint.address();

std::cout << "client: " << addr.to_string() << std::endl;