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-boun...@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 <somdo...@gmail.com
> <mailto:somdo...@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, <li...@chuckremes.com
>     <mailto:li...@chuckremes.com>> wrote:
>
>
>         > On May 17, 2017, at 7:56 AM, BJovke . <bjo...@gmail.com 
> <mailto:bjo...@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@lists.zeromq.org <mailto:zeromq-dev@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@lists.zeromq.org <mailto:zeromq-dev@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@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to