I'm a die-hard .NET developer with limited experience in C++. I'm really familiar with how happily interpreted languages (and scripting languages) work cross-platform, but what about C++?
I realize that GCC/GPP and some other compilers sorta work multi-platform with the right compiler flags, and I understand that the STL is normalized between compilers, but what else am I missing? I'll need to do audio in/out, high accuracy timers, and I'll need to do multithreading. I don't think any of these things are supported in the STL, so I'll be needing a cross-platform library of some type, right? Which one should I use?
I'm aiming to support the latest Mac and Windows platforms. This is a shared framework/sdk and won't have a UI. I plan on writing the UI in a native language such as Objective-C/Cocoa and .NET/WPF (both which have excellent native UI support).
So what should my tool chain look like? Should I be using GCC/GPP or MinGW? What other 'libraries' should I integrate that will function cross platform? I'd like to setup my build environment to 'just work' such that I can build a Mac compatible binary and a windows compatible binary (32 bit and 64 bit). How can I do that?
At this point, I'll be writing code for each platform so that I can interop with this my C++ multiplatform framework sdk/api thingy. In windows, I think this will look like a managed DLL, is that right? Any thoughts on how I'll do this on a Mac?
Any suggestions or recommendations?
Thanks for the suggestions,
Brett
1) Your real goal here should be to write portable C++ -- you get portability by keeping your language use clean, not by using a particular compiler.
2) Some of what you want, like audio i/o, is fairly inherently platform dependent. You can, however, cleanly isolate the platform dependencies inside particular modules and conditionally compile a set of platform support files on each platform.
3) Stuff like multithreading can be done in a platform independent manner using standard libraries.
Getting into subjective territory but for a developer used to working with large, do-it-all kind of frameworks like those we find in .NET, QT would probably be your best cross-platform C++ analogy (though I am not a huge fan of it). There you have your threads, XML I/O, localization, sockets, high accuracy timers, GUI building blocks, etc.
[...] and I'll need to do multithreading. I don't think any of these things
are supported in the STL [...]
Just a small thing, but the STL is limited to describing the aggregate containers and generic algorithms of the C++ Standard Library. It is not synonymous, but C++11 has specifications in the standard library for concurrency support. However, popular compilers are still slow to support it fully. You also have boost if you need threads for the time being: http://www.boost.org which is an extremely cross-platform library.
As for building an API that can happily plug in to various environments (.NET, Cocoa, etc), your best, most cross-platform option is actually to expose a C API (you're free to implement it using C++). It'll cause the least headaches this way (no issues with name mangling, trying to interop with complex, user-defined C++ types, etc.).
I recommend you get some practice with building DLLs/shared libraries in C++ as a way to extend .NET and Cocoa applications (ex: C++ module used in objective-C) before you start trying to develop a grand library.
For timing the standard library has <chrono>, which has nanosecond resolution on Mac. Unfortunately it's only got millisecond resolution on Windows as of the VS11 Beta. I'm hoping they fix it without too much delay.
Related
Are there any platforms to build GUI platform without resorting to QT or .NET using native C++ ?
QT is cool, but take a lot of time to learn, in addition it has a lot of things I don't really need and really dislike QT IDE, compared to Visual Studio (I know you can use QT within Visual Studio)
.NET suffers same problem (I am actually learning C# and WPF right now, though it looks like WPF is somewhat easier to program and you can call native C++ code from WPF)
I am looking for something that is: relatively easy learn, does not have to have advanced features, works with C++11, support C++11 multi-threading, works with Visual Studio. Planning to build some applications for Numerical analysis.
There are lots of alternatives with varying levels of support in VS.
MFC has quite a bit of direct support in Visual Studio in the form of code generators, Wizards, etc. Unfortunately, the basic design is very old and hasn't aged very gracefully at all. Quite a few programmers not only would but do cite it as a prime example of a library that's better avoided if humanly possible.
WTL is Microsoft's other class library for producing Windows applications. It's a much newer design than MFC and generally considered much cleaner and nicer. As implied by the name, it's heavily template based, which helps it produce applications that are generally considerably smaller and faster than MFC ever attempted. For better or worse, Microsoft placed it under a fairly permissive open-source license some time ago, and updates since then have been quite minimal. Despite both being from Microsoft, Visual Studio has never done much to support WTL development.
wxWidgets started as more or less a clone of Microsoft's MFC, but has continued active development while MFC has mostly stagnated. It now has quite a few features (e.g., XML-based UI design, layout managers) far beyond anything MFC ever even considered including.
Ultimate++ is a fairly unusual toolkit that has mapped its own route (so to speak) that's quite a bit different from most others. They have their own IDE (TheIDE). Code can be quite simple and short, but is enough different from most typical C++ that many people find it difficult to grasp at first (and some experienced C++ programmers don't particularly like how some thing work).
GTK+/gtkmm is less of a Windows framework than a Linux framework that's portable enough to also work under Windows. It's probably not your best choice if you're developing exclusively (or even primarily) for Windows. These are also much more purely GUI frameworks than most others (i.e., they don't include things like collections, networking, cryptography, etc., that many others do include).
FLTK is another cross-platform toolkit. Its fairly small and fast, but somewhat like GTK+, it seems (at least to me) less like a Windows toolkit, than a Linux toolkit that happens to be portable enough that it can also work on Windows (but the results don't look or feel much like most Windows applications).
Juce was originally used to develop some music software (Traktion) so it includes a lot of music-oriented functionality. It also have some fairly unusual widgets that most others don't include (especially widgets that imitate controls you'd see on all sorts of audio equipment). Nonetheless, it has a solid core of basic GUI functionality, as well as the usual "extras" like network, crypto, XML and JSON, etc. Although I haven't tried to do anything like a full review of the code, it appears to be rather better written than most.
That's not a complete list by any means, but I think it hits most of the more popular/widely used GUI toolkits (other than Qt, of course).
Some time ago I asked myself exactly that same question.
I wrote my program using C++/CLI, which was not bad (my C++ code was very well isolated from the GUI/CLI part), but sharing the executable with others was a problem: it was the typical - it runs in my PC(...only). So, I needed a light alternative to the user unfriendly command line programs in scientific calculations, which I could easily share.
I am now happy to use Nana. Please join the group of users and / or developers of Nana and... have fun!
GUI with Nana C++ Library
Nana C++ Library takes aim at easy-to-use and portable library. It
provides a GUI framework and threads for easy programming with modern
C++ methods, such as traits, metaprogramming and other template
technologies.
Since you plan to develop exclusively for Windows, I think you should stay with MS provided GUI toolkits. While third party toolkits may provide the cross platform advantage you already said don't need, they add complication and dependencies.
Complication by for example when a new Visual Studio is released, then you have to wait for the toolkit to get that new VS supported, and dependencies, which means more dlls to be installed on the target system.
Plus some toolkits do not use the native look of the operating system, like many java programs for example.
I'm starting development on a new Application, and although my background is mainly Mac/iOS based, I need to work on a Windows application for participation in their Imagine cup.
This project includes communication between clients through a socket connection (to a server, not ad-hoc), and I need for both Mac and Windows clients to be able to communicate with each other. I'd also like to not have to write this networking code twice, and simply write different native-UI code on both platforms. This makes the networking easier (I'm confident that two different platforms are not going to be interacting with the server in different ways) and allows for a native UI on both platforms.
Is C++ the best language for this task? Is the standard library the same on both platforms? I understand that I'll have to use Microsoft's Visual C++ library, as it seems as though it is hard to utilize C++ code from C#; is this true?
I've never really written a cross-platform application before, especially one that deals with networking between platforms.
If you're going to use C++, I second "the_mandrill" above by strongly recommending you look at ASIO in Boost - that is a great way to write the code once and support both platforms.
As to whether or not C++ is the right language is rather more subjective. My personal feelings are that if you need to ask, odds on, it's not the best approach.
Reasons for selecting C++ to implement networking code are:
Possible to achieve very low latencies and high throughput with very carefully designed and implemented code.
Possible to take explicit control of memory management - avoiding variations in performance associated with garbage collection.
Potential for tight integration of networking code in-process with other native libraries.
Potential to build small components suitable for deployment in resource constrained environments.
Low level access to C socket API exposes features such as socket options to use protocols beyond vanilla TCP/IP and UDP.
Reasons for avoiding C++ are:
Lower productivity in developing code compared with higher-level languages (e.g. Java/C#/Python etc. etc.)
Greater potential for significant implementation errors (pointer-abuse etc.)
Additional effort required to verify code compiles on each platform.
Alternatives you might consider include:
Python... directly using low level socket support or high-level Twisted library. Rapid development using convenient high-level idioms and minimal porting effort. Biggest disadvantage - poor support to exploit multiple processor cores for high-throughput systems.
Ruby(socket)/Perl(IO::Socket)... High level languages which might be particularly suited if the communicated information is represented as text strings.
Java... garbage collection simplifies memory management; wide range of existing libraries.
CLR languages (C# etc.) also garbage collected - like Java... WCF is an effective framework within which bespoke protocols can be developed... which may prove useful.
You also asked: "I understand that I'll have to use Microsoft's Visual C++ library, as it seems as though it is hard to utilize C++ code from C#; is this true?"
You can avoid Visual C++ libraries entirely - either by developing using a language other than C++, or using an alternate C++ compiler - for example Cygwin or MinGW offer G++... though I'd recommend using Visual C++ to build C and C++ code for Windows.
It's not hard to use C++ code from C# - though I don't recommend it as an approach.. it's likely overly complicated. Visual C++ can (optionally) compile "Managed Code" from C++ source (there are a few syntax extensions to grasp and there's a slightly different syntax for interoperation using Mono rather than Visual C++, but these are not major issues IMHO.) These CLR objects interact directly with C# objects and can be linked together into a single assembly without issue. It's also easy to access native DLLs (potentially written using C++ for the native architecture) using Pinvoke. All this is somewhat irrelevant, however, as the .Net framework has good support for low level networking (similar to that provided by Winsock[2]) in system.net - this provides a convenient C#-oriented interface to similar facilities, and will likely provide a more convenient API to develop against if using C# (or VB.Net or any of the other CLR languages.)
I would suggest that you take a look at Qt. IMO Qt is one of the best C++ libraries for doing cross-platform application. The benefits of Qt when comparing with Boost is that Qt have even GUI classes.
Best language is very subjective, but if you want portable fast code with useful abstractions and C style syntax the C++ is a good choice. Note if you do not know any C++ already there is a steep learning curve.
The library as defined by the ISO standard is by definition the same on each platform, however the implementation of it my be less or more compliant. That said, both gcc, clang and MSVC(post .net) all implement C++98 very well. So long as you don't use compiler specific extensions.
I strong recommend looking at boost asio (and the boost library in general) for your networking, it uses the proactor design pattern which is very efficient. However it does take some time getting your head around it.
http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html
Stick with the Standard library and boost and for the most part cross platform problems are not a major concern.
Lastly, I would avoid using the C++11 features for writing cross platform code, because MSVC, GCC and Clang have all implemented different parts of the standard.
If you want to spend a year and put in a 1000 hrs sure use boost::asio. Or you can use a library that's built around boost::asio that invokes C++ network templates. This is crossplatform network and you can find it here:
https://bitbucket.org/ptroen/crossplatformnetwork/src/master/
It compiles on Windows,Android, Macos and Linux.
That is not to say if your absolutely expert level in boost::asio you can do a tiny bit better in performance but if you want to get like 98% of the performance gains you may find it useful. It also supports HTTP,HTTPS,NACK,RTP,TCP ,UDP,MulticastServer and Multicast Client.
Examples:
TCPServer: https://bitbucket.org/ptroen/crossplatformnetwork/src/master/OSI/Application/Stub/TCPServer/main.cc
HTTPServer: https://bitbucket.org/ptroen/crossplatformnetwork/src/master/OSI/Application/Stub/HTTPServer/httpserver.cc
OSI::Transport::TCP::TCP_ClientTransport<SampleProtocol::IncomingPayload<OSI::Transport::Interface::IClientTransportInitializationParameters>, SampleProtocol::OutgoingPayload<OSI::Transport::Interface::IClientTransportInitializationParameters>,
SampleProtocol::SampleProtocolClientSession<OSI::Transport::Interface::IClientTransportInitializationParameters>, OSI::Transport::Interface::IClientTransportInitializationParameters> tcpTransport(init_parameters);;
SampleProtocol::IncomingPayload< OSI::Transport::Interface::IClientTransportInitializationParameters> request(init_parameters);
request.msg = init_parameters.initialPayload;
std::string ipMsg=init_parameters.ipAddress;
LOGIT1(ipMsg)
tcpTransport.RunClient(init_parameters.ipAddress, request);
I'm biased because I wrote the library.
You can also check for this communication library:
finalmq
This library has the following properties:
C++, cross-platform, async/non-blocking, multiple protocols (TCP, HTTP, mqtt5), multiple encoding formats (json, protobuf). Check the examples.
If a program was written in c++ to run on Windows, does it have to be completely rewritten to run on Mac OS or a mobile OS?
C++ is a standard language, which means that the source code that you write can be compiled on any platform which has an implementation of the C++ standard. There are two ways you can write C++ programs that can't be compiled on different implementation. First, if you use language extensions that are found on a specific (set of)implementation(s) only. Second, using a library that depends on code that doesn't ship with the standard library(like on OS API).
For the first matter, try always to write standard code. For the second, use cross-platform libraries like Boost, Qt...
Typically, yes, because the program will need to use OS-specific features for windowing and possibly for other features as well (networking, synchronization, etc.) However, many programs try to mitigate this as much as possible by building wrapper classes so that most of the program deals with these wrappers rather than the raw platform-specific tools. To port the program from one platform to another, you just need to reimplement the wrappers using the new platform's tools.
Many programs take this a step further by using prewritten libraries like Qt or Boost to handle some of the cross-platform silliness, but this is (essentially) the above idea at a larger scale.
This depends. In general, Standard C++ is a general-purpose, portable language which can be compiled to run on any system or platform that has a standard-compliant compiler.
However, a lot of the more "interesting" features you might want to add to a typical application are not part of Standard C++. This includes GUIs, threads, sockets, and low-level OS API calls. These are generally not portable, and parts of the code which use these features will need to be implemented separately for each operating system or platform.
Fortunately, this is not as daunting as it sounds, because there are a lot of cross-platform libraries in existence that have already gone through the trouble of doing this. For example, the Boost threading library already has threading code written for different platforms or operating systems, but all of this is abstracted behind a nice uniform API that can be used portably in C++ application code.
Additionally, a lot of non-Standard C++ code still conforms to some standard, such as POSIX, which is supported across multiple platforms. For example, most UNIX-ish systems, including Linux and Mac OS X, support POSIX threads (the pthread API).
If the code itself uses libraries that are supported on all the target platforms then you will only need the appropriate compilers to generate a valid binary for each system.
Software can be written in multiple languages and then linked together. For example, I can code the back-end logic of my application in C++ (often using Boost), and then build two separate front-ends in C# for Windows and Objective-C for Mac. I can link the C++ and C# components to ship for one platform, then link the C++ and Objective-C components to ship for another. That approach will give the most "native" look-and-feel for each platform.
As alternative, I can code the entire front-end in C++ using Qt or WxWidgets. This will run on all platforms, albeit without 100% of a platform's bells and whistles.
I need to develop a Windows/Linux command line utility. The utility will talk to middleware that has a standard API on both platforms. I have done some cross-platform development before, on FreeBSD/Linux, which was considerably easier - and I had people in the group with experience that I could talk to.
At this point there is no one in my group who has tackled a Windows/Linux development project. I am looking for advice on how to best set it up. I'm kind of a newbie to C++ too, I have mostly developed C#/.Net GUI applications and Linux device driver level "stuff". Kind of a weird mix.
I was thinking that it would be best to define my own data types and not use either the Linux or the Windows defined types - keep the OS specific code in separate folders and include conditionally. That's kind of what we did for the Linux/BSD work. So it seemed like a good start.
One of the developers here is a big fan of Boost... another thought the TCLAP command line parser library was easier to use... Obviously everything has to be compatible with the licensing.
The code will be open sourced, but it is production code - so I don't want to be sloppy. What else should I be doing or looking for? Are there any best practices out there?
Boost is good, as is ACE. Between the 2 of those they cover pretty much anything you would want to do in a cross-platform manner. I have also gone the route of getting posix libraries for windows and using gcc on cygwin, but I don't recommend it.
Use a portable runtime that is supported on both platforms. I have had good luck with the Apache Portable Runtime.
Use standard C or C++ for most of the project. Only use platform specific functions when necessary. If possible, put those in a wrapper in isolated files so that the build (makefile) can substitute in the correct version for the appropriate platform.
Refrain from using #ifdef LINUX or #ifdef WINDOWS or similar conditional compilation. Those get really hard to debug and there are error prone when the keyword is not supplied to the compiler.
Use Boost. Among other things, you'll get a portable implementation of a subset of TR1, which is worth it if only for <cstdint> and the types within - int32_t etc. As well, shared_ptr is essential for many moderately complicated data structures.
Boost also has a slew of helper types which are extremely convenient in day-to-day C++ tasks. Two specific ones that come to mind right away are optional, and ptr_... polymorphic container types come to mind right away. String algorithm library is also very handy, considering the lack of very commonly needed string functions, such as case conversion or trimming, in the standard library.
Speaking of more heavyweight components, Boost.Filesystem is a very decent cross-platform abstraction for filesystem navigation, also a relatively common task in command-line tools. Then there's Boost.MultiIndex is a swiss army knife of containers - rarely truly needed, but when it is, it's indispensable.
I did a gig this summer in .NET and just ported to Mono. Worked great.
Although there are some good cross platform libraries out there (like Boost), remember that they are probably not there by default. This is especially problematic if you are shipping binaries only. The target platform is unlikely to have the library (or correct version of the library) that you need.
First prize is to stick with standard C++ (even if you need to implement simple stuff yourself). This avoid library dependence altogether.
If you must use a library, try statically linking against it (although this may create big binaries). This will allow you to avoid runtime failure due to lack of binaries.
If you must ship DLLs (or .so on some unixes) make sure that the correct version is shipped with your product and some way to avoid conflicts with the wrong version.
If you are shipping code, include the library with the code and build the library as well as your utility.
Also beware of GPL and possibly LGPL code. If you release a library with a GPL dependency (or modify an LGPL library) you will need to supply the code and allow redistribution as per the GPL.
TCLAP is the only header-only CLI parsing option that I'm aware of. As such, it strikes me as the most portable and is probably your best bet (it's currently what I use and recommend for exactly those reasons). It also helps that the API for TCLAP is very developer friendly and automatically generates decently formatted help messages for you.
Boost program_options has a shard library component to it, which is irritating to maintain ABI with. It also gets around nuisance parsing incompatibilities and behaviors from the getopt family of arguments.
I have used libparamset, that is cross platform (Windows, OS X, Linux) CLI parser. It provides flexible and powerful CLI parser and various UI building features (input error handling, wildcards, typo detection, task resolving, help formatting ...) to build a good command-line tool. It is suitable for both C and C++ projects.
With all the fuss about opensource projects, how come there is still not a strong standard that enables you to make portable code (I mean in C/C++ not Java or C#)
Everyone is kind of making it's own soup.
There are even some third party libs like Apache Portable Runtime.
Yes, there is no standard but libraries like Qt and boost can make your life much easier when you do cross-platform development.
wxwidgets is a great abstraction layer on the native GUI widgets of most window managers.
I think the main reason there isn't any single library anyone agrees on is that everyone's requirements are different. When you want to wrap system libraries you'll often need to make some assumptions about what the use cases will be, unless you want to make the wrapper huge and impossible to work with. I think that might be the main reason there's no single, common cross platform runtime.
For GUI, the reason would be that each platform has its own UI conventions, you can't code one GUI that fits all, you'll simply get one that fits just one or even none at all.
There are many libraries that make cross-platform development easier on their own, but making a complete wrapper for all platforms ends up being either small and highly customized, or massive and completely ridiculous.
Carried to it's logical conclusion, a complete wrapper for all aspects of an operating system becomes an entire virtual runtime. You might as well make your own programming language.
The ADAPTIVE Communication Environment (ACE) is an excellent object oriented framework that provides cross-platform support for all of the low level OS functionality like threading, sockets, mutexes, etc. It runs with a crazy number of compilers and operating systems.
C and C++ as languages are standards languages. If you closely follow their rules when coding (That means not using vendor-specific extensions) you're code should be portable and you should be able to compile it with any modern compiler on any OS.
However C and C++ don't have a GUI library, like Java or C#, however there exist some free or commercial GUI libraries that will allow you to write portable GUI applications.
I think the most populars are Qt (Commercial) and wxWidgets (FOSS). According to wikipedia there is a lot more.
There is also boost, while not a GUI library boost is a really great complement to C++'s STL. In fact some of the boost libraires will be added in the next C++ standard.
If you make sure it compiles cleanly with both GCC and MS VC++, it will be little extra effort to port to somewhere else.