zeromq / zmqpp

0mq 'highlevel' C++ bindings

Introduction

Library / Bindings

This C++ binding for 0mq/zmq is a 'high-level' library that hides most of the c-style interface core 0mq provides. It consists of a number of header and source files all residing in the zmq directory, these files are provided under the MPLv2 license (see LICENSE for details).

They can either be included directly into any 0mq using project or used as a library. A really basic Makefile is provided for this purpose and will generate both shared and static libraries.

There are a number of unit tests covering the code but in no way should the tests be considered complete.

Command-Line Client

There is also a command line client that can be used to test or even bridge zmq connections. The client is built on top of the libzmqpp bindings.

Feature Requests

If there is any missing features from the current versions of ZeroMQ that you wish to use please raise an issue against this project, or even a pull request.

Generally I've only added things as I need them but I'm always happy to improve the feature set as people require.

Contributing

Contribution to this binding is welcome and it is suggested using pull requests in github that will then be reviewed and merged or commented on. The full contribution is outlined on the zmq site (http://zeromq.org/docs:contributing)

Please feel free to add yourself to the AUTHORS file in an alphanumerically sorted way before you raise the pull request.

Documentation

Most of the code is now commented with doxygen style tags, and a basic configuration file to generate them is in the root directory.

To build the documentation with doxygen use

doxygen

And the resulting html or latex docs will be in the docs/html or docs/latex directories.

libzmqpp

There is a Makefile provided which will build, test and install the binding on a GNU Linux system. I have not tested it on anything other than Ubuntu since 11.04 and Centos 5 and 6.

The install process will only install headers and the shared object to the system. The archive will remain in the build directory.

The tests for the binding (make check) require the boost unittest framework to have been installed however these do not need to be built or run to install the library itself.

Requirements

ZeroMQ 2.2.x or later. We recommend to use ZeroMQ >= 3. C++11 compliant compiler. (g++ >= 4.7)

The command line client and the tests also require libboost.

Installation

Installation can be done by the standard make && make install. If the boost unittest framework is installed, check and installcheck can be run for sanity checking. To use ZMQ4 security feature install libsodium and libzmq --with-libsodium as shown below before ZMQPP.

# Build, check, and install libsodium
git clone git://github.com/jedisct1/libsodium.git
cd libsodium
./autogen.sh 
./configure && make check 
sudo make install 
sudo ldconfig
cd ../
# Build, check, and install the latest version of ZeroMQ
git clone git://github.com/zeromq/libzmq.git
cd libzmq
./autogen.sh 
./configure --with-libsodium && make
sudo make install
sudo ldconfig
cd ../
# Now install ZMQPP
git clone git://github.com/zeromq/zmqpp.git
cd zmqpp
make
make check
sudo make install
make installcheck

The most commonly useful overrides are setting CXX, to change the compiler used, and PREFIX to change install location. The CXX prefix should be used on all targets as the compiler version is used in the build path. PREFIX is only relevant for the install target.

Debugging

The makefile defaults to a production ready build, however a debug version can be build by passing CONFIG=debug to the make command. In debug mode there is less optimisations and a number of sanity check assert statements. If you are not using the installed library the sanity check effect is governed by the defining of NDEBUG.

zmqpp

The make file can also build and install a client tool called zmqpp. To build this tool add the step;

make client

Before the install stage. The install target will install the client to the binaries directory if it has been built.

Usage

The client is a command line tool that can be used to listen or send to 0mq sockets. Its very basic so don't expect anything clever. zmqpp --help will list details about the possible flags it can take;

Usage: zmqpp [options] SOCKETTYPE ENDPOINT
0mq command line client tool.
SOCKETTYPE is one of the supported 0mq socket types.
  pub, pull, push, rep, req, sub
ENDPOINT is any valid 0mq endpoint.

Connection Options:
  -a [ --annotate ]            annotate output with direction
  -b [ --bind ] arg            bind to specified endpoint
  -c [ --connect ] arg         connect to specified endpoint
  -d [ --detailed ]            increased level of information displayed
  -x [ --exit-when-no-input ]  don't wait for (streamed) input; exit on zero 
                               message
  -s [ --singlepart ]          treat each line as a new message
  -v [ --verbose ]             display output sent over socket to stderr

Miscellaneous Options:
  --version             display version
  --help                show this help page

Multiple uses of -c or -b are allowed to connect or bind to multiple endpoints, if neither is specified the connect is assumed for endpoint ENDPOINT.

For send capable sockets entering text on standard in and pressing return will create a message part, with an empty part (double newline) marking the end of a message. If singlepart is enabled then the message is sent after each newline on the input stream.

The default flags will allow you to pipe data from one instance of zmqpp to another and so bridge between zmq sockets.

Licensing

Both the library and the associated command line client are released under the MPLv2 license.

Please see LICENSE for full details.

zmqpp's Issues

Build Error

"make" worked well, and error happend in "make check"
Running 87 test cases...
unknown location(0): fatal error in "sending_large_messages_string": std::bad_alloc: std::bad_alloc
src/tests/test_socket.cpp(481): last checkpoint

*** 1 failure detected in test suite "zmqpp"

System: Centos 7 64bit
zeromq-3.2.2-13.1.x86_64
zeromq-devel-3.2.2-13.1.x86_64

const correctness

After much discussion it seems that it's cleaner for the zmqpp classes to support const correctness as a user would expect it and then use const casts to call the underlaying zmq library.

An example of this would be things such as the message get part functions.

incorrect work of zmqpp::frame with the underlying zmq::msg_t through raw_new_msg API

I'm using zmqpp v4.1.2 together with zmq v4.1.3
When using

zmq_msg_t& raw = zmqpp::message::raw_new_msg(size_t)

the

  zmq_msg_t._

char array actually points at the beginning of the underlying

zmq::msg_t struct

first 16 bytes of which are occupied by the internal struct data, because of the following code:

zmq.cpp line 571:

int zmq_msg_init_size (zmq_msg_t *msg_, size_t size_)
{
    return ((zmq::msg_t*) msg_)->init_size (size_);
}

When I try to read the written data, using

const unsigned char* partData = (const unsigned char*)msg.raw_data(size_t);

I receive a pointer to the actual beginning of the raw data, namely, offset of 16 bytes, relative to the char array beginning, which is correct. The method

zmqpp::message::add_raw(const char*, size_t);

also copies the provided array into the internal storage with the proper offset, so it seems only

zmqpp::message::raw_new_msg(size_t)

I think that it stopped working, when a new member pointer was added to the

from zmq/msg.hpp:

zmq::msg_t::u::vsm struct:
            struct {
                metadata_t *metadata;   <------- the new member pointer
                unsigned char data [max_vsm_size];
                unsigned char size;
                unsigned char type;
                unsigned char flags;
            } vsm;

zmq.hpp compiling error at std::vector

I have problem in this function in zmq.hpp when compiling project:

inline int poll(std::vector<zmq_pollitem_t> const& items, long timeout_ = -1)
{
return poll(items.data(), items.size(), timeout_);
std::vector a;
}

The error is:

error C2039: 'data' : is not a member of 'std::vector<_Ty>'
1> with
1> [
1> _Ty=zmq_pollitem_t
1> ]
1>f:\zeromq 4.0.4\include\zmq.hpp(153) : error C2133: 'a' : unknown size
1>f:\zeromq 4.0.4\include\zmq.hpp(153) : error C2512: 'std::vector' : no appropriate default constructor available

Please help!

compilation error in src/zmqpp/actor.cpp

src/zmqpp/actor.cpp: In constructor ‘zmqpp::actor::actor(zmqpp::actor::ActorStartRoutine)’:
src/zmqpp/actor.cpp:27: error: call of overloaded ‘to_string(ptrdiff_t)’ is ambiguous
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:2604: note: candidates are: std::string std::to_string(long long int)
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:2610: note: std::string std::to_string(long long unsigned int)
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:2616: note: std::string std::to_string(long double)

i wish the header file stddef.h could be added to the file src/zmqpp/actor.cpp to avoid this compilation error.

Problem: CURVE test cases(stonehouse, ironhouse and ironhouse2) failing

NULL & PLAIN test cases are working fine.

CURVE test cases are failing with "unknown location(0): fatal error in "stonehouse": std::runtime_error: Operation not supported".

Details:
auth: configure CURVE - client public key:CURVE_ALLOW_ANY
auth: API command=CURVE
auth: configured CURVE - allow ALL clients
auth: API command=TERMINATE
auth: Shutdown ZAP Authentication Server
unknown location(0): fatal error in "stonehouse": std::runtime_error: Operation not supported
/home/travis/build/zeromq/zmqpp/src/tests/test_auth.cpp(121): last checkpoint
auth: Starting ZAP Authentication Server
auth: verbose:true
auth: API command=DOMAIN
auth: domain=*
auth: API command=ALLOW
auth: whitelisting ipaddress=127.0.0.1
auth: API command=TERMINATE
auth: Shutdown ZAP Authentication Server
unknown location(0): fatal error in "ironhouse": std::runtime_error: Operation not supported
/home/travis/build/zeromq/zmqpp/src/tests/test_auth.cpp(121): last checkpoint
unknown location(0): fatal error in "ironhouse2": std::runtime_error: Operation not supported
/home/travis/build/zeromq/zmqpp/src/tests/test_auth.cpp(121): last checkpoint

Latest release?

This isn't really an issue, but is 3.2.0 from late 2013 the latest stable release? Changes.md suggests that there is a 4.1.1, but it doesn't seem to show up on the list of releases here: https://github.com/zeromq/zmqpp/releases.

Is the recent activity working towards an upcoming 4.1.1 release, or am I just not looking in the right place?

Branch for different zmq versions / Code Simiplification.

We have a lot of #ifdef sections in the code for different versions of the code base, however we only actually do test builds with 3.x, 4.x and 4.1 builds of zmq. Would it be worth stripping most of these from the codebase in an effort to simiplify the code for future maintenance?

We could either branch for the 3 and 4 version to match the libzmq-3.x and libzmq-4.x repos or something similar along those lines.

Add support for event monitors

These were added for the 3.2 snapshot and are currently ignored by the zmqpp system.

Default client display should distiquish multipart messages

Currently without the -n there is no way to tell multiple single part from one multipart message, this should be the default. This also allows piping of data in a shell script.

Publishing documentation to gh-pages

Hello,

The documentation (for someone not having doxygen) is "hard to access" -- you have to look through the library header. Our wiki doesn't feature example or explanation either.

What would you think about using the gh-pages branches to push doxygen-generated web documentation ?

zmqpp::socket Send/Receive : using bool dont_block or int flag

Hi,

As pointed out in #56 the parameters of the send and receive overloads in zmqpp::socket are not very consistent.

Sometimes we use an int flag and in other places we use bool dont_block for options.
The zmqpp::message and zmqpp::signal overloads use bool because the only meaningful flag would be block or don't block. send_more is not relevant here (please correct me if i'm wrong).

However, send_more is relevant in the send_raw / receive_raw method, so a int flag is needed.

The std::string overload, which is more of a syntactic sugar, uses int flag. I guess it can be used to send multiple string as 1 message with send_more, but wouldn't using a zmqpp::message be a better alternative?

Changing the std::string overload so that it takes bool dont_block would break compatibility for people using this overload as describe before, but would bring a bit more consistency to the API.

What do you think?

Remove code duplication in poller

There is a lot of duplicated code due to handling the sockets and file descriptors the same way but separately

Should be fairly easy to pull out common code into private templates to make any maintenance easier.

Switch to new message send/recv system

Since 3.2 zmq_sendmsg and recvmsg are now in the zmq_msg subgroup. Code should be updated to reflect this change for 3.2 and later

Support for socket disconnect

Missed out the disconnect functions when updating to all the 3.2 options.

WebSocket?

Hi,

I was wondering, is there any plan to add WebSocket feature?

Regards,
Rchockxm

visual studio 2015 found?

CMake Error at cmake/macros/FindZMQ.cmake:80 (message):
Could not find ZMQ libraries/headers! Please install ZMQ with libraries and
headers
Call Stack (most recent call first):
src/server/ipc/CMakeLists.txt:11 (find_package)

Clean up client code

The client is a mess of almost one function and needs work, actually turns out to be useful and not just a hack as it first was.

Licensing

Dear zmqpp contributors,

Our current license is LGL3 + static link exception as describe here.
It also recommends switching to MPLv2 when possible.

It is the intention of the ZeroMQ community to move gradually towards the Mozilla Public License v2, as a replacement for the current LGPLv3 + static link exception.

MPLv2 is pretty much the same that our current license but has the advantage of being more standard.

The goal of this issue is to collect approval of contributors. If you agree to this change, please state it in a comment.

I am pinging all contributors in the github tab and @hintjens for his use of the merge button :)
@benjamg
@meprem
@Rhubbarb
@chminx
@gyulalaszlo
@xdmiodz
@pschoeni
@rontana
@TobiasSimon
@crheckman
@pin3da
@mfsv
@jerome-pouiller
@da-x
@olenz

Client application should support pipeing

Currently it isn't easy to use the zmqpp client application to pipe data in a bash shell.

Ideally this needs to be reworked to allow data to be piped both in and out of an instance and so allow simple shell scripts to create zmq devices.

Some thought will probably need to go into this to work with multiple part messages, currently my thinking is stick with newline as a part double newline as a message (similar to http) when the multipart option is enabled, and just newline for a message otherwise.

extremely CPU usage on SUB socket without subscribe before receive

Good day.

Calling receive method on SUB socket without subscribe uses 100% CPU.

Example (100% CPU usage):

zmqpp::context cont;
zmqpp::socket sub(cont, zmqpp::socket_type::sub);
zmqpp::message msg;
sub.connect("epgm://eth0;239.192.100.1:12345");
sub.receive(msg);

Example (no 100% CPU usage):

zmqpp::context cont;
zmqpp::socket sub(cont, zmqpp::socket_type::sub);
zmqpp::message msg;
sub.connect("epgm://eth0;239.192.100.1:12345");
sub.subscribe("");
sub.receive(msg);

I dare suggest this is expected behavior, but I believe throw exception in this situation (receive without subscribe) would be good idea.

Pull in datasift macos fixes

@glaude made the following changes to support OSx MeltwaterArchive@ed2c07e

These work although really the POLL_IN / POLL_OUT constants should be replaced because POLL_IN and POLL_OUT are both fairly common macros and I have no idea what I was thinking when I used them. Surprised it works anywhere.

This will of course break backwards compatibility

VS2013 build failure

I downloaded the latest source tree and have my own vs solution and project files I use to build windows libs. When I run that build, I find that inet.hpp (and only this file) produces errors on all occurrences of uintxx_t types.

I can get a clean build by adding #include <cstdint> to inet.hpp, though I'm not sure that's your preferred fix.

Compiler can't resolve zmqpp::frame constructor when zmqpp::message::add_const() is called with Type == const void *

Compiler in my case is VS2013, update 4. To correctly resolve on my end, it's necessary to cast any const void * data I'm passing into add_const() to (void *), but it seems like the value of the template method is lost in these cases since I'm having to feed the right type info to the compiler based on my knowledge of the signature for the zmqpp::frame constructor.

A possible fix would seem to be changing the signature for the relevant frame constructor:

frame(void* part, size_t const size, zmq_free_fn *ffn, void *hint);

...to:

frame(void const* part, size_t const size, zmq_free_fn *ffn, void *hint);

...and addressing any needed const casting in the body of that constructor. This seems reasonable, since there is already another zmqp::frame constructor that takes a part argument of type void const *:

frame(void const* part, size_t const size);

...and, it seems void const * is the appropriate "promise" to make to clients of that zmqpp::frame constructor since it shouldn't be altering the input data.

receiving can only be done to empty messages?

In zmqpp, the socket_t::receive() method throws an exception if you pass it a non-empty message_t. This seems to be contradictory to the philosophy of zmq_recv(), which states that the message passed to it will be deallocated cleanly if necessary.

Now, I know zmqpp defines a "message" as all parts of a multipart message, while libzmq defines it as just one part. So this isn't a direct contradiction of the API semantics. But it seems like this could be fixed without much effort.

compiled error

src/zmqpp/socket_types.hpp:136:15: error: ‘ZMQ_STREAM’ was not declared in this scope
stream = ZMQ_STREAM,

The ZMQ version is 3.2.

constexpr not compiling on windows.

is constexpr really necessary here?

zmqpp/src/zmqpp/auth.hpp

Line 149 in 14ba51d

constexpr static const char * const zap_endpoint_ = "inproc://zeromq.zap.01";

because I'm compiling the library on Visual Studio 2013 and it's not supported yet.

Windows build problem: 'ZMQ_XPUB_VERBOSE_UNSUBSCRIBE': undeclared identifier

C2065 'ZMQ_XPUB_VERBOSE_UNSUBSCRIBE': undeclared identifier zmqpp-static c:\programming\c++\libraries\zeromq\c++ binding\zmqpp-develop\src\zmqpp\socket_options.hpp 111

X8 in the error log.

Adding same socket multiple time to reactor cause bug

It seems that adding a socket multiple times to a zmqpp::reactor cause events to not be dispatched.

Maybe it's also the case for zmqpp::poller (or the underlying libzmq poller).
Will investigate.

expecting string instruction after `rep'

typing "make" results in:

g++ -MMD -std=c++0x -pipe -Wall -fPIC -DBUILD_ENV=max -DBUILD_VERSION='"3.2.0"' -DBUILD_VERSION_MAJOR=3 -DBUILD_VERSION_MINOR=2 -DBUILD_VERSION_REVISION=0 -DBUILD_DATESTAMP='"2014-05-18 03:01"' -DBUILD_LIBRARY_NAME='"zmqpp"' -DBUILD_CLIENT_NAME='"zmqpp"' -I./src -O3 -funroll-loops -ffast-math -finline-functions -fomit-frame-pointer -DNDEBUG -c -o build/max-g++/obj/zmqpp/socket.o src/zmqpp/socket.cpp
{standard input}: Assembler messages:
{standard input}:3883: Error: expecting string instruction after `rep'
make: *** [build/max-g++/obj/zmqpp/socket.o] Error 1

Please advise.

Thank you.

Compile error: zmqpp::frame::frame(const zmqpp::frame&) is private.

Hi,
I'm trying to compile zmqpp with gcc (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)) but I get this error:

g++ -MMD -std=c++0x -pipe -Wall -fPIC -DBUILD_ENV=max -DBUILD_DATESTAMP='"2014-12-03 09:49"' -DBUILD_LIBRARY_NAME='"zmqpp"' -DBUILD_CLIENT_NAME='"zmqpp"' -I./src -I/home/fews0_app/dev/zeromq-4.1.0/include -O3 -funroll-loops -ffast-math -finline-functions -fomit-frame-pointer -DNDEBUG -c -o build/max-g++/obj/zmqpp/message.o src/zmqpp/message.cpp
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/vector:69,
from src/zmqpp/message.hpp:15,
from src/zmqpp/message.cpp:11:
src/zmqpp/frame.hpp: In member function ‘void std::vector<_Tp, _Alloc>::_M_fill_insert(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp&) [with _Tp = zmqpp::frame, _Alloc = std::allocatorzmqpp::frame]’:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_vector.h:851: instantiated from ‘void std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp&) [with _Tp = zmqpp::frame, _Alloc = std::allocatorzmqpp::frame]’
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_vector.h:557: instantiated from ‘void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = zmqpp::frame, _Alloc = std::allocatorzmqpp::frame]’
src/zmqpp/message.cpp:444: instantiated from here
src/zmqpp/frame.hpp:52: error: ‘zmqpp::frame::frame(const zmqpp::frame&)’ is private

Can you help me?

Thank you,
Mirko Cambi

Support raw data type in set options

Some options, namely ZMQ_IDENTITY, have been incorrectly treating as string types when really they are raw data. A new method is probably needed with built in conversions from the known data type methods.

Timestamps on messages

Need an option, possible default if going to a terminal and not being piped, to display timestamps next to parts received.

Auth : Allow and Deny have no effect.

Please see title ^^.

I am using an xrep and xreq sockets apart from that my code matches this example.

I've tried allowing and denying access to clients on 127.0.0.1. The clients are written in node js and use the req socket type.

context move assignment operator leaks context

context& operator=(context&& source) noexcept
{
    _context = source._context;
    source._context = nullptr;
    return *this;
}

In the above _context is overwritten without being released. How about just doing
std::swap(_context, source._context)? That way the _context will be cleaned up by the dtor of source.

Configure Script Without libsodium

On your front page you specify to do the following to compile zmqpp

./autogen.sh
./configure --with-libsodium && make

However, I don't use ZMQ4 so therefore I believe I don't need to install libsodium, however when I call ./configure without the --with-libsodium:

./configure
...
...
checking for sodium... no
configure: error: Package requirements (libsodium) were not met:

No package 'libsodium' found

Is libsodium now a mandatory requirement for zmqpp, or is this an error from the autogen?

Crash problem

Here is the error message:
terminate called after throwing an instance of 'zmqpp::exception'
what(): attempting to request a message part outside the valid range
Aborted (core dumped)

code snippet:
server:
const string endpoint = "tcp://*:5558";
zmqpp::context context;
24 // generate a pull socket
25 zmqpp::socket_type type = zmqpp::socket_type::pull;
26 zmqpp::socket socket (context, type);
27
28 cout << "Binding to " << endpoint << "..." << endl;
29 socket.bind(endpoint);
30 // receive the message
31 cout << "Receiving message..." << endl;
32 zmqpp::message message;
33 // decompose the message
34 while (1)
35 {
36 ┊ string jsonstr;
38
39 ┊ socket.receive(message);
40 ┊ message >> jsonstr;
41
42 ┊ cout << "jsonstr: " << jsonstr << endl;
}

client:
14 zmqpp::socket_type type = zmqpp::socket_type::push;
15 zmqpp::socket socket (context, type);
16
17 // open the connection
18 cout << "Opening connection to " << endpoint << "..." << endl;
19 socket.connect(endpoint);
20
21 // send a message
22 cout << "Sending text and a number..." << endl;
23 zmqpp::message message;
24 // compose a message from a string and a number
25 //message << "Hello World!" << 42;
26 message << "Hello World!";
27 socket.send(message);
28

The crash happened at the second execution of the client (work well in the first execution of the client)

Mimic czmq zthread_fork

Hello,

I would like to add the cool syntactic sugar that is zthread_fork() to zmqpp.
It's my understanding that in CZMQ, the context is responsible for freeing the memory allocated for the 2 pair sockets.

If I submit a PR to add this, do you think the context should somehow manages the memory for the pair sockets, or does it make sense to give this responsibility to the caller (meaning both end of the pipe should be manually deleted).

Requiring the caller to manages memory means more work for the caller for little to no benefits. The benefit (that i see) would be to free the pair socket as soon as you don't need it anymore, instead of having to wait for the context to die. I'm not sure there is many use where this make sense.

Any thoughts about this?

Thanks

Handling of file descriptor in win64 broken.

In the api a file descriptor (e.g. in poller::add()) is a simple int. But under Windows such a descriptor is actually of type SOCKET. This type is a typedef to UINT_PTR (see WinSock2.h). And here is the problem: Under 32bit UINT_PTR is an unsigned int, but under x64 it is an unsigned __int64. This means that the value of a file descriptor under x64 cannot not fit into an int. The compiler only warns about this but happily cuts off half of the value by casting the uint64 into int. In case of the poller this could have some unexpected side effects. Two distinct descriptors could be seen as the same because they only differ in the upper 32 bit. Worse than that is that the poller could do the wrong thing altogether because the 'broken' descriptor value is passed to zmq_poll().

A solution to this would be to not use int as the file descriptor but a type that is declared depending on the platform like this:

#ifdef _WIN32
    typedef SOCKET descriptor_t;
#else
    typedef int descriptor_t;
#endif

void poller::add(descriptor_t const descriptor, short const event /* = POLL_IN */);

Of course this would break the public interface. But seeing that it only breaks for windows and it is already broken there, I see no other choice.

Bring into ZeroMQ organization?

@benjamg would you like to bring this into the github.com/zeromq organization? I'll make you co-admin of that, so you can move/rename it. You'd get more contributors and users like that. There's also some discussion of moving cppzmq back into the core library, and making zmqpp the "official" C++ binding.

Switch to new ctx init/destroy methods

As of 3.2 all context operations have new initialiser methods, this should probably be done before issue #4

No support for ZMQ_IMMEDIATE

The enum class socket_option misses support ZMQ_IMMEDIATE, accordingly it's impossible to set this option for a socket via the bindings.

requirement of C++0x compliant compiler is not quite accurate?

Using gcc 4.4.7 (yes, I know it's old) and -std=c++0x is not sufficient to build zmqpp. The README.md states minimum requirements as ZeroMQ 2.2.x or later and C++0x compliant compiler.

I see the following error:

In file included from src/zmqpp/socket.cpp:22:
src/zmqpp/message.hpp: In constructor ‘zmqpp::message::message(const T&, Args&& ...) [with T = zmqpp::signal, Args = ]’:
src/zmqpp/socket.cpp:132:   instantiated from here
src/zmqpp/message.hpp:63: error: type ‘zmqpp::message’ is not a direct base of ‘zmqpp::message’
make: *** [build/max-g++44/obj/zmqpp/socket.o] Error 1

Explained here:
http://stackoverflow.com/questions/11391108/c-class-is-not-base-of-itself
One of the answers points out:
According to C++0x/C++11 Support in GCC , delegating constructors were implemented in GCC v4.7.

I'm guessing you're going to update the documentation to require a C++11 compiler rather than test for supported C++11 features?

Proxy equivalent?

Is there a proxy equivalent in zmqpp as used in the mtserver example? I can't seem to find any in the source code.

zmqpp has a maximum read buffer capacity of 512 bytes

If input lines longer than 512 bytes are sent to stdin they will be cut off and treated as multiple lines. This is particularly problematic when sending large serialised objects.

Recommendations: Fail when the buffer is too small to read the next line and/or making the buffer automatically resize.

https://github.com/benjamg/zmqpp/blob/develop/src/client/main.cpp#L283

Graceful Handling of: Context closed

Hi Ben,

I'm currently playing around with the implications of manually destroying the zmqpp::context by calling zmq_ctx_destroy on it. Obviously this is not "normal" behavior, but rather a rare edge case. When you adopted zmq 3.2 you introduced zmqpp:: invalid_instance, which one might use for exactly this case: as there is no way to change the context of a poller / socket these should probably close themselves and throw that particular exception.

I would love to have your opinion on this, before preparing a pull request.

Cheers,
Maximilian

poller remove socket_t from _items, but the index not in _index not change.

function:
void poller::remove(socket_t const& socket)

std::swap(_items[found->second], _items.back()); //index _items[found->second] not changed.
_items.pop_back();
_index.erase(found);

Probably error in test sanity - zmq_basic_push_pull

Hello.

Found that in file test_sanity.cpp, instead of
zmq_pollitem_t items[] = { { puller, ZMQ_POLLIN, 0, 0 } };
BOOST_CHECK_EQUAL(0, zmq_poll(items, 1, max_poll_timeout));
sould be:
zmq_pollitem_t items[] = { { puller, 0, ZMQ_POLLIN, 0 } };
BOOST_CHECK(zmq_poll(items, 1, max_poll_timeout) >= 0);

Thank you,
Alexander

Add overload for socket::set(socket_option const&, const char *)

When setting a socket option like:

mysocket.set(socket_option::subscribe, "myprefix");

the C++ standard requires that the bool override for set be considered before the std::string override. This causes the above code to fail by throwing an exception that complains that a bool option is being set with a non-bool value.

An explicit override for const char * will capture the literal properly.

Travis CI

Hello,

We have a working .travis.yml that check regression against both ZMQ3.2 and ZMQ4.
It would be very nice if Travis integration would be enabled for the repository.