... 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 . <[email protected]>: > 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 <[email protected]>: > >> 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:[email protected]] 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 <[email protected] >> > <mailto:[email protected]>>: >> > >> > 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, <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > >> > > On May 17, 2017, at 7:56 AM, BJovke . <[email protected] >> <mailto:[email protected]>> 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 >> > [email protected] <mailto:[email protected] >> > >> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >> > >> > >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >> > >> > >> > >> > >> > -- >> > >> > Jovan Bunjevački. >> > >> > >> > _______________________________________________ >> > zeromq-dev mailing list >> > [email protected] >> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > > -- > > Jovan Bunjevački. > -- Jovan Bunjevački.
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
