[zeromq-dev] Questions about Coding Style

[john skaller]

On 13/02/2012, at 9:24 AM, Gary Wright wrote:
> 
> Perhaps the solution is to have two interfaces to the library.

Heh! I just wrote that too.

> A
> 'paranoid' interface that reports errors as much as possible and a
> 'go wild' interface that simply assumes that everything has been
> checked.  The 'paranoid' interface can simply wrap the 'go wild'
> interface and clients can pick and choose the interface that meets
> their needs?

It isn't just a matter of checking. The interface a C application
programmer needs is different to what a binding needs.

For example, if zmq_msg is useful at all in C++ (which I have doubts about),
it needs to have

	default_init      // cannot fail, returns void
	reset                 // close then init
	init_data/size  // reset then do the init_data/size

It isn't safe to close a non-init'd object, but this just can't happen in C++
if the constructors call default_init, unless the user does something weird
with casts or whatever (which will break anything you want).

And we don't want to call msg_move or copy: C++ has assignment,
copy constructors, and in C++xx a move operation.

The only way to make this work cleanly in C++ with the current 
C interface and semantics is to add a state flag to the wrapper object.

The thing is .. the C API is already a wrapper around C++ :)

In some languages (like Felix) the destructor could be executed
off-line by a garbage collector, so the close has to either work
or kill the process. It's the same in C++ except there you have
exceptions, and it's possible the destructor is being executed
due to one being thrown. Again, you want to release any resources
but you cannot permit failure (or you get a double fault).

> I think this is an interesting discussion, but it is also an abstract
> one about API design principles. I don't pretend to have an informed
> opinion on how this might best be applied to the ZMQ code base.

It's not that hard. The existing C API is intended for standardisation
and use by C application programmers. It has to be left alone
pretty much.

That doesn't prevent a second API being created for language
binders. Actually, there already is one (the core C++ code).
After all that's how the C binding works.

--
john skaller
skaller at users.sourceforge.net