What are the alternatives for SOAP development in C++? Which one do you prefer and is most supported/modern?
Check out Apache Axis. That is my all times favorite SOAP implementation. It's SOAP done right! Exists for C++ and Java.
http://ws.apache.org/axis/
And in best traditions of Apache Foundation, it is FREE and OPENSOURCE.
So, enjoy!
I had to make SOAP calls for a project a while ago and the only acceptable solution I found was GSOAP.
http://www.cs.fsu.edu/~engelen/soap.html
It supports both C and C++ code, although working with C++ is nicer and easier to understand. It worked ok although there was an incompatibility with our WCF web service which meant we had to manually edit the automagically generated source code.
I stumbled on gsoap awhile ago, but I wasn't a huge fan of its interface and code generator. And as I remember it, the documentation is significantly lacking (or at least in a very difficult format).
Sometime in the near future, though, this library may be adding sockets support. At least, I suggested it to the developer some time ago and he seemed to think it was the idea, and a few months later an XML parser showed up in the API. I'm a big fan of that library, and would definitely use it more if it wasn't GPL.
If you are writing for Windows, Microsoft has a utility that comes with the Windows 7 SDK (And visual studio 2013 and later) called WSUTIL. It generates C proxies given a WDSL file, as shown in this example.
http://msdn.microsoft.com/en-us/library/windows/desktop/gg288974.aspx
KD Soap if you are in Qt C++. This is the URL
https://www.kdab.com/kd-soap/
SmartWin++ have a side-project called SmartSOAP which is pretty neat I think, it features a pretty complete stack starting from SocketStream, working its way up to HttpRequest/Response objects. Features a small (to the job) XML DOM class abstraction and goes up to SOAP. It even comes with a WSDL parser to create proxy classes for you. It heavily uses templates and STL. And is pretty awesome C++. Works on Windows Mobile...
Though it isn't extremely rich, doesn't feature stuff like SSL and such. But since the code is pure art I would guess it could easily be understood and extended upon yourself...
License is New BSD...
Disclaimer; I implemented it...
Related
I have written an simple applications in C++, and I need to connect with any RIA just for viewing the process ... is there is any good RIA based on C++
Qt is a good, popular cross-platform GUI library for C++.
I don't know whether it matches your definition of "RIA", though.
Silverlight is the nearest framework for you. You may find this Stackoverflow question interesting.
Update
After seeing your comment, I'd recommend you using ISAPI or CGI programming in C or C++
Update 2
After figuring that you need to execute C++ code from browsers, The answer is ActiveX. But portability is an issue, rather.
Generally speaking, this is difficult to do. Clients don't trust running arbitrary C++ code from the internet, because people don't want every website under the sun to be able to install malware, and generally hijack the entire machine, every time they visit a web site. In the general case, therefore, what you want is not really possible.
If you're willing to require the user to answer a ton of prompts, and are okay restricting your application to Internet Explorer on Windows, you could familiarize yourself with COM and write an ActiveX control.
I would strongly advise against doing so, however.
Have you looked at Qt? It comes with Webkit built-in. It is also more portable than other RIA implementations. BTW, most RIA implementations run on language virtual machines that are in turn implemented in C or C++ :-)
I know Wt is the most stable of them, but it's a bit uncomfortable to use.
CppCMS sounds good but how stable is it? How secure is it?
I have encountered C++ Server Pages as well but there's nothing about their security in there.
Has anyone had some experience with any of those libraries and can enlight me?
First of all, several differences:
Wt is GUI like framework, it is quite far from traditional web development. So, if you
want to develop a code as if it was GUI it is for you.
CppCMS is traditional MVC framework optimized for performance, it has many features like template engines, forms processing, i18n support, sessions, efficient caching and so on, support of various web server APIs: FastCGI, SCGI and CGI. If you come for Django world, you would find yourself at home.
I'm less familiar with the third project, but it feels more like PHP -- you put the
C++ code inside templates and has no clear separation of View and Controller.
Stability, I can tell only about CppCMS, it is stable, and there are applications running
it 7/24, the authors blog and the Wiki with documentation of CppCMS are written in CppCMS.
So, there shouldn't be major critical bugs.
Disclosure: I'm developer of CppCMS.
I am the developper of libapache2-mod-raii and I am very disappointed we did not recommend this library for production work... Cause I do ! :)
I also like to point out that the project page is also available in English.
On the other hand, I do not agree with Steve about the fact that servlets are not compiled on the fly, as they are !
Otherwise, on the lacks of prefork support is not my point of view, although I was looking on the issue.
On a side note, I used mod_raii a while ago to rapidly port some parts of an existing C++ application on the web.
It takes exactly the same approach than JSP, with the whole compilation part delegated to the Apache module.
I cannot recommend it for production use, since I don't have much experience in it, but it is definitely something worth playing around with, and I didn't have any issue at the time.
It lacks some features like the support of a preforked apache, but has all the needed core features.
Answer from 2018:
I am running on limited hardware resources, so C++ is the first thing I think of. I made a decision by looking at this benchmark of web frameworks. cutelyst (a Qt derivative) and Wt dominate the top spots. They are all non-libre. So, I looked into treefrog. Right after its first and only tutorial, it is apparent that it uses qmake from Qt and thus Qt's LGPL applies.
I reluctantly go with CppCMS at the bottom of the list, as ffead has too many errors and poco is not a fullstack framework.
Diving into the tutorials, CppCMS is way ahead of treefrog when it comes to documentations. The first several tutorials are easy to follow. However when I start encountering problems, help is almost non-existent. I can't imagine how it would be like going with treefrog to get something done. Lack of documentations (and good ones) is the reason why I dumped it in the first place.
I almost dumped CppCMS also due to a serious roadblock. A tiny community cannot offer much help. Got Laravel (a very popular PHP framework) installed and about to test something. Then, the CppCMS issue seemed resolvable and I am back to it. Guess I am about to get stuffs done with CppCMS but its constraints are showing.
The incident got me thinking, and I look back at the benchmark, allowing Java and PHP to be there. I need some alternatives in case things don't work out. Lo and behold, the top three spots are occupied by Java frameworks. Laravel may not be the fastest, but it is really hot right now. Plus, I can call my C++ executables from PHP codes.
According to this discussion: if you use Qt with dynamic linking, it seems that you do not have to disclose your code if you use Qt with dynamic linking. This has to be researched, and Qt cannot be mastered within a single day. I suppose that makes cutelyst a possible choice again, IF AND ONLY IF you can do dynamic linking, and do all your things that way. I am just not a fan Qt's legal minefield and jumping hoops.
Through all this, I have a different look towards Java. Will still do Laravel because of all the rage, and I am now open to things other than C++.
I'm just starting my first C++ project. I'm using Visual Studio 2008. It's a single-form Windows application that accesses a couple of databases and initiates a WebSphere MQ transaction. I basically understand the differences among ATL, MFC, Win32 (I'm a little hazy on that one actually) and CLR, but I'm at a loss as to how I should choose.
Is one or more of these just there for backward-compatibility?
Is CLR a bad idea?
Any suggestions appreciated.
Edit:
I've chosen C++ for this project for reasons I didn't go into in the post, which are not entirely technical. So, assuming C++ is the only/best option, which should I choose?
It depends on your needs.
Using the CLR will provide you with the most expressive set of libraries (the entire .NET framework), at the cost of restricting your executable to requiring the .NET framework to be installed at runtime, as well as limiting you to the Windows platform (however, all 4 listed technologies are windows only, so the platform limitation is probably the least troublesome).
However, CLR requires you to use the C++/CLI extensions to the C++ language, so you'll, in essense, need to learn some extra language features in order to use this. Doing so gives you many "extras," such as access to the .net libraries, full garbage collection, etc.
ATL & MFC are somewhat trickier to decide between. I'd refer you to MSDN's page for choosing in order to decide between them. The nice thing about ATL/MFC is that you don't need the .NET framework, only the VC/MFC runtimes to be installed for deployment.
Using Win32 directly provides the smallest executables, with the fewest dependencies, but is more work to write. You have the least amount of helper libraries, so you're writing more of the code.
Win32 is the raw, bare-metal way of doing it. It's tedious, difficult to use, and has a lot of small details you need to remember otherwise things will fail in relatively mysterious ways.
MFC builds upon Win32 to provide you an object-oriented way of building your application. It's not a replacement for Win32, but rather an enhancement - it does a lot of the hard work for you.
System.Windows.Forms (which is what I assume you meant by CLR) is completely different but has large similarities to MFC from its basic structure. It's by far the easiest to use but requires the .NET framework, which may or may not be a hindrance in your case.
My recommendation: If you need to avoid .NET, then use MFC, otherwise use .NET (in fact, in that case, I'd use C# as it's much easier to work with).
As far as C++ goes, I would use WTL. It's lightweght and you will have few (if any) dependencies, making it easy to ship and install. I find it very satisfying when my app consists of a single EXE that will run on most versions of Windows, but this may not be a concern to you.
If you choose to go .NET instead, then C# is almost certainly the way to go.
More in WTL here:
http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx
I would be very curious as to why you would do this in C++ at all. Based on your brief description, C# sounds like a much more appropriate choice.
Just to elaborate a bit, look at the link you gave describing the C++ CLR. The top rated answer notes (accurately, in my opinion) that C++ is appropriate for "kernel, games, high-performance and server apps" - none of which seems to describe what you're doing.
MFC, ATL, etc are going to be supported in the sense that, yes you'll be able to compile your app on future versions of Visual Studio and run them on future versions of Windows. But they're not supported in the sense that there's not a lot of new development going on in the API or the language the same way there is in the CLR and C#.
There is nothing wrong with CLR. Like others here I'd suggest C# but as you have reasons for sticking with C++ then using the .NET framework is several thousand times easier than messing with ATL/MFC if you're not already familiar with them (IMO).
It may be worth mentioning that if you're using C++/CLR then you're not really using C++ at all. C++/CLR compiles to CIL just like C#. I've never used it myself but I believe its purpose is to allow you to compile legacy code and make it easily available to new .NET code rather than allow new code work with old C++ executables. There are other methods of calling native code from .NET which, perhaps, you should explore.
The modern (2021) answer to this question would appear to be to use C++/WinRT instead of C++/CLR (or C++/CLI or C++/CX... jeez Microsoft):
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt
C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.
...
C++/WinRT is Microsoft's recommended replacement for the C++/CX language projection
It's basically standard C++ but the UI is defined with XAML.
Still though, as with the other answers, it would appear that using C# is really microsoft's favorite approach. C++/WinRT really looks like it's almost C# anyways.
I have an application written in Delphi that compiles in Delphi 2007. I think it was originally written in Delphi 7.
Anyway, I need to convert all the core non-GUI code into C++ because I want to release a Mac version of the software.
What is the best way to do this? Any shortcuts I can take to speed up the process?
EDIT: The code compiles to native code, not .NET.
Simple answer: You simply can't port non-trivial Delphi code to C++ without a complete rewrite. C++'s object model is very different from Delphi's. It doesn't have a base class like TObject from which all other objects are derived, and it lacks support for a lot of the RTTI stuff that Delphi code often takes for granted. And there's no simple way to reimplement Delphi RTTI in C++, since a lot of it's done at the compiler level, and a lot of it's based on the fact that all Delphi classes descend from TObject.
C++ also lacks support for the concept of unit initialization and finalization sections that are so common in Delphi, and what it has instead is badly broken. (Look up the "static order initialization fiasco" for all the gory details.)
Delphi's exception handling is also much more advanced than C++'s. Part of this is the object model and part of it's compiler magic. Plus, C++ has no support for the try-finally construct.
If you want to port a Delphi project to the Mac, Free Pascal is your best solution. It's not 100% compatible with Delphi, but it's good enough for a lot of things, and you specifically mentioned that you don't need to port the Delphi GUI stuff. AFAIK the GUI area is the source of most of FPC's compatibility weaknesses, so if that's not necessary, FPC is probably pretty close to ideal for your needs, at least until CodeGear gets an OSX compiler out. (Which hasn't been officially announced, but based on various things that have been said it's not unreasonable to suppose that one will be available sometime next year.)
For converting your code from Delphi to Cpp, have a look at
http://ivan.vecerina.com/code/delphi2cpp/.
I used this to convert some of the classes and functions in SysUtils, DateUtils and StrUtils using wxWidgets functions. If you are planning to use wxWidgets for C++ have a look at http://twinforms.com/products/wxwidgets/wxvcl.php which has all the converted source.
If you want directly develop Mac OSX applications using then have a look at wxForms for Delphi - http://twinforms.com/products/wxformsdelphi/index.php
I think this would be difficult to do mechanically, so you are probably looking at a complete re-write. One thing to bear in mind is that typically Delphi uses try...finally structures for resource management, whereas C++ uses a technique known as RAII (resource acquisition is initialisation). You should read up on this and other C++ idioms before you attempt the conversion.
If your code compiles in Delphi 2007 into .NET assemblies, you may have a much easier option than trying to port from Delphi's object pascal to C++.
You could potentially compile your logic into .NET assemblies (and maybe even portions of the UI), and use Mono to run it on Mac. You could write a custom GUI around Mono, or even potentially make a single, platform independent application.
You can use also Delphi Prism. It's for .NET, but it's the last expression in Delphi language spec. It supports also Mac OSX (see the link). Also the guys from CodeGear/EMBT are in the works for a new compiler as well as for a new version of Delphi which is expected to enter in beta in April and narrow the gap between Prism and RAD studio. See their 'Beta Programs' page.
The "correct" way to do this is to rewrite it in Objective C. I find Objective C a little weird, but there are a lot of similarities with Delphi in the way objects connect and delegate.
You may be able to use Free Pascal to do it more quickly, but you should seriously consider a rewrite.
I would be in love with Embarcadero if they could release a Mac OS X version of Delphi that didn't, you know, suck like Kylix did. One can dream.
Edit: There is a great benefit to staying in Delphi, and having a separate version for the Mac in Objective C. First, it means you don't need to rewrite the version on Windows, losing the (presumably) years of investment in Delphi code. Second, Mac software operates differently than Windows, from a UI perspective. A simple port of the product is inappropriate, and hobbles the developer from using the great native features of Windows and Mac. See: older versions of MS Word for Mac, or iTunes for Windows. They look and feel wrong.
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.