If we check the official documentation we can find various ways of interfacing Erlang and C/C++. A similar question was asked here in 2009 and I would like to know how the things changed since then.
Is there any mature stable library that does all the dirty work of implementing binary protocols between Erlang and C? Is it ei or erl_interface and what is the difference between them?
I mean this seems to be a quite common problem and I hope that someone has successfully solved it already and there is no need to write your own Erlang Port Driver anymore, since most of it is generic code.
P.S. I have also found this library: EPAPI.
Nothing have changed significantly since 2009, the top answer from the question you linked is still correct.
NIFs became less experimental starting from R14 and are actively used in some projects, but they are still incompatible with HiPE compiler (native flag to compile).
Related
I am coding in C++ for a while, and I already get used to platform compatibility issue. But now, I realized that backward compatibility is another substantial issue:
How can the Boost libraries be used successfully for important projects?
Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible.
(Source: http://www.boost.org/users/faq.html)
Does Java have the same issue? I know that the situation is different from package to package, but how about Java packages that are as much famous as boost is in C++ world?
You have conveniently snipped the rest of the answer on the Boost FAQ, which tells you how to deal with this problem:
Deal with this by freezing the version of the Boost libraries used by
your project. Only upgrade at points in your project's life cycle
where a bit of change will not cause problems. Individual bug fixes
can always be obtained from the boost repository.
As for the rest of your question...
Does Java have the same issue?
Of course. This is not an issue with a specific programming language. It's an issue with 3rd-party libraries or frameworks in general.
I know that the situation is different from package to package, but how about Java packages that are as much famous as boost is in C++ world?
There is nothing like Boost for Java, because many things offered by Boost are already part of the Java framework itself, for better or worse. Think of string algorithms or filesystem operations.
That being said, perhaps Apache Commons comes close. As it turns out, it has its own share of backward compatibility issues -- which, as I said above, is completely normal. For example, the release notes for v4.0 clearly state the following:
This version uses the generics features of Java 5 and is not compatible with earlier JDK versions.
(...), we have chosen to break the API in various ways. (...) We have also removed all deprecated classes and fixed oddities in the previous API that we couldn't fix due to backwards compatibility restrictions.
Keep in mind that both Boost and Apache Commons deal with this fundamental software-engineering problem in a very professional and well-documented way. Unfortunately, the same cannot be said about most other libraries and frameworks you will encounter in the wild, regardless of the programming language used.
This question already has answers here:
Biggest differences of Thrift vs Protocol Buffers? [closed]
(15 answers)
Closed 7 years ago.
I've been using PB for quite a while now, but, Thrift has constantly been at the back of my mind.
The primary advantages of thrift, as I see it are:
Native collections (i.e, vector, set etc) vs PBs repeated providing functionality similar to, but not quite like (no iterators unless you dig into RepeatedField which the documentation states "shouldn't be required in most cases").
A decent RPC implementation provided, instead of just hooks to plug your own in.
More officially supported languages (PB offers "official" support for Java, C++, Python)
The cons of Thrift:
The RPC implementation means I can't plug in my own (for example) encryption/authentication layer on top.
Windows support doesn't seem to be great.
PB definitely seems to have, if not better, more accessible documentation.
Neutral:
Unknown size of .lib/.dll on Windows (Thrift).
Large size of .lib on Windows (PB, but it does offer a -lite which is significantly smaller).
Speed wise, they both seem to be similar.
I'm not quite ready to take the plunge and switch to Thrift yet, can anyone offer me more pros/cons, or reasons to go one way or the other?
Thanks!
As I've said as "Biggest differences of Thrift vs Protocol Buffers?" topic :
Referring to Thrift vs Protobuf vs JSON comparison :
C++, Python, Java - in-box support in Protobuf and Thrift.
Protobuf support for other languages (including Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) is available as Third Party Addons (btw. Here is SWI-Prolog support).
Protobuf has much better documentation and plenty of examples.
Protobuf objects are smaller
Protobuf is faster when unsing "optimize_for = SPEED"
Thrift has integrated RPC implementation, while for Protobuf RPC solutions are separated, but available (like Zeroc ICE ).
Protobuf is released under BSD-style license
Thrift is released under Apache license
Additionally, there are plenty of interesting additional tools available for those solutions, which might decide. Here are examples for Protobuf: Protobuf-wireshark , protobufeditor.
You might want to analyse your need first:
Do you need a protocol-agnostic format? For example, do you want to implement a custom protocol or need 100% portability? In such a case use PB.
If you are fine with the default protocol of Thrift, and you need a protocol to begin with, by all means, go with Thrift.
Hope this helps.
Our project's main reason to stick with Thrift over protocol buffers was that protocol buffers don't auto-generate a complete RPC server, and existing solutions for PB seemed to all be fairly unstable. Just my $0.02.
You need to specify your use case(s) in detail. Else this is a "Which is better, a car or a truck?" question.
Can anyone tell me what are the debugger(s) available for the C++ language.
Also please provide details about those debugger or reference to get details for the same.
Wikipedia has a comprehensive list of debuggers. Far bigger than any indidivudal is going to rattle out off the top of their head. Of course without limiting it to a platform the list is huge and potentially full of esoteric solutions. For what it's worth most debuggers that started life with C also offer C++ support these days.
Probably the two major ones would be the one built into Visual Studio and gdb for gcc although there is, of course, a plethora of such things.
It probably depends quite a bit on what environment you're using as to which debugger is suitable. Since you haven't specified even the platform you're developing on, that's about as much help as I can give.
I need to use XmlRpc in C++ on a Windows platform. Despite the fact that my friends assure me that XmlRpc is a "widely available standard technology", there are not many libraries available for it. In fact I only found one library to do this on Windows, (plus another one that claims "you'll have to do a lot of work to get this to compile on Windows). The library I found was Chris Morley's "XmlRpc++". However, it doesn't have support for SSL.
My question therefore is: what library should I be using?
I've written my own C++ library. It's available at sourceforge:
xmlrpcc4win
The reason I wrote it rather than using Chris Morley's was that:
The Windows "wininet.lib" library gives you all the functionality for handling Http requests, so I'd rather use that. As a result, I only needed 1700 LOC.
"wininet.lib", and therefore my implementation, supports HTTPS
Chris Morley's use of STL containers was quite inefficient (Chris, mail me if you read this).
Until I wrote my own library, (see above) here was my answer:
Currently, the XmlRpc++ library by Chris Morley is the only public domain/LPGL XmlRpc implementation for C++ on Windows.
There are a couple of C++ implementations for Linux, either of which could be presumably easily ported to Windows, but the fact seems to be that no-one has yet done so and made it publicly available. Also, as eczamy says, "The XML-RPC specification is somewhat simple and it would not be difficult to implement your own XML-RPC client."
I'm using Chris Morley's library successfully, despite having had to find and fix quite a number of bugs. The Help Forum for this project seems to be somewhat active, but no-one has fixed these bugs and done a new release. I have been in correspondence with Chris Morley and he has vague hopes to do a new release, and he has contributed to this stackOverflow question (see below/above) and he claims to have fixed most of the bugs, but so far he has not made a release that fixes the many bugs. The last release was in 2003.
It is disappointing to me that a supposed widely supported (and simple!) protocol has such poor support on Windows + C++. Please can someone reading this page pick up the baton and e.g. take over XmlRpc++ or properly port one of the Linux implementations.
There are dozens of implementations of the XML-RPC implementations, some in C++, but most in other languages. For example, besides XmlRpc++ there is also XML-RPC for C and C++. Here is a HOWTO on how the XML-RPC for C and C++ library can be used.
The XML-RPC specification is somewhat simple and it would not be difficult to implement your own XML-RPC client. Not to mention, it would also be possible to take an existing XML-RPC implementation in C and bring into your C++ project.
The XML-RPC home page also provides a lot of useful information.
Just wanted to note a couple of items:
The source in the cvs repository for XmlRpc++ has support for OpenSSL (although I have not tried it, it was contributed by another developer).
Most of the reported bugs are fixed in cvs; I don't have access to a linux machine at the moment, so I haven't made an official release.
XmlRpc++ is not public domain. It is copyrighted and licensed (LGPL).
Thanks,
Chris Morley
I was able to get Tim's version of xml rpc working with https and with basic username / password authentication.
For the authentication:
1) the username and password need to be passed to the InternetConnect(...) function
2) an http request header of "Authorization: Basic base64encoded(user:pass)" needs to be added prior to sending the HttpSendRequest(...) command.
I was a C++ developer (mostly ATL/COM stuff) until, as many of us, I switched to C# in 2001. I didn't do much C++ programming since then.
Do you have any tips on how to revive my C++ skills? What has changed in C++ in the last years? Are there good books, articles or blogs covering the language. The problem is that most material I could find either targets people who are new to the language or those with a lot of experience.
Which C++ libraries are popular these days? I guess I will need to read on the STL because I didn't use it much. What else? Boost? ATL? WTL?
Boost - though it, and other libraries were around back then, its only relatively recently that it's taken off in a big way. Google for TR1 and c++0x standards too. You should defintely read up on STL because (IMHO) its the thing that makes C++ special.
ATL is as good a dead technology (don't get me wrong, I liked it and still use it somewhat, but its not fashionable in the MS world anymore).
Something like QT is probably more new and cool for C++ developers, and has the advantage of getting you into all the new Linux and web development that'll be increasingly popular over the next few years.
However, once you start looking at the things you can do, I think it'll all come back quite quickly.
I personally find that syntax is where i mostly need to catch up when i wander back to a language i havent used in a long time. But the concepts and what the language is about stays the same in memory.
Assuming its the same with you, i would say its a good idea to relook at the texts you remember to have been useful to you while learning C++. I would recommned Thinking in C++ for getting up fast on the syntax.
STL would be really useful yes. Thats one thing i have found commonly appreciated by all mature C++ programmers. It would be useful to know the libraries that Boost provides.
The changes to C++ world, depends on the changes your favourite compiler has decided to implement. Since you mentioned ATl/COM i assume it would be VC++. The changes to MFC would be support for Windows Forms (2005 vc++) and Vista compliant uI's and ribbon support(?) (2008 Vc++)
VC++ now supports managed C++ -i'm sure you know what that is coming from the C# world - 2008 adds supports for managed STL too.
VC++ is trying to be more standards compliant and are making some progress in that area.
They have introduced lots of secure functions that depreciate the old stds like strcpy and the compilers will also give warnings if you use the old fns.
VC++2005 also has something called function attributes, which it uses to describe the parameters so that it can do more checking on the inputs you pass in and statically flag a warning if it sees soething amiss. Usefuli would say though our shop has not progressed to using the 2005 compiler.
MSDN has the list of breaking changes for each releases. Oh & Support for Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0 has been removed from 2005 version of VC++. Additionally the core libraries you required till now (CRT, ATL, MFC etc) now support a new deployment model which makes them shared side sy side assemblies and requires a manifest.
This link should get you going - http://msdn.microsoft.com/en-us/library/y8bt6w34.aspx
2008 adds even more like Tr1 recommendations, more optimizning compiler, parallel compilation(/mp), support for new processor architectures etc. Open Mp support has also been enhanced in one of these versions is what i remember.
Again refer MSDN - thats the suthentic source for all the answers.
Good luck.
Definitely read the latest edition of "Effective C++" by Scott Meyers. I would also recommend "C++ Gotchas: Avoiding Common Problems in Coding and Design" by Stephen C. Dewhurst.
To sharpen your C++ skills I'd suggest going over some of your old C++ code if you still have access to it. Revisiting it will hopefully trigger those parts of your brain that have laid dormant after switching to C# :)
For libraries STL is good, then boost. I don't think there is too much new stuff going on with ATL/WTL from what you would have known back in 2001.
Just start a project. The libraries you use will depend on your project, but you should certainly read up on the STL. If you haven't used C++ for a long time you might need learn more about templates.
Pickup one of the C++ Unit Test frameworks out there (I suggest Google C++ Testing Framework, aka. gtest). Pick a small project that you can start from scratch and try some TDD. The TDD will encourage you to make small steps and to reflect on your code. Also, as you build your suite of unit tests, it gives you a base from which you can experiment with different techniques.
Rewrite some of your C# stuff using C++
For a start, I'd say try writing code that will work on both a Mac and Windows or Linux and Windows. This will force you to write code that is much more portable than the type of C++ code you can get away with on Visual C++ - there a lot of finer points that are very different when you go cross platform.
I'd suggest stay away from libraries for now if you can - perfect your ANSI C++ game first. I'd also suggest reading up on C++0x - the next standard is due soon and it would help you more to work towards that. To that end, brush up on the STL (the concepts behind it, not the implementation so much) and templates.
If you'd like to try BOOST, go ahead, but you can generally get by without using it. The reason I stayed away from it mostly is because of the way templates are used to do what is needed - a lot of which will become much easier once the new standard is introduced.
UPDATE: Once you're comfortable with the STL and start needing to do things that require a lot of code with the STL or are just plain tricky, then head over to BOOST. Buy a book on BOOST and read it and understand it well.
Take some old piece of code and add to it. This won't get you back on top of the latest C++ trends but it will get your feet wet.
At my job I had to add some features to a C++ ActiveX control and I hadn't touched C++ in years and years and have never done it professionally. Figuring out how to do it again was actually pretty damn cool.
I was in a similar situation: switched from C++ to C# in 2005 and then switched back to C++ in 2007. I can't say C++ universe really changed in those 2 years. The most crucial thing was to regain my memory-management instincts, but that can only be done by practicing.
Now that you have both C++ and .NET under your belt you might want to study C++ CLI a bit (new incarnation of late "Managed C++").
As for books, read everything with "Meyers" and "Sutter" on the cover.