[zeromq-dev] Porting libzmq to C++11
BJovke .
bjovan at gmail.com
Fri May 19 15:28:49 CEST 2017
... sent the previous message prematurely...
There are also many aspects of libzmq which make it hard to adopt the code,
instead requiring complete rewrite:
- The API needs to be radically different while the functionality
remains the same. If we are to use RAII and no pointers exposed outside of
library this is a must.
- Hundreds of #ifdef <platform xxx> need to be get rid of, except in the
network part which is still not standardized on a C++ level.
- For me the only obvious and efficient way to use different types of
libzmq sockets is via templates. This is completely against current libzmq
structure.
- Porting some structures from libzmq just for the sake of less effort
is a double edged sword. It might make C++11 idea again just another
wrapper around old code.
- Wrapping of any calls inside others is clearly not wanted at all.
- and so on..
Greetings.
2017-05-19 15:21 GMT+02:00 BJovke . <bjovan at gmail.com>:
> 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.
>
--
Jovan Bunjevački.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170519/9c7f40f9/attachment.htm>
More information about the zeromq-dev
mailing list