Creating static library that uses Boost ASIO and does not expose it

Question

I'm trying to create a library that uses Boost ASIO (UDP multicast, asynchronous) and does not expose it. Basically I am following the async udp example, except I have made the io_service object a static private member of the library.

The code works fine if directly compiled into an executable. If I try and make a static library and then use it inside an application, the code throws exceptions while constructing my class.

If anyone has examples or has created a library that uses Boost ASIO and does not expose it and could comment I'd greatly appreciate the help.

I've also tried making io_service a private member of the class and also tried passing it to the constructor. Everything I've tried so far has thrown exceptions.

Here is the example code for the library:

#ifdef _LIB
static boost::asio::io_service asio_service;
#endif

class udpframereader
{
public:
    udpframereader() : m_socket(asio_service)
    {
        m_packetCount = 0;
        ...
    }

    unsigned long long asio_error_count();
    ...

#ifdef _LIB
private:  
    void handle_receive(const boost::system::error_code& error, std::size_t bytes_transferred);

    boost::asio::ip::udp::socket   m_socket;
    boost::asio::ip::udp::endpoint m_remote_endpoint;
    boost::array<char, 4096>       m_buffer;
    boost::crc_ccitt_type          m_crc;

    unsigned long long m_packetCount;
    ...
#endif
};

@bdonlan The ifdef _LIB allows me to use the same .h file inside the library and the application that uses the library. _LIB is not defined when used by the application. Also, the constructor is really in a separate cpp file, but I've copy pasted it in just to show how it looks. — Mark
You can't do conditional compilation via _LIB like you have. In C++, the class definition of udpframereader in the library must be identical to the one that the library's user sees. Among other reasons, C++ must allocate the same-sized data structure for each object of udpframereader. — chrisaycock
There is a nasty hack called the Pimpl idiom. Basically, your client-facing class has a pointer to different structure that the user doesn't need. This hides the implementation details, but it adds runtime overhead and the library code can become difficult to read. — chrisaycock

bdonlan bdonlan · Accepted Answer · 2011-09-19T20:13:01

You cannot change the class's definition between the library and the application like you show; this would result in (among other things) the application and library disagreeing about the size of the object, causing buffer overflows when you try to initialize these objects.

If you want to hide the private implementation of the object, use the pImpl idiom, and do not expose the implementation class to the application at all.

Creating static library that uses Boost ASIO and does not expose it

1 Answers