So, inorder for the program to work for diff platforms (win, mac, linix), i need to compile the program on each OS?
Also, im pretty sure im going to be learning OpenGL pretty soon (maybe in a month), and if i program on a mac, all i need to do make it work for windows, is save to a memory stick, upload on my desktop, and compile the code on winXP, and not have to change 500 lines of coding?
The reason i ask, is that im pretty sure im going to probably get a macbook. [smile]
@ Nytegard:
Im not looking for work in the apple business, im just looking for a laptop to use for music, internet, and program on. Im going to want to program games on it, but i want to make sure that before i buy a mac, that i wont have to learn a lot of new stuff, just to be where i am at right now programming on windows even though i havent learned any graphix API's yet.
Windows vs. Mac Programming!
Well with the new Macs being based on BSD means that Mac programming is basically Unix/Linux programming. And programming on thoes platforms are far more coherent, organized and straight forward that Windows. There are a very wide variety of free libraries with very flexible liscences.
Warning Rrant: And MS has problems with following standards. For example the standard library on Linux has always been ANSI compliant. Microsoft just released an ANSI compliant standard library with the newest visual studio. Hell with Visual Studio 6 their C++ compiler didn't even conform to the C++ standard properly.
Yes you will need to compile for each platform. Though availability of libraries on each system will mean you'll have to use #ifdef _WIN32 to choose between libraries for the appropriate platform.
You can make any program cross compile as long as you have access to the same or similar library on each system. You'll have to get used to using the "wrapper" design pattern where you write a class that wraps around the functionality of each library, abstracting which library is used.
Well sorta ... you'll have to do what I mentioned above unless you go on Windows and install something called Cygwin or Mingw. Thoes will provide you with Unix (remember MacOS is based on Unix) tools compiled for Windows. So you can use the same buld tools and libraries (if available) for both platforms.
Apple laptops are pretty sweet. Thats all I have to say on that point.
Warning Rrant: And MS has problems with following standards. For example the standard library on Linux has always been ANSI compliant. Microsoft just released an ANSI compliant standard library with the newest visual studio. Hell with Visual Studio 6 their C++ compiler didn't even conform to the C++ standard properly.
Quote:
So, inorder for the program to work for diff platforms (win, mac, linix), i need to compile the program on each OS?
Yes you will need to compile for each platform. Though availability of libraries on each system will mean you'll have to use #ifdef _WIN32 to choose between libraries for the appropriate platform.
You can make any program cross compile as long as you have access to the same or similar library on each system. You'll have to get used to using the "wrapper" design pattern where you write a class that wraps around the functionality of each library, abstracting which library is used.
Quote:
Also, im pretty sure im going to be learning OpenGL pretty soon (maybe in a month), and if i program on a mac, all i need to do make it work for windows, is save to a memory stick, upload on my desktop, and compile the code on winXP, and not have to change 500 lines of coding?
Well sorta ... you'll have to do what I mentioned above unless you go on Windows and install something called Cygwin or Mingw. Thoes will provide you with Unix (remember MacOS is based on Unix) tools compiled for Windows. So you can use the same buld tools and libraries (if available) for both platforms.
Quote:
The reason i ask, is that im pretty sure im going to probably get a macbook.
Apple laptops are pretty sweet. Thats all I have to say on that point.
Quote:Original post by fpsgamer
Well with the new Macs being based on BSD means that Mac programming is basically Unix/Linux programming. And programming on thoes platforms are far more coherent, organized and straight forward that Windows.
For example the standard library on Linux has always been ANSI compliant. Microsoft just released an ANSI compliant standard library with the newest visual studio. Hell with Visual Studio 6 their C++ compiler didn't even conform to the C++ standard properly.
So programming on a mac will not give me errors with the code i have now?
Also, what do you mean that it is more coherent? (please give examples, i really want to know b4 i buy a mac)
Quote:Original post by NUCLEAR RABBIT
So, inorder for the program to work for diff platforms (win, mac, linix), i need to compile the program on each OS?
Or at least cross-compile it.
Quote:
Also, im pretty sure im going to be learning OpenGL pretty soon (maybe in a month), and if i program on a mac, all i need to do make it work for windows, is save to a memory stick, upload on my desktop, and compile the code on winXP, and not have to change 500 lines of coding?
The OpenGL extension mechanisms are different on each platform, so you'll have to abstract that much at least. File paths will be different too.
Quote:
The reason i ask, is that im pretty sure im going to probably get a macbook.
The integrated graphics on those isn't the best, maybe you need a pro :)
Win32 is very direct and to the point generally.
VC6 is not a valid criticism because it was released back in 97, b4 the C++ standard was released.
VS2003 was the first attempt at a standards compliant C++ compiler, and VS2003 was the first good attempt. And VS2005 is one of the most standard compliant compilers on the market, rivals GCC and the code generation is much better.
VC6 is not a valid criticism because it was released back in 97, b4 the C++ standard was released.
VS2003 was the first attempt at a standards compliant C++ compiler, and VS2003 was the first good attempt. And VS2005 is one of the most standard compliant compilers on the market, rivals GCC and the code generation is much better.
Quote:Original post by fpsgamer
Well with the new Macs being based on BSD means that Mac programming is basically Unix/Linux programming. And programming on thoes platforms are far more coherent, organized and straight forward that Windows. There are a very wide variety of free libraries with very flexible liscences.
Warning Rrant: And MS has problems with following standards. For example the standard library on Linux has always been ANSI compliant. Microsoft just released an ANSI compliant standard library with the newest visual studio. Hell with Visual Studio 6 their C++ compiler didn't even conform to the C++ standard properly.Quote:
So, inorder for the program to work for diff platforms (win, mac, linix), i need to compile the program on each OS?
Yes you will need to compile for each platform. Though availability of libraries on each system will mean you'll have to use #ifdef _WIN32 to choose between libraries for the appropriate platform.
You can make any program cross compile as long as you have access to the same or similar library on each system. You'll have to get used to using the "wrapper" design pattern where you write a class that wraps around the functionality of each library, abstracting which library is used.Quote:
Also, im pretty sure im going to be learning OpenGL pretty soon (maybe in a month), and if i program on a mac, all i need to do make it work for windows, is save to a memory stick, upload on my desktop, and compile the code on winXP, and not have to change 500 lines of coding?
Well sorta ... you'll have to do what I mentioned above unless you go on Windows and install something called Cygwin or Mingw. Thoes will provide you with Unix (remember MacOS is based on Unix) tools compiled for Windows. So you can use the same buld tools and libraries (if available) for both platforms.Quote:
The reason i ask, is that im pretty sure im going to probably get a macbook.
Apple laptops are pretty sweet. Thats all I have to say on that point.
Basically if you want to get used to doing some system gui programming and how wrappers work then doing the wrapper yourself is a good project, if you want to start doing stuff with least bother then getting a window abstraction layer like SDL is the way to go. SDL mimicks win32 quite a bit in the way it does its calls, just dumbs it down a bit.
If you are learning to program 3d stuff, and want your stuff to work quickly on both platforms download a window layer like SDL or wxWindows etc.
If you are learning to program 3d stuff, and want your stuff to work quickly on both platforms download a window layer like SDL or wxWindows etc.
Quote:Original post by Anonymous Poster
Basically if you want to get used to doing some system gui programming and how wrappers work then doing the wrapper yourself is a good project, if you want to start doing stuff with least bother then getting a window abstraction layer like SDL is the way to go. SDL mimicks win32 quite a bit in the way it does its calls, just dumbs it down a bit.
If you are learning to program 3d stuff, and want your stuff to work quickly on both platforms download a window layer like SDL or wxWindows etc.
im not quite sure what youy mean about wrapper stuff. can someone please show me an example of code that would run on both mac and windows? or even show me an example of what i would have to change for things to work? simple examples such as like:
#include <string>#include <iostream>using namespace std;int main(){ string name; cout << "Whats your name: "; cin >> name; cout << "Hello, " << name << "\n\n"; return 0;}
That example will work. You create it under a C++ Command Line Utility in XCode.
The main thing with this is trying to create things which aren't part of the c++ standard. Such as, how would you create threads? Or how do you manage directories? Or how will you draw graphics or play music?
Just things that we take for granted now, but weren't exactly designed to be part of the language when it was created. At the time, you had different groups deciding their own way to do things, thus, no standardization.
A wrapper is basically something that takes these platform specific pieces of code, and adds another layer ontop of them.
Thus, a simple example.
Mac:
MyLibrary::DawGraphics()
{
MacGraphics.Draw();
}
Win:
MyLibrary::DrawGraphics()
{
WinGraphics.Draw();
}
Unix:
MyLibrary::DrawGraphics()
{
UnixGraphics.Draw();
}
MacGraphics.Draw isn't the same code as WinGraphics.Draw, and neither are the same code as UnixGraphics.Draw(). But I wrote this wrapper for all 3 systems. Thus, someone with a Mac, or Windows, or Unix, downloads MyLibrary. And when they want to draw graphics, they don't call those platform specific pieces of code, they call MyLibrary.Draw(). And because my wrapper is exists on multiple platforms, someone with a Mac can compile & run this same code the way a person on Windows or Unix can.
The main thing with this is trying to create things which aren't part of the c++ standard. Such as, how would you create threads? Or how do you manage directories? Or how will you draw graphics or play music?
Just things that we take for granted now, but weren't exactly designed to be part of the language when it was created. At the time, you had different groups deciding their own way to do things, thus, no standardization.
A wrapper is basically something that takes these platform specific pieces of code, and adds another layer ontop of them.
Thus, a simple example.
Mac:
MyLibrary::DawGraphics()
{
MacGraphics.Draw();
}
Win:
MyLibrary::DrawGraphics()
{
WinGraphics.Draw();
}
Unix:
MyLibrary::DrawGraphics()
{
UnixGraphics.Draw();
}
MacGraphics.Draw isn't the same code as WinGraphics.Draw, and neither are the same code as UnixGraphics.Draw(). But I wrote this wrapper for all 3 systems. Thus, someone with a Mac, or Windows, or Unix, downloads MyLibrary. And when they want to draw graphics, they don't call those platform specific pieces of code, they call MyLibrary.Draw(). And because my wrapper is exists on multiple platforms, someone with a Mac can compile & run this same code the way a person on Windows or Unix can.
I think what everyone means by wrapper is a class. Basically, you avoid doing this within your main program:
If you accomodate for every platform right in line with the rest of you code, you make it at least three times as long, and at least three times as unreadable.
When you make a wrapper, you are hiding this under the hood. You create a class called, oh let's say, "PlatformManager". Then you create a member function called, let's say, "DoWindow()". Now here's what this function would look like:
Now, in your main program, instead of calling the Windows or Mac or Unix API directly, you call your own function when you need to create a window:
So, even though you are still accomodating for all the different platforms, you are now doing it under the hood, and your program is three times as short, and three times as clean. If you release your source code (as well as your platform manager), then your code could be compiled on Windows, and on Mac, and on Unix without having to change a single line of code.
Unfortunately, if you release your output executable file, you won't be able to run the same executable on three different machines. Remember, #ifdef is a preprocessor macro. If whatever you use it on is "defined", then the code between the #ifdef and the #endif is included and compiled; but if it is NOT defined, the compiler ignores it as if it was a comment. Essentially, 2/3 of the code I wrote above won't even be included in the output executable. So this approach does not make your executable file portable, it just makes your code portable.
Now, you can write your own PlatformManager, or you can use an existing one like wxWidgets. I would recommend you use an existing one, since they have been thoroughly tested, and in the case of wxWidgets, it has been more than a decade in production. And of course, if you run into a problem with wxWidgets, there is always a support forum. Unlike if you run into a problem with your own platform manager, then you would have to include it with every question you ask on the forum.
Finally (and my thread totally pwnz yours on this topic), if you want a portable executable, you can use a language such as Java, Python, Perl, and I think you can also use C#. I'm not sure if all .NET languages create portable executables - for example, I don't know about C++.NET
#ifdef __WIN32CreateWindowEx( params... );#endif#ifdef __APPLE__MacCreateWindow( params...); // or whatever the analogous function would be#endif#ifdef UNIXXCreateSimpleWindow( params... );#endif
If you accomodate for every platform right in line with the rest of you code, you make it at least three times as long, and at least three times as unreadable.
When you make a wrapper, you are hiding this under the hood. You create a class called, oh let's say, "PlatformManager". Then you create a member function called, let's say, "DoWindow()". Now here's what this function would look like:
[ReturnType] PlatformManager::DoWindow( params... ){ #ifdef __WIN32 CreateWindowEx( params... ); #endif #ifdef __APPLE__ MacCreateWindow( params...); // or whatever the analogous function would be #endif #ifdef UNIX XCreateSimpleWindow( params... ); #endif}
Now, in your main program, instead of calling the Windows or Mac or Unix API directly, you call your own function when you need to create a window:
#include "PlatformManager.h"...// Create a window regardless of what platform we are usingPlatformManager mgr;mgr.DoWindow( params... );
So, even though you are still accomodating for all the different platforms, you are now doing it under the hood, and your program is three times as short, and three times as clean. If you release your source code (as well as your platform manager), then your code could be compiled on Windows, and on Mac, and on Unix without having to change a single line of code.
Unfortunately, if you release your output executable file, you won't be able to run the same executable on three different machines. Remember, #ifdef is a preprocessor macro. If whatever you use it on is "defined", then the code between the #ifdef and the #endif is included and compiled; but if it is NOT defined, the compiler ignores it as if it was a comment. Essentially, 2/3 of the code I wrote above won't even be included in the output executable. So this approach does not make your executable file portable, it just makes your code portable.
Now, you can write your own PlatformManager, or you can use an existing one like wxWidgets. I would recommend you use an existing one, since they have been thoroughly tested, and in the case of wxWidgets, it has been more than a decade in production. And of course, if you run into a problem with wxWidgets, there is always a support forum. Unlike if you run into a problem with your own platform manager, then you would have to include it with every question you ask on the forum.
Finally (and my thread totally pwnz yours on this topic), if you want a portable executable, you can use a language such as Java, Python, Perl, and I think you can also use C#. I'm not sure if all .NET languages create portable executables - for example, I don't know about C++.NET
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement