views:

357

answers:

5

This is my first-attempt at writing anything even slightly complicated in C++, I'm attempting to build a shared library that I can interface with from Objective-C, and .NET apps (ok, that part comes later...)

The code I have is -

#ifdef TARGET_OS_MAC
  // Mac Includes Here
#endif

#ifdef __linux__
  // Windows Includes Here
  #error Can't be compiled on Linux yet
#endif

#ifdef _WIN32 || _WIN64
  // Windows Includes Here
  #error Can't be compiled on Windows yet
#endif

#include <iostream>

using namespace std;

bool probe(){
  #ifdef TARGET_OS_MAC
    return probe_macosx();
  #endif
  #ifdef __linux__
    return probe_linux();
  #endif
  #ifdef _WIN32 || _WIN64
    return probe_win();
  #endif
}

bool probe_win(){
  // Windows Probe Code Here
  return true;
}

int main(){

  return 1;
}

I have a compiler warning, simply untitled: In function ‘bool probe()’:untitled:29: warning: control reaches end of non-void function - but I'd also really appreciate any information or resources people could suggest for how to write this kind of code better....

+1  A: 

It seems none of TARGET_OS_MAC, __linux__, _WIN32 or _WIN64 is defined at the time you compile your code.

So its like your code was:

bool probe(){
}

That's why the compiler complains about reaching the end of a non-void function. There is no return clause.


Also, for the more general question, here are my guidelines when developping multi-platform/architecure software/libraries:

Avoid specific cases. Try to write code that is OS-agnostic.

When dealing with system specific stuff, try to wrap things into "opaque" classes. As an example, if you are dealing with files (different APIs on Linux and Windows), try to create a File class that will embed all the logic and provide a common interface, whatever the operating system. If some feature is not available on one of the OS, deal with it: if the feature makes no sense for a specific OS, it's often fine to do nothing at all.

In short: the less #ifdef the better. And no matter how portable your code is, test it on every platform before releasing it.

Good luck ;)

ereOn
Thanks very much… I gave the `right` answer to someone who helped me on IRC (Roger) but that's good advice, as ever.
Beaks
@Beaks: No problem ;) Glad you got the answers to your questions.
ereOn
+1  A: 

The warning is because if none of the defines are actually defined then you have no return in your probe function. The fix for that is put in a default return.

Tristan
+4  A: 

I'll address this specific function:

bool probe() {
#ifdef TARGET_OS_MAC
  return probe_macosx();
#elif defined __linux__
  return probe_linux();
#elif defined _WIN32 || defined _WIN64
  return probe_win();
#else
#error "unknown platform"
#endif
}

Writing it this way, as a chain of if-elif-else, eliminates the error because it's impossible to compile without either a valid return statement or hitting the #error.

(I believe WIN32 is defined for both 32- and 64-bit Windows, but I couldn't tell you definitively without looking it up. That would simplify the code.)


Unfortunately, you can't use #ifdef _WIN32 || _WIN64: see http://codepad.org/3PArXCxo for a sample error message. You can use the special preprocessing-only defined operator, as I did above.


Regarding splitting up platforms according to functions or entire files (as suggested), you may or may not want to do that. It's going to depend on details of your code, such as how much is shared between platforms and what you (or your team) find best to keep functionality in sync, among other issues.

Furthermore, you should handle platform selection in your build system, but this doesn't mean you can't use the preprocessor: use macros conditionally defined (by the makefile or build system) for each platform. In fact, this is the often the most practical solution with templates and inline functions, which makes it more flexible than trying to eliminate the preprocessor. It combines well with the whole-file approach, so you still use that where appropriate.

You might want to have a single config header which translates all the various compiler- and platform-specific macros into well-known and understood macros that you control. Or you could add -DBEAKS_PLAT_LINUX to your compiler command line—through your build system—to define that macro (remember to use a prefix for macro names).

Roger Pate
You are correct on the WIN32 define ...
Goz
+11  A: 

instead of repeating yourself and writing the same #ifdef .... lines again, again, and again, you're maybe better of declaring the probe() method in a header, and providing three different source files, one for each platform. This also has the benefit that if you add a platform you do not have to modify all of your existing sources, but just add new files. Use your build system to select the appropriate source file.

Example structure:

include/probe.h
src/arch/win32/probe.cpp
src/arch/linux/probe.cpp
src/arch/mac/probe.cpp

The warning is because probe() doesn't return a value. In other words, none of the three #ifdefs matches.

stijn
Hear, hear! (1) This adds clarity to your code, (2) reduces mental effort to read it for someone who's only familiar with only one platform, (3) doesn't depend on arcane non-portable compiler/platform-specific flags.
Alex B
This. Also don't rely on compiler-defined platform macros, make your build system define your own.
PiotrLegnica
I know it has its uses, but IMHO the preprocessor should be dropped and this is how all cross-platform coding should be done.
T.E.D.
Amen! Platform-specific code is best managed by the build system - not the C++ preprocessor.
Nemanja Trifunovic
It also allows code which can only parse/compile on one of the platforms - say if probe_win uses some MSVC specific function/compiler flag/preproc declaration that doesn't exist on gcc
Martin Beckett
@Martin: for functions, compiler flags, and #pragmas, that's not an issue: the preprocessor strips away function calls inside #if...#endif, flags are specified on the command line anyway, and unknown #pragmas are required to be ignored. Are there other CPP directives in common use that pose a problem?
Roger Pate
@ Roger Pate - yes if you are careful everything can be escaped by #ifdef (except possibly "#pragma once" has to be at the top of the file?) but it's a lot easier not to have to worry about it.
Martin Beckett
A: 

To add something more to this, other than the outstanding options above, the directives __linux__ and _WIN32 are known to the compiler, where the TARGET_OS_MAC directive was not, this can be resolved by using __apple__. Source: http://www.winehq.org/pipermail/wine-patches/2003-July/006906.html

Beaks