Related
Background: I'm working on porting a large project that was developed in C++ exclusively for unix systems, to be compatible with windows to make way for an eventual windows distribution. I don't have very much experience in Windows development, but I'd like to get whatever I can do, done right, before senior developers move in and take over.
Question: So for a while, I've been looking up Windows versions for all the unix/posix calls that are used in the software, most coming from dirent.h, unistd.h, and some ones under sys, like sys/stat.h or sys/types.h. And although it'll take a lot of work to modify the programs to adopt the new Win32 API calling conventions and return types (and sometimes all new functions), it'll probably work, eventually.
But I've been seeing this come up frequently, the fact that MinGW, I guess, includes many native unix calls and functionalities as part of the GCC environment, and can translate them into windows-compatible calls so you can compile on Windows, and use said compiled program on Windows easily. In fact, one of the similar questions I read in the sidebar talks about just that. What I don't understand, and seem to have trouble understanding, is exactly the extent of this built-in translation functionality, and where I can find a list of system stuff that'll work with this.
Sorry this post is a little unstructured and that I'm so green with this, but I only have 2 weeks to try to accomplish something with this before I get swapped with a senior developer.
No. MinGW does not attempt to implement UNIX functions on Windows. It cannot replicate most system calls with no effort.
However, Cygwin does do that.
I'm not sure the way I'm organising my library is the most elegant way to organise it. I'm mainly concerned about making all the code that I type compile/run for all systems that I'm targeting (keeping it portable), and also keeping it up-to-date for every system.
For example:
I'm not sure using __declspec(dllexport/dllimport) would be used for Mac or Linux. I assume that it's not, but I don't know what the equivalent is for Mac/Linux is. Or another example might be calling specific Operating System functions, which I try to avoid. However, things such as: measuring how long something takes to happen*, in a precise manner, does require me to call OS specific functions.
*as in getting the user's time precisely (down to micro/milli-seconds).
The systems that I am currently (perhaps more in the future) aiming for is Mac, Windows and Linux. But testing that the code compiles (and runs correctly) for every system just seems like a waste of time. As currently, the way I'm proposing to do it, requires me to make a separate project for every system. i.e. I create a Visual Studio Project for Windows, an Xcode project for Mac, and use the command line for Linux or use some other IDE.
Okay, so my main problems with the way I organise things are:
1. Time Consumption, as in creating the projects for all systems and keeping each indiviual project, for each system up-to-date.
2. Knowledge on all IDE's/Compilers that I require to use
Please note, I've never really used* Linux before, I'm thinking about switching. The only problem that I'm concerned about is finding the right tools for me to use with it, and finding the right Distro that would suit me, for what I need. I would really appreciate if someone that is experienced with Linux could guide me, or give me some advice whether to switch or not.
I really like Visual Studio, and it's been my main IDE for quite a while now. I'm just not sure if I want to ditch Visual Studio or not, for Linux; as I don't know if the tools that are available for Linux can do what Visual Studio can or not. What I mean is, it being as user friendly as Visual Studio is. I'm afraid to learn how to use Linux's tools, I'm just not sure if it's worth doing so. Time isn't a major factor on this library, I have plenty of time, I'm fairly young and determined to program as my career in the future.
*I have used it before, but I've never replaced it for Windows.
I am currently hosting all my source code for my project on BitBucket, but at the moment, I only have the RAW code on my repo. There is no project files or any other tool to compile it with, just the code and a readme file. I was thinking of using Makefiles, since they seem popular. But I've never made a Makefile before, don't get me wrong, I am willing to learn. I'm just not really sure where to start. I've heard that people use CMake to create portable libraries, such as SFML and Ogre3D. I've built a couple of libraries with CMake, but I have no clue on how to actually make my own library with it to make my project/make files. Should I learn and incorporate CMake with my library, or is there a better option available?
EDIT:
I'm not aiming to write a library for actual Software that uses a GUI. I'm mainly aimed to write games.
1 - Boost. Boost will help your portability more than you can imagine. Its only real sticking point is, believe it or not, OS X.
2 - Use CMake. It integrates with Visual Studio project files as the build tool, and you can put most of your different-platform compilation voodoo in there.
3 - If you're seriously writing a portable library, consider writing it in C/writing a C wrapper, or making it header-only, or providing the source-code. Making it a shared or statically linkable library does not mean that it will play nice. Name mangling leads to inconsistencies that will blow your mind.
4 - Always be explicit about the number of bits in each variable.
5 - use git. It'll allow you to setup a crappy local server for a repository very easy and get very fast transfers of the kind of huge changes MSVC will make annoyingly
There are a lot more best-practices that can be discussed about cross-platform development. All of that advice isn't applicable in every case; I have a very code-heavy Linux/Windows library that I code almost exclusively in MSVC2k10 and mostly build/test for in Linux, and it is nowhere close to header-only.
EDIT in response to comments:
git was suggested because I find it very easy to use and manage locally. I've use svn before and liked it, I won't really endorse any others, but there are probably plenty of fine ones.
To expound on point 3,
A C wrapper would make it so that anyone anywhere could use your library - FORTRAN developers, Ruby, even Java.
Otherwise you generally have to have similar compiler versions to link properly and it will only link to other C++ code, outside the case of DLLs, and there are still versioning issues. It's one of the stupidest problems in C++ left over, check "name mangling" on Wikipedia. There is a reason widely-used libraries are written in C or have C wrappers, such as libz, openssl etc.
There are other advantages to it. Exception propagation across dynamic libraries is non-existent; with static libraries it can be inconsistent or non-existent.
You'll find that the most widely-used C++ libraries are mostly header-only, like Boost. A header-only library solves many problems by putting all the code directly into a project in a relatively intuitive way, and modern compilers can still optimize away much (but certainly not all) of the extra compile time associated with it.
With all this said, it is certainly possible to do without a C wrapper or header-only, it is just annoying and very troublesome. DLL hell and its Linux equivalents still exist.
You also asked about Boost. That depends. If you're distributing the sourcecode then you certainly must distribute Boost with your code/have people install it. Having people install libraries in order to compile other libraries or use programs is common practice. Think of how specific versions of DirectX come with games for an example.
However if you are distributing binary versions of your library, statically linking against Boost will eliminate any need to include it as long as you are careful to keep Boost headers out of the outward-facing parts of your library. This is where you start seeing things like void * pointers inside C++ headers; an unfortunate side-effect of some of the shortcomings of C++ compilation and library distribution unfortunately.
CMake is a good choice. You can learn to use it. Read a tutorial:
http://www.cmake.org/cmake/help/cmake_tutorial.html
But, if your targets are Linux and Windows only. It is probably OK, in your case (small/average first multi-platform project), to maintain 2 separate build systems.
On Linux, Use Make. It is standard and has a very good reference manual:
http://www.gnu.org/software/make/manual/make.html
On Windows. Use your IDE project file, be it Visual, DevC++ or other. That is the simplest way to go.
Most important, make it easy to test your library/software on different platforms. Install a virtual machine on your desktop. Or at least compile your library into Cygwin.
Once you are here come back on stackoverflow and we will help !
Personally I'd leverage a framework like Qt, because it is quite portable, it does abstract a lot of OS functionality (files, timing, threads, networking), and you get a decent, free IDE (Qt Creator) that is also portable and runs on Windows, OS X and any Unix flavor that runs Qt. It'd give you the lowest barrier to entry. Qt Creator can leverage the Visual Studio compiler and the CDB debugger if they are available.
You do not need to use OpenGL to use Qt, in fact you're not bound to any particular graphics subsystem. Qt only "uses" OpenGL in Qt 5 for the Qt Quick 2 graphics backend. It's not needed for Qt 4, nor for Qt Quick 1 (even in Qt 5!).
You can use any 2D or 3D framework you fancy to push images and other content to the screen. What Qt is good at is creating the kind of 2D imagery that is often needed in games - menus, configuration screens, HUDs, etc. There's a lot of controls and drawing primitives that Qt makes easy to leverage for your purposes.
Qt also lets you use a reasonably powerful model-view and networking frameworks, thus you'd be able to reasonably easily generate server or client lists that update in real time.
There'd need to be a small amount of shim code between Qt and DirectX, of course. On the output side, you typically end up with a QImage in Qt, and then use DirectX, SDL, OpenGL, etc. to push it to the screen. On the input side, you need to call qApp->processEvents() within your main game loop, and you will need to post user input events from DirectX etc. to Qt's event queue using qApp->postEvent(...). This would be only needed if, say, DirectX main loop consumes all Windows messages and won't let standard winapi/win32 code (Qt's windows event dispatcher) see them. I haven't deal with DirectX much, so others feel free to chime in with details, of course.
I'm interning in a company for the summer and I've to look at different ways of looking at the current codebase (C++,MFC, around 100K lines) and using state machines to model the current program.
I've been reading a couple papers and CPP2XMi looks like it may be some use to try to build sequence diagrams as a start.
The end goal is to gauge the feasibility of moving away from microsoft as an O/S and look at development (possibly in another language) on *nix.
I've also started looking at the MFC dependancies to see if we could just port the current C++ code.
I've had the program running through WINE and performance-wise, it seems acceptable but I still need to investigate other solutions as this will only work on X86 while we have other solutions running running on MIPS and ARM.
Any other ideas or caveats I could look at?
The first thing I would look at is where do I use mfc and other non portable stuff. If the only place there is mfc is in the interface layer for example you then can isolate the work.
If there is no such separation I would look at the fesablity of creating some sections of the code that are isolated and portable. Once you have a base of portability you can begin abstracting all of the services rendered by the non portable code. Any way you slice it though MFC to Nix is a big change and will require a significant amount of work. One other possibility is to see if you can run it under a windows emulator.
From reading through the wxWidgets book, it seems very similar to MFC. You might have a look at it.
I would first look into whether the GUI is separated from the rest of the application. With MFC, this includes limiting use of utility classes like CString to GUI-only code.
If the code is well-factored in this way, the easiest thing to do is probably to leave the MFC GUI code alone, and simply build a new GUI for your other platforms using the native GUI library of choice for each new platform. This will give a proper native appearance and behavior to the application that is really difficult to achieve any other way.
If the application logic is intermixed with the GUI code, it's a good time to ask whether you could devote resources to creating a proper separation, with the goal of doing the above once you've achieved separation. This is risky, from a business standpoint, because it can look like you have made a lot of effort and merely ended up back where you started. It isn't until you start work on the new GUI atop the refactored application that your sponsors see any real progress.
You can also look at portable GUI libraries like wxWidgets and Qt.
I have programmed for both MFC and wxWidgets, and they are conceptually very similar. I have never had to port code from one to the other, but I did once port from Borland's OWL to MFC, which was a similar experience. This sort of thing is not particularly difficult; it's just a grind. I can only recommend doing it when you have multiple reasons for dropping the old GUI library. For instance, perhaps you were also thinking of dropping Visual C++ entirely, or switching from Professional to Express, losing access to MFC. If you were planning on sticking with VC++ Professional (or above), it becomes difficult to justify throwing away your MFC GUI.
I once ported a big COM library from MFC to portable code. I used the STL and boost to replace all the MFC bits. For example, CString => std::string and VARIANT => boost::any.
It took forever, but it was mostly straightforward replacement and tweaking. Fortunately it didn't have any gui code-- it was a data processing library.
I am a software engineer and i work in VC++, C++ in WIndows OS.
Are there any major differences when it comes to coding in C++ in Linux environment.
Or is it just some adjustments that we have to make when we need to code in C++ in Linux.
It would depend on the types of projects you've worked on and what native windows APIs you made use of. For example if you used the native Windows API for everything, you're going to have a pretty big task ahead of you, it'd be worth making your project(s) work nicely with Wine instead.
In the Linux environment you have the man pages, quite detailed documentation of almost everything :). As mentioned above, look at POSIX, and while I recommend Qt - it provides a LOT of abstractions for things you might want to learn to do the Linux way (eg sockets, filesystem...)
Use the POSIX API instead of the Win32 API.
Use gtkmm, Qt, or wxWidgets instead of MFC.
Linux programming world is very different from you are familiar with in Windows world. You have to understand it and get used to it. Once you understand you will not want to come back.
You have many small/good tools that works with each other rather then all-in-one MSVC solution. For example:
In Linux you have a compiler as stand-alone tool (Gnu compiler collection), you have build system as stand-alone tool (autotools, CMake). You have GNU Debugger as stand alone tool and you have very good editors as stand alone tool (like hard core vim/emacs).
There are integrated development environments like Eclipse, Netbeans, KDevelop, Anjuta
but still you have to understand how stuff works.
You should understand that each separate tool is very powerful and integrates with others.
OS Level API is designed for simplicity. You'll rarely will find calls like CreateProcessEx with bizzilion parameters rather you have simple fork()+exec(). man is you real friend in all connected to system API and standard C library.
GUI - You have two big GUI libraries Qt/GTK. Qt is great C++ library that makes GUI development enjoyable work (unlike MFC). GTK has both C and C++ APIs GTK and GTKmm (no experience with them).
i18n/l10n/unicode - this is where Linux programming makes life easier. Almost everything is UTF-8. No wide API crap, no issues with opening Chinese file names with simple fopen or ifstream, no 3rd part library that can't open file with Unicode name. Great built in tools available like gettext, and good translation toolkits like KBabel.
Libraries - this is where Linux programming makes you hate Windows. Almost every single free library is already installed or available with simple apt-get or yum install. no debug/release incompatibility crap, no DLL_EXPORT-ing, simple robust, making shared objects is as simple as working with static libraries (and most do not use static libraries at all).
My $0.02
(I'm Linux programmer that have deal a lot with windows development)...
It depends on how many windows-specific things you've been using. The standard part of C++ is the same, but using that will not get you much further than command-line applications.
There's also the whole makefile-instead-of-letting-VS-build-for-you thing. Depending on what tool (or IDE) you decide to use in Linux, that could be a big difference.
I have worked quite a bit on both platforms and like them both, but in general I found most developers to like one and hate the other.
I would describe *nix environment as "geek friendly": many excellent and very flexible tools on your disposal. Some of them introduce hard learning curve, and some are simply broken but still popular for some reason (make) but if you are willing to invest some time in properly learning them, the reward is high. In fact, I use many *nix tools even when working on Windows: vim, grep, perl, etc...
On the other hand, Windows platform offers Win32 API which has way more functionality than POSIX, is very well documented and supported by very good tools. Debuggers on Windows (especially windbg) are generally more powerful that any *nix debugger I have tried, although gdb is generally good enough for most tasks. Deployment of executables is also easier than in Linux world - in fact the only truly reliable way to deploy software on Linux is to ship source code and build it on clients' machines via config/make.
I would suggest to use a Buildsystem like SCons which works very well on both Linux and Win32.
Take a look at the source to some open-source project that runs on both Linux and Windows. Typically, over 80% of the code is identical, and the bigger the project the less the system-specific part tends to be. Unfortunately, there can be hard parts (threading, non-blocking network IO, GUI details) in the system-specific code.
There are some major differences that I can think of:
Tools. Good and bad points. If you are used to Visual Studio, there is nothing quite like that available. Each Linux IDE has some issues. On the other hand, especially debugging tools are very good. But all in all, you are supposed to create your own working environment from what's available.
API's. Documentation varies wildly. Some components are well documented, but often you end up reading the source code to figure out how something is supposed to work. On the other hand, you have source code so eventually you have all the tools possible to figure out why something doesn't work.
The Linux programming community is usually very good as long as you remember to behave and you find the right places. SO isn't half bad in some issues, but sometimes you need to find other places.
Things are not quite as automatic as you might have learned in the Windows world. Yes, some tools allow you to create projects without Makefile knowledge, but really, you should learn how to use them. In Windows it's much more common that you never edit the project files (e.g. Makefiles) by hand.
If you want to work in kernel space (drivers etc) C is a better bet than C++ since the kernel is written with that.
And I agree with people suggesting Qt. Very nice widget set. Beats at least Swing (yes, I know, it's Java) hands down. And Qt Creator isn't half bad.
Don't underestimate the power of shell scripting! Something very few Windows programmers have figured out, but you can do a hell of a lot with them to help your work.
A typical windows programmer who is used to Visual C++ might find the following aspects of Linux C++ programming novel, or difficult:
Linux programming isn't linux programming, it's Unix programming. Unix programming's roots go back a lot further than the MS-DOS roots of Windows, and it shows in a lot of places.
Windows programmers tend to think about the environment, they tend to think about the IDE tools (your GUI editor, compiler, debugger) first. Unix programmers tend to be arranged in various tribes, many core Unix (linux) C++ programmers are very comfortable working from the command line without an IDE, and some, I'm sure, use visual-studio style IDEs on Linux, of which there are many.
I personally found I had to learn how to read (and maybe write) a makefile, build a bunch of standard Linux/Unix applications from source (and understand how to type my way through steps like 'autoconfiguration' and the various "--command-line-options" one might select there), before I get the feel, and the flavour of the environment.
Until you are a seasoned Linux system administrator you might want to stick with the newbie-friendly Linux distributions (like Ubuntu).
It has been a few years since I did any development for PCs (I usually do embedded software).
At that time I was highly proficient with (Borland, now CodeGear) C++ Builder. Time has moved on, C++ Builder has become extremely expensive and there are alternatives (MSVC studio, NetBeans, QtCreator, maybe even Eclipse with the right plugins). Others?
Three things concern me (in no particular order), ease of use, additional GUI components and cross-platformness.
Ease of use - I want an IDE which helps, not hinders me. Good debugger, refactoring, jump to variable declaration, usage, that sort of thing ..
GUI components - when using C++ Builder I was impressed by how easy it was to develop additional VCL components and how many were available, often for free. Thus if I wanted a standard string grid where the cells also could contain pictures, checkboxes, etc, I could probably find one, or roll my own.
I am not sure what the current state of play is with respect to add-on components. Do other systems have anything like http://www.tmssoftware.com/site/ ?
Cross-platform - I personally use Linux for everything, but realistically, the majority of my users have Windows installations. So, cross-platform is "nice to have", "all other things being equal".
Now I have to pick a solution and stick with it for the next few years. Which one, given my points above (cost plays a role, but is not make/break)?
Thanks in advance for your help.
I have used both C++ Builder and Visual Studio.
Over the years I have always preferred C++ Builder over V.S.
Builder and VCL just feels much better designed than Microsoft's products.
(Even the Borland library source code just looks cleaner than anything
that comes out of Microsoft).
The integrated debugger in Builder is truely integrated and quite intuitive to use.
I find Builder compiles much faster than Visual Studio.
Builder 5 had a problem that made it unnecessarily slow,
but at the time it was still faster than VC++
and the latest Builder versions have faster compile times.
Accellerators such as TwineCompile make Builder even faster.
I've never tried to create custom C++ controls for Visual Studio,
but it is fairly easy to do in Builder.
Last year, CodeGear released a free version of TurboExplorer
(I haven't used it myself) which includes the IDE
and RAD (although limited) http://www.turboexplorer.com/
TurboExplorer can be used for commercial apps.
I have not been happy with Java based IDE's where are always slow.
I.e. SunStudio12 which is good (and free) but the UI is slow response.
I use Code:Blocks on Linux which has reasonable usability,
but haven't done any RAD work with it.
I never used C++ Builder but used to be a big fan/user of delphi. I normally work on server apps in c++, with some java. Reciently I started writing some small productivity apps for myself originally I used java, but then moved to Qt.
Now I love it. The library feels well designed just like vcl did in delphi. The signals/slots mechanism is great, I am still surprised how often I don't have to write code to wire up a dialog box. Using qt is easy and the code you write is very easy to read and create. I haven't yet had to write my own widgets, I think qt's model/view architecture splits the roles very well making the stock widgets very powerful. For example when using a QTableView most display and editing functions can be provided by the ItemModel, more powerful control is provided by an ItemDelegate. I have found these easier to reuse than writing custom widgets although it seems easy enough from looking at the documentation.
Qt creator is basic but does 95% of what I require, integrated project, gui designer, code, debug and help. Has support for CMake as well as qmake. It doesn't have advanced features like refactoring, but the intelli sense better than VS2005. However the next version of KDevelop looks very promising and will include these. You could also use eclipse if you wanted these features, or move between eclipse and qt creator as required. But I am very happy with qt creator.
On the cross platform issue, I develop my apps on Linux at home and tend to use them on windows in work. So far everything that works on linux works just work windows and looks like it was written for it too.
The strength of C++ Builder (and also Delphi) is the VCL GUI framework, it is easy to work with, and delivers true RAD development. There are a lot of alternatives to VCL which all have their strengths and weaknesses. The strength of VCL is the close ties with C++Builder/Delphi which makes it work very well with that combination. The downside is that it is propitiatory software, which means that you are unlikely to port your code to other IDE's or platforms without official support from Codegear/Embarcadero.
There is however some free alternatives out there, one of the more interesting being the Lazarus IDE. The Lazarus IDE is an IDE for the Free Pascal language, this is very similar to that of Delphi, I must admit that I am not a Delphi guy myself, so I am unable to go into too much detail about this. Lazarus have a GUI framework much like VCL called LCL. From the brief looks I've had on it, it looks very similar. There are several good things about the Lazarus/Freepascal package especially for your case. It is free, it can compile and build for both windows, linux, and mac, it has 64 bit support. Further more the compiler seems more modern than the Delphi one.
Lazarus running on Windows 7
Lazarus running on Linux (GTK2)
Lazarus running on Mac OSX
More screenshots can be found here: http://wiki.lazarus.freepascal.org/Screenshots
The problem with Delphi/C++Builder is that the VCL is not currently crossplatform capable. Although this is planned for future versions (as far as I recall) it is not yet implemented. Having noted that, there are some considerations as to whether the C++Builder will continue to be maintained or not, in here there is some comments on this: here.
Qt has been mentioned and it is indeed a very strong GUI framework and the Qt creator is a fine tool, personally though I like to have a very close bond between the IDE and the GUI framework like it is the case with the VCL, but that is very dependent on the developer.
Edit: Just a thought I had, when comparing C++Builder to other RAD IDE's it is easy to include IDE's for the .NET languages and Java. These use languages created for this purpose. C++ used in C++ Builder does, although in Borlands version slightly modified, not. This does raise an interesting question, is using C++ for RAD applications necessary and justifiable? Why not use a tool (language) that is written for the purpose. I am aware that C++ Builder is written for RAD development, but the language behind it was not designed for this purpose. If your need is truly rapidly developed applications, I would consider looking for other languages, but if you dependent on C++ for whatever reason, could be 3rd party libraries etc. Then C++ Builder is in the C++ world an excellent RAD development platform.
Short answer is NetBeans. It is cross platform, it is easy to use, although it is made-in-java but still it is fast.
PS: If you also do or intend-to-do programming in java, it will be convenient to use/learn this one IDE for both.
You can also use wxForms for C++ Builder and use wxWidgets to create cross platform applications. It works with the existing C++Builder IDE and make use of the same form designer.