[zeromq-dev] Porting libzmq to C++11
Jens Auer
jens.auer at betaversion.net
Mon May 22 20:52:35 CEST 2017
Hi,
I’ve read the post a couple of years ago. You probably find some comments from me in the comments section. I still think that the conclusion is questionable for a couple of reasons. The first post is about C++ exceptions, but it is more a criticism of some common bad usage of exceptions. Conditions which you expect and have to handle are not exceptional, and thus should not be handled by exceptions. Exceptions are for errors which you cannot handle locally and have to let the caller (or somewhere up the call hierarchy) handle. Together with RAII, this creates a very clean programing style.
The main point in the second post is that C++ forces you to write inefficient code and then he compares an linked list written in C to std::list. IMHO, this is comparing apples and oranges. First, the C list is an intrusive list and std::list is not. This is not a language decision, but a design choice for the list implementation. In the example, he shows a Person struct which has next and prev pointers to form a list. From software engineering point of view, and the language is irrelevant, this combines two independent concerns which should be expressed independently, e.g. in a list implementation and a Person struct. Sometimes, performance dictates using intrusive lists, but even this can be done in C++ in a better way using mix-ins. At least, we can write a list implementation which can be used with anything providing a prev- and next field in a type-safe and efficient way.
There is also a hidden argument for C++11 in the post. The example was changed to make Person non-assignable to prevent using a STL list in an easy way. In C++11 we can use movable objects and still have an efficient std::list implementation where the stored nodes are equivalent to the C struct Person, but we keep the concerns separated. I would say this a clear win for C++11.
That being said, I think Martin knows way more about network programming (and messaging, distributed systems …) than I will ever learn. I just think that modern C++ is not his biggest strength.
Cheers,
Jens
Von: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] Im Auftrag von lists at chuckremes.com
Gesendet: Freitag, 19. Mai 2017 15:29
An: ZeroMQ development list
Betreff: Re: [zeromq-dev] Porting libzmq to C++11
Looks like no one has read the blog posts I sent earlier in this thread. The original author of libzmq explains his rationale for avoiding C++ very well in these two posts. Please read them.
http://250bpm.com/blog:4
http://250bpm.com/blog:8
Additionally, if you want to consider how to REWRITE libzmq, then look at how the original author of libzmq approached it.
http://nanonmsg.org
He rewrote it in C and named it something else. It isn’t compatible with libzmq’s wire protocol but it should give some ideas on how to adjust the architecture. Look at the code for it.
On May 19, 2017, at 8:21 AM, BJovke . <bjovan at gmail.com> wrote:
I have a feeling that C++14 and C++17 are just improvements of C++11.
C++11 is the game changer, 14 and 17 don't bring ground breaking stuff.
I would be also happy to contribute to C++11 libzmq but I'm not sure how much stuff I can do.
I'm currently not familiar with inner workings of libzmq enough detailed to be confident to rewrite it, although I'm reading the docs and code day by day.
My time to spend is questionable, sometimes I have a lot of time and sometimes I cannot contribute for days or even weeks.
There are also many aspects of libzmq which make it hard to adopt the code, instead requiring complete rewrite:
2017-05-18 20:29 GMT+02:00 Jens Auer <jens.auer at betaversion.net>:
Hi,
I would be happy to contribute to such a project, even if many users will stay with the "old" code. For me, it is a great way to learn something. I would also be happy to aim for C++14 or even C++17 once it is officially released. I think structured bindings and the new if (init; condition) will be very helpful. C++17 also has std::optional.
Cheers,
Jens
-----Ursprüngliche Nachricht-----
Von: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] Im Auftrag von Aram Santogidis
Gesendet: Donnerstag, 18. Mai 2017 10:57
An: ZeroMQ development list
Betreff: Re: [zeromq-dev] Porting libzmq to C++11
Hi,
a good reason to modernize the codebase, or even better to create a new project ala libzmq11, is to help its evolution with new networking technologies and software engineering practices.
As an example, consider the difficulties many faced (including myself) in extending ZeroMQ to support RDMA-based networking interfaces. The current design and implementation is hostile to such extensions.
Honestly, C++98 or not, I think it still can be done but with major cost in development effort and additional complexity to an already complex codebase.
Moving to C++11 and beyond is not merely an argument of fashion, as some of you implied, but it is vital for its future.
C++ and related technologies evolve and libzmq stays behind. New
developers are reluctant to contribute once they have a look at the current design and implementation (old school C++ roughly speaking).
Think for example when networking will be included in the standard, how much ugly code that juggles platform differences could be eliminated from the current implementation. Same applies for threading, which is in the standard since C++11.
I don't underestimate the importance (and the size?) of the current userbase. I'm aware from first-hand experience about some fairly critical software that relies on libzmq.
I guess the idea is to create i) a new project in the ZeroMQ organization that ii) implements ZMTP and iii) the non-depricated ZMQ socket types. The public API of libzmq should be a subset of the
libzmq11 so that will facilitate the transition of users, in the long term, that do not run on legacy systems.
I will happily contribute to such an effort provided that there will be at least one or two experienced members from the community that will join this effort.
Cheers,
Aram
On 17.05.2017 16:54, BJovke . wrote:
> Well, you're right. There must be a good reason for such an undertaking.
> I too feel that C++11 itself is not good enough reason.
> Anyway there has to be enough people willing to contribute to it.
>
> I was just saying this because no idea should be discarded right away,
> but for sure there needs to be a valid need and reason for it.
>
> Greetings.
>
> 2017-05-17 16:15 GMT+02:00 Doron Somech <somdoron at gmail.com
> <mailto:somdoron at gmail.com>>:
>
> What will be the benefit from moving to C++11? And more important
> what is the benefit from having two projects? one supporting C++11
> and one not?
>
> I think that maintaining two repositories is hard and not sure for
> what cause?
>
> Anyway, if some one want to do it, in the zeromq philosophy, please
> fork and add the project to the zeromq organization.
>
> On Wed, May 17, 2017 at 4:29 PM, <lists at chuckremes.com
> <mailto:lists at chuckremes.com>> wrote:
>
>
> > On May 17, 2017, at 7:56 AM, BJovke . <bjovan at gmail.com <mailto:bjovan at gmail.com>> wrote:
> >
> > Hello.
> >
> > Libzmq is not even fully C++ compliant:
> > - There's no exception handling.
> > - There are no RAII principles implemented.
> > - Parent/child object hierarchy is loose or not implemented, all of the burden of proper order of calls is on programmer.
> >
> > And so on...
> >
> > C++11 is really a remarkable feat of engineering and me personally like to see fully C++11 implemented software.
> > Unfortunately, for libzmq this would require substantial rewrite of the library.
> >
> > Maybe there's an option to create another parallel branch to existing libzmq or even create another product, for example "libzmq11"?
> > On the wire this could be 100% compatible with non-C++11 libzmq but there would be 0% chance to compile older projects with it.
>
> This is a good time to bring out some old blog posts. Martin
> Sustrik was the original developer of libzmq. He had some
> thoughts on why he should have written the library in C instead
> of C++. Here you go:
>
> http://250bpm.com/blog:4
>
> http://250bpm.com/blog:8
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>
>
>
>
> --
>
> Jovan Bunjevački.
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Jovan Bunjevački.
_______________________________________________
zeromq-dev mailing list
<mailto:zeromq-dev at lists.zeromq.org> zeromq-dev at lists.zeromq.org
<https://lists.zeromq.org/mailman/listinfo/zeromq-dev> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170522/7510b7d6/attachment.htm>
More information about the zeromq-dev
mailing list