C/C++ Is C++ code different on mac and PC

[rshalloo]

I'm about to start a module in C++ programming and I was just wondering if the code I learn in college (on P.C's) will be useable on macs Xcode. As in will I be able to EXACTLY the same code on both?

 

[Tac-Tics]

Platform dependency is a big issue in all areas of software development.

Platform issues typically arise in three ways (listed in order of prevalence):

1) Libraries.

Windowing toolkits, networking, filesystems, even basic input and output depend on the underlying operating system for support. Since most operating systems do pretty much the same thing, this isn't a deal-killer. But every once in a while, you run into problems where some functionality is buggy or just plain undocumented.

2) Vendor-specific compiler options.

This is usually a bigger problem with compiled languages. Especially "standardized" compiled languages. While every vendor agrees on (most of) the spec for the language, they feel the need to add new features to lure in more users.

3) Allowances or ambiguities in the language spec, or failures in the language implementation.

Many languages are spec'ed. Common Lisp, C++, C, Scheme, Haskell, ML, and EcmaScript (Javascript) all have a written document that explains in fine detail how to write a compiler (or interpreter) for the language. The goal is to make all the implementations compatible. They rarely are. Either on the fault of the spec writer or the language implementor, differences in the implementations arise. Those differences become the responsibility of the developers to work around.

 

[phinds]

I agree w/ Tic-Tacs post but would add that his point:

Windowing toolkits, networking, filesystems, even basic input and output depend on the underlying operating system for support. Since most operating systems do pretty much the same thing, this isn't a deal-killer. But every once in a while, you run into problems where some functionality is buggy or just plain undocumented.

is indeed not a deal-killer, BUT that simple statement glosses over the fundamental concept I would point out, which is that programming languages are not JUST languages. The syntax of the language will like have no more than small differences, but the differences in HOW the underlying operating systems do what they do can be quite different and the calls to OS functionality has to be learned independent of whatEVERY language is being used and in that sense, there are really significant differences.

SO ... if you write a = b + c, that will compile just fine under any implementation and any OS, but when you want to open a file or do something more complex by invoking the OS, then there is likely to be significant structural difference in the statements.

Thus, the fundamental LANGUAGE is no different at all, but PROGRAMMING with it can be quite different.

 

[jtbell]

The kind of stuff you do in an introductory C++ programming course is almost certain to be completely portable between MacOS, Windows and Linux. You don't do operating-system specific stuff (graphics, windows, etc.) in those courses. The programs will probably be purely text-based, and use the standard C++ input and output stream operations to read/write to a Windows or MacOS command-line terminal window, or to files.

Under Windows, you might have to use an extra #include directive at the beginning of a program in order to set up the terminal window, which you don't do under MacOS and Linux. If your program otherwise uses the standard C++ libraries, switching between operating systems should be simply a matter of adding or removing that #include.

 

[Ivan92]

It has been my 2nd year using xcode for my C++ class. So far no major problems. However when you learn to open and read from .txt files, you will need to type in the exact location of where the file is at, rather than Windows compilers, where you would just type in the file name(since it expects the file to be in the same folder as the project). So far all good.

 

[MisterX]

Under Windows, you might have to use an extra #include directive at the beginning of a program in order to set up the terminal window

nope

http://msdn.microsoft.com/en-us/library/fcc1zstk.aspx

"If main or wmain is defined for native code... CONSOLE is the default."

I doubt an include is required to have a console application with any other C++ complier/linker/environment for Windows.

It has been my 2nd year using xcode for my C++ class. So far no major problems. However when you learn to open and read from .txt files, you will need to type in the exact location of where the file is at, rather than Windows compilers, where you would just type in the file name(since it expects the file to be in the same folder as the project). So far all good.

All the major PC operating systems support relative paths. You may have had a false idea of what the present working directory was.

 

[jtbell]

Under Windows, you might have to use an extra #include directive at the beginning of a program in order to set up the terminal window

nope

OK, so that's apparently changed since I used to hang out in the comp.lang.c++ Usenet newsgroup, several years ago. I remember seeing lots of people posting programs (that they were asking for help with) that had '#include <conio.h>' at the beginning.

 

[rcgldr]

I remember seeing lots of people posting programs (that they were asking for help with) that had '#include <conio.h>' at the beginning.

<conio.h> is used for functions like _cgets() and _cputs(). Note that Visual Studio (all versions or at least since VS 2005) broke _cgets(). I've read that using the unicode (16 bit wide character) option may fix this bug. I use Visual C 4.0 or 4.1 to compile old 32 bit programs that use these functions, or Visual C 2.2 to compile old 16 bit programs since _cgets() isn't broke in the older compilers.