I'm but a silent lurker here, but I couldn't resist: https://hintjens.gitbooks.io/scalable-c/content/preface.html: "Why not C+ +?"
;-) I'm not sure if this is still the case today but in my (rather outdated) experience it can be difficult next to impossible to use C++ libraries built with a different C++ compiler, even if they only expose a C interface. This might happen e.g. due to usage of exceptions in the library C++ code and their different compiler implementations. Which might mean you'd need to build your (C++) program and a library you use (0MQ) with the same compiler - and there's a potential that you're just not able to do that due to conflicting compiler version requirements (maybe you just mustn't use the latest & greatest C++11/14/17-enabled compiler for your program because of corporate restrictions, maybe other libraries demand another compiler (version) that isn't as modern). In essence, you're screwed if part of your program demands a certain C++ compiler and runtime and other parts demand another. If this part is closed source than it's not even under your control. I think this is far less a problem for pure C libraries, which may also be (way) more portable (think e.g. embedded). But I'm not really a C++ developer so maybe this has improved or there are measures to work around it... (And yes I know the current 0MQ core is also C++; I don't know what measures have been taken there to heighten portability/compatibility - think not using exceptions at all etc.) Best regards Holger > And, by the way, I see that Martin Sustrik had his last commits on > nanomsg in 2014, before he started working in Google in beginning of 2015. > > This is also one of the issues with open-source projects, a danger > that it can become a dead project. > > 2017-05-19 15:50 GMT+02:00 BJovke . <[email protected]>: > Actually I've read the whole blog post together with the comments. > > I have to say that author had many wrong points: > Speaking of C++ as a bad language doesn't make any sense to me. > Especially when it seems that he did not read the story behind many > of the principles and why are they introduced in C++. > Everyone's free will is to choose the language in which to develop > it's own code. Hence if author didn't feel comfortable with C++ he > should have used C only. > It seems that the author's knowledge about C++ comes down to one of > the earliest C++ versions called "C with classes". The code fits > perfectly into that language. > In nanomsg (you have a typo, it's not nanonmsg), the author simply > discarded all of the C++ constructs, which was really easy to do > since the libzmq code is almost pure C. > The blog post is old, possibly from time when C++11 has just appeared. > I'm not convinced with any of the points he stated against C++. > I have a feeling that history is repeating itself: "why would you > use magnetic tapes when punch cards are the best way to input > program into computer?". > I'm not sure this is the place to discuss in details all of the > claims from the post, but I'm not against it. > Discussion about that can give us clearer picture about libzmq, C and C+ +(11). > > Greetings. > > 2017-05-19 15:29 GMT+02:00 <[email protected]>: > 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 > [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 > > LBBW IT-Security: Diese E-Mail wurde unverschlüsselt übertragen. Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
