C++ Programming For Linux AND Windows?
Can programs be made in C++ and compiled for Linux and Windows, even if it is compiled differently for Windows, can the same C++ code be used?
|
Not easily. Platforms are very different. To do this, you have to stick with ANSI C++ and avoid any system calls. If you want to use a graphical UI, you need to stick with a UI that is available on both platforms, such as gtk-widgets.
Console apps that don't deal with the system can do it (although anything involving a directory gets into issues with forward slash vs backslash), but if you get more complicated it gets hard. |
Moved: This thread is more suitable in the Programming Forum and has been moved accordingly to help your thread/question get the exposure it deserves.
|
For all your cross-platform C++ needs (use it with gcc
in Linux, and mingw or VC++ on windows). http://www.trolltech.com/products/qt Cheers, Tink |
Quote:
|
Yes.
My game programming tutorials prove that. You just have to use a cross platform library API like SDL, OpenGL, HawkNL, wxWidgets, etc. |
It depends on the code. As stated above, if you're using operating system-specific function calls, no. But there exist application development frameworks which implement common APIs on both platforms. There are some alternatives, and quite a few different ones with different emphasis:
QT. Excellent general purpose application development framework. They claim porting from one platform to another is as easy as re-building. I think it's a superb API. Well thought out, powerful etc. You can also flip a switch and have your app display in a style which looks native on each windowing system. QT is the underlying API for the KDE desktop environment. wxwindows is "MFC, but done right". Personally I find wx apps on Linux to feel odd and clunky. The window borders draw funny under KDE, window resizing is not fast and so on, but that might just be a bad use of the API in the apps in which I've noticed it used. GTK. The big rival to QT on Linux. It's a C API, but there's a C++ interface called gtkmm. GTK is the underlying API of the gnome environment. I belileve it was originally coded for The GIMP. I have heard that porting apps to Windows using GTK is a more difficult than with QT. I never used it apart from on Linux. It's nice. SDL is not so general purpose. It's more for game-like apps. There are SDL components for doing graphics, audio, font handling, image file format handling etc. There's no GUI toolkit in SDL, it's rather lower level than that, but there are some GUI toolkits which run on top of it, like CEGUI. SDL is nice. One of the projects I am involved in, Stellarium, uses SDL as the underlying API. To get program to compile cross platform, you need to do a fair few #ifdefs, but it works. Ogre3D is a more fully fledged game API. It's much heavier than SDL, but contains some amazing functionality for game devs. The list goes on. I'm only mentioning the ones I've looked at personally. |
There's also FLTK.
|
I was just wondering how some programs are made for single operating systems and the developers find it hard to produce programs for a range of operating systems. I saw how some programs are available for each version of mac, Linux, Unix and windows, this is rare but i didn't think they would have to reprogram something for a different operating system.
|
I think the main thing is to start a project with portability in mind, and choose libraries with this in mind. Many apps start with only one platform in mind, become successful and then have massive trouble porting because they basically have to re-write the whole thing for the new platforms.
A common example would be someone writing a program in MFC on Windows, and then finding out that 30% of their target market has moved to the Mac.... if they want to get that 30% of the market they need to re-write their program. The cost of porting from scratch late in an application's life-cycle is high. Assuring consistent behaviour between separate code-cases is difficult. Worse, maintaining two separate code-bases significantly increases the cost of development of new features, and bugfixes. All this cost can be effectively eliminated by choosing a good cross platform API at the start of the project. There are some costs associated with choosing a cross platform API over the native API. The most obvious for most developers is learning a new API if the developer doesn't already know it. These frameworks are large and complex, and can require significant effort to learn well. Another potential cost is the loss of OS-specific features. The cross platform APIs may not implement OS integration as completely as native APIs. Lastly, the resulting API may not look native (e.g. audacity on Linux looks "weird"). This can put users off using the application. |
Quote:
|
I have a program that I took some minor pains to ensure it was portable and did not call anything from windows.h or and winapi etc.al (sdl & opengl are pretty good for that)
I use Visual Studio .NET 2003 and have the other free VS on another computer. Is it possible to compile through VS for Linux? I do not have very high hopes that this is even possible, but I might be surprised. Now that I have met all of the obstacles mentioned above regarding OS specific calls: What can I use to compile on windows so it can run on linux? What should I download?? |
There is no VS for Linux. If you want to do compiler portability, that's great, but if all you really care about is platform portability, mingw is your friend.
I don't think there is any way for windows to cross-compile for linux. |
You could use premake to generate makefiles and vs projects, or you could use Codeblocks which is a cross platfrom IDE.
If you don't have a linux box and use premake you can then compile with the help of Cygwin(which makes a windows executable from linux source, requires more packages to do this), or you install VMware or VirtualPC and create a linux install on a windows partition or just create a linux partition on your box. |
Quote:
(i didn't realize you were on LQ) I have been having a go at some of these at work on XP (when the boss isn't looking), and they work great both at work and on my Linux box at home. Good stuff. |
All times are GMT -5. The time now is 06:18 AM. |