As long as you're not using any OS specific headers, commands, functions, etc... You're fine.
I'd recommend downloading a virtual machine with a Linux OS, and a Mac OS to test out your software (Or just make friends with people who are on Linux and Mac to program with and test out your stuff but testing it out yourself is the best option. That way you're not dependant on others).
When the compiler compiles the code, it links/incorporates platform dependent library's that are on your computer which handle the behind the scenes stuff that needs to be done for your program to run on a given operating system and machine.
When you compile your code, the resulting executable file will only run on the type of system is was compiled for. This is not avoidable.
You just need to worry about the code being cross platform. That means that you can compile it on any operating system. That means when you use a library that's not part of the standard built in C++ library, you need to make sure it's cross platform.
It is sometimes possible to get certain tools and libraries and set up a compiler so that it can compile a program for a different operating system than your running. This is called cross-compiling. I wouldn't recommend it unless you have to for some reason.
Of course I'm talking about native compiled code like C, C++, etc. There are some other types of languages like Java and C# which are different in that they are designed to not be ran by your system directly, they instead are ran by another program that sits between your system and your program. This way they are able to ( sort of ) achieve "compile once, run anywhere".
Oh yeah, I completely forgot to mention the executable file.
.exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them). Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).) .out is what I use as a replacement to .exe
"Cross platform" software is software that is available on all of the most commonly used operating systems (today, it's Linux, Windows, and Mac; Although google's ChromeOS seems to be trying to weasle it's way in as well).
However, I believe you meant to say "how to write cross-platform code", which is code that compiles on all the most commonly used operating systems without any modification. The compiler is not part of the codebase, and, thus, is not included in this definition. To write cross-platform code, all you have to do is use a cross-platform build system (cmake is pretty popular, and readily available), and modify your code to use cross-platform libraries instead of direct calls to the operating system. While making calls to the operating system's API isn't forbidden, or even bad practice in some situations, it can make it harder to maintain as different operating systems are updated continuously and their APIs change over time.
The Boost library provides cross-platform implementations for a huge set of operating system features: filesystem, ASIO, etc... So it is my primary choice. I'm sure there are other libraries though.
I watched 2 of their videos about it. It's great for people who only use their computer to go on the internet. It just doesn't sound very safe (well, maybe it is because who would bother writing a virus to take out ChromeBooks if only a small percent of the majority use them) or like it can do much else. It's almost pointless.
I'd say it's good for younger kids, but younger kids are more interested in computer apps and games than their Social Media.
Edit: It's good for older folk, like grandparents who just need to check their email.
Oh yeah, I completely forgot to mention the executable file.
.exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them). Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).) .out is what I use as a replacement to .exe
...
Sorry about that haha.
In short
.exe will not work on Mac
.out will work on Mac.
I think either should work on Linux
[quote]
there are so many things wrong with this. first:
[quote].exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them)
.exe is an extension. if i name any file foo.exe on a unix (or unix like) machine, it will execute, as long as it has the executable (+x) flag and has told the os the proper way to execute it. for example:
1 2 3 4 5 6
$ echo "#!/usr/bin/python2.7" >> foo.exe # so foo.exe is a python file
$ echo "print 'Hello, world!\n'' >> foo.exe
$ chmod +x foo.exe # make foo executable
$ ./foo.exe
Hello, world!
$
What you mean is COM/PE (the windows binary executable type) wont execute on Unix/Linux systems, which is only half right. It wont execute natively (like ELF/Mach-O files on linux/mac systems respectively) because they dont come with COM/PE loaders. Programs such as wine (does wine exist on mac? im sure it exists for other unix systems like BSD) allow you to run COM/PE though.
Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).)
on unix (and unix like systems) *almost* everything is a file. not all of those files are neccesarily executable though. only things marked as executable (ie +x the executable flag). this is true of all unix (including mac) and unix like file systems (including linux and the bsd's). also, the point of Linux is that it isnt unix ;). Linux Is Not UNix (coincidence, since Linus didn't come up with Linux).
.out is what I use as a replacement to .exe
no its not.
edit:
thanks to toad, who did my research for me since i had a pissy day at work, wine does in fact exist for mac
Wine exists, and if I really needed to run a .exe I have bootcamp set up so I can switch over to Windows, but without any help from Wine, Bootcamp, etc... You can't run .exe (just like you said, it can't execute natively) that's what I meant.
Little Bobby Tables wrote:
no its not.
Sorry that was really terrible wording on my part. If I'm not using any external libraries, and it's just a plain-jane console application, .out is what I use.
.app is much closer to .exe (but honestly it's such a hassle and most of the time I'm experimenting in console so I'm just not used to .app and even sort of forgot about it).
Apologies on my part for all the false information, and thanks again for correcting me.
on unix (and unix like systems) *almost* everything is a file.
I've used arch linux for almost a year now, and have yet to come accross a filesystem object that isn't a file. I would, however, add that the same is true on Windows, but that it's just implemented differently (and by differently, I mean poorly, and with a few exceptions to the rule). For example, links are "files", so are folders, but external media/hardware is just a mess to deal with and isn't represented as files as in *nix operating systems.
But that's just me being pedantic... Let's get back to the OP.
For example, links are "files", so are folders, but external media/hardware is just a mess to deal with and isn't represented as files as in *nix operating systems.
links are files. not "files" (well im assuming you mean links to other files, ie ln). and external media is treated as a file ;). it is literally a file system. you just have to mount it.
cactus:
for every time you say .exe, replace it with COM/PE. as i showed you, linux can run "exes".
.app is much closer to .exe
do you mean the macintosh Application files? those are not close at all to COM/PE. if anything its closer to JAR.
.app launches the application on Mac like .exe would on Windows, from my understanding. I understand that they function in completely different manners, but I'm talking in terms of what can natively be executed on Mac. (Jar can be executed natively on Mac, but exe can't. So it's not a "replacement" like I had originally said, but the "how-Mac-apps-are-packaged.")
Edit: I was half asleep when I replied, and just reread what you wrote now.
I get what you're saying, and I don't mean to be a nag about it, I'm just sort of trying to explain what I meant (but honestly I need to do my homework on these things and get more savvy with the terminology. I could blame it on being self taught, but I don't like coming up with excuses and that's not even a fair excuse).
Not on windows. On *nix, you can write to a device file to control the device, but on windows, you have to use the api. Devices aren't files on windows.