[zeromq-dev] Porting libzmq to C++11
Holger Joukl
Holger.Joukl at LBBW.de
Fri May 19 18:23:21 CEST 2017
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 . <bjovan at gmail.com>:
> 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 <lists at chuckremes.com>:
> 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 . <bjovan at gmail.com> 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 <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.
> _______________________________________________
> 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._______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> 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
More information about the zeromq-dev
mailing list