Hi, I know the "Why should I have written...." serie of reflections. Really great. But...
Who is using today struct in the middle of a C++ code? Discussing about struct and class is a bit obsolete here, because of the alternatives to struct in C++ for putting together data, even if the question of Object Orientation is highly important. The observation here is that there is a divide between IT and Telecom engineers, for instance, because of the missing skills in programming. Giving a modern "face" to zeromq might impact the overall performance, of course, but it is not a FACT today, but only an extrapolation. Cheers On Tue, 23 May 2017 at 12:00, <[email protected]> wrote: > Send zeromq-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of zeromq-dev digest..." > > > Today's Topics: > > 1. Re: Porting libzmq to C++17 (Marcin Romaszewicz) > 2. Re: Porting libzmq to C++11 (Jens Auer) > 3. Re: Porting libzmq to C++17 (Jens Auer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 May 2017 10:59:59 -0700 > From: Marcin Romaszewicz <[email protected]> > To: ZeroMQ development list <[email protected]> > Subject: Re: [zeromq-dev] Porting libzmq to C++17 > Message-ID: > < > cackfmauoq7mn2h8omifrfqgrqfwoign9gugapmk+mc6ddto...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Why? C++17 is syntactic sugar on top of older versions of C++. C++17 won't > give you more performance or better code, just easier to read. There are > still lots of old devices which only have C++98 support, which is probably > the most widely adopted C++ standard. > > A C++17 wrapper API which is optional around the older library would be > very nice for end users, though. > > On Sun, May 21, 2017 at 3:11 AM, Bela Berde <[email protected]> wrote: > > > It is not clear to me. There are still bugs and, of course, GCC is > > evolving. > > There should be, however, a concret action in porting zeromq to C++ 17, > > and at least on Ubuntu. > > Is there an initiative already put in place ? > > Cheers. > > > > Sent from my iPhone > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > 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/f652008d/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 22 May 2017 20:52:35 +0200 > From: "Jens Auer" <[email protected]> > To: "'ZeroMQ development list'" <[email protected]> > Subject: Re: [zeromq-dev] Porting libzmq to C++11 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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:[email protected]] Im Auftrag > von [email protected] > 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 . <[email protected]> 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 <[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. > > _______________________________________________ > zeromq-dev mailing list > <mailto:[email protected]> [email protected] > <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-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 22 May 2017 21:01:33 +0200 > From: "Jens Auer" <[email protected]> > To: "'ZeroMQ development list'" <[email protected]> > Subject: Re: [zeromq-dev] Porting libzmq to C++17 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Hi, > > > > I don’t think it is just syntactic sugar, even if the changes are not what > I was hoping for. Inline variables and guaranteed copy elision are semantic > changes, so there are some non-syntactic features. Most changes are small, > but I think they will have significant impact on the way that modern C++ is > written. I am thinking especially of structured bindings and the template > deduction of constructors. The constructor deduction will eliminate a ton > of basically useless helper methods like make_pair, so I welcome this sugar > very much. Things like the new if with initializers and if constexpr make > C++17 just easier to write and read. Also, the new library has nice > additions like std::optional or std::string_view, although array_view is > missing. It has also parallel STL algorithms and the iterator hierarchy > contains contiguous iterators, which are nice for system-programming. My > favorite additions is std::byte. Finally we can stop to use chars as bytes. > > > > I would really go for the latest standard, even if there are some bugs in > the compiler or libraries. Given the expected time for a re-write or fork, > there should be enough time to stabilize. > > > > Cheers, > > Jens > > > > Von: zeromq-dev [mailto:[email protected]] Im Auftrag > von Marcin Romaszewicz > Gesendet: Montag, 22. Mai 2017 20:00 > An: ZeroMQ development list > Betreff: Re: [zeromq-dev] Porting libzmq to C++17 > > > > Why? C++17 is syntactic sugar on top of older versions of C++. C++17 won't > give you more performance or better code, just easier to read. There are > still lots of old devices which only have C++98 support, which is probably > the most widely adopted C++ standard. > > > > A C++17 wrapper API which is optional around the older library would be > very nice for end users, though. > > > > On Sun, May 21, 2017 at 3:11 AM, Bela Berde <[email protected]> wrote: > > It is not clear to me. There are still bugs and, of course, GCC is > evolving. > There should be, however, a concret action in porting zeromq to C++ 17, > and at least on Ubuntu. > Is there an initiative already put in place ? > Cheers. > > Sent from my iPhone > _______________________________________________ > zeromq-dev mailing list > [email protected] > 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/4a601619/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > ------------------------------ > > End of zeromq-dev Digest, Vol 14, Issue 16 > ****************************************** > -- Sent from iPad
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
