4 ms·

The worst gift #ifdef gives to the world is processor specific code paths. You should really be using conditionals in your make file to select source code file

The worst gift #ifdef gives to the world is processor specific code paths. You should really be using conditionals in your make file to select source code files. It is easier to test, easier to debug and you can have a portable fallback. Plan9 uses this method, which is why porting to a new architecture is orders of magnitude simpler than other software platforms. There is no #ifdef hell to work your way through. For instance, plan9's lib C http://plan9.bell-labs.com/sources/plan9/sys/src/libc/ http://plan9.bell-labs.com/sources/plan9/sys/src/libc/ You can choose which functions you would like to hand code and test them against portable C versions with the flick of an environment variable. tl;dr put your logic where it belongs

dllthomas 13y ago
There's also the web (literate programming) approach of "change files".
sillysaurus3 13y ago
There is no such capability on Windows as a GNU makefile. There is nmake, but it's substantially different. Please don't do this. It will make your code much harder to port. So almost every gamedev will be harmed by this.
- mschuster91 13y ago
  Actually you can do the following (example is a hypothetical memory allocator implemented at least partially in asm): 1) create a "meta header file" malloc.h, containing the function prototypes. 2) create a "meta source file" malloc.cpp, with #ifdef switches for e.g. x86, x86_64, arm, etc, and inside the ifdefs some #include "malloc_x86.cpp" 3) inside the malloc_x.cpp source files, implement your architecture-specific asm code. 4) if you're after portable code, just do a #else #include "malloc_c.cpp" with a pure-c/cpp implementation. This way everyone can use the malloc and those with matching CPUs can benefit from acceleration.
- SixSigma 13y ago
  GNU make, that's the last thing I would recommend!
  - sillysaurus3 13y ago
    You should really be using conditionals in your make file to select source code files. If you start moving your programming logic (even compiletime logic) into any kind of makefile, you make life much harder for gamedevs, because it becomes harder to port your code to Windows. If you care about open source, then this is less inclusive a way to write code. You'll be excluding a segment of your programming community (gamedevs) because they're forced by the nature of the industry to compile their code on Windows. That's changing, but it's changing slowly. In the meantime, some people don't care about that, but it would be nice to get some sympathy when it's so easy to write the code in a way that can include more groups of programmers, which is what open source is all about.
    - dllthomas 13y ago
      The gamedevs I have worked with use cross-platform makefiles (CMake, IIRC, but it's been a while) for their builds.
      - sillysaurus3 13y ago
        CMake is pretty awesome. If that's what they were recommending, then I apologize. It sounded like they were talking about standard make though. Does plan9 use CMake?
        dllthomas 13y ago
        I doubt plan9 uses cmake, though one could presumably use cmake on plan9. The general point they were making was "use your tooling to build different files, rather than different versions of the same file." Nit-picking at particular tools misses the point. Building it that way means you just need to pick a compatible set of source files and build them. Writing your code with a bunch of #ifdefs set up with autotools is going to be harder to get working on Windows not easier.

dllthomas 13y ago

There's also the web (literate programming) approach of "change files".

sillysaurus3 13y ago

There is no such capability on Windows as a GNU makefile. There is nmake, but it's substantially different. Please don't do this. It will make your code much harder to port. So almost every gamedev will be harmed by this.

mschuster91 13y ago
Actually you can do the following (example is a hypothetical memory allocator implemented at least partially in asm): 1) create a "meta header file" malloc.h, containing the function prototypes. 2) create a "meta source file" malloc.cpp, with #ifdef switches for e.g. x86, x86_64, arm, etc, and inside the ifdefs some #include "malloc_x86.cpp" 3) inside the malloc_x.cpp source files, implement your architecture-specific asm code. 4) if you're after portable code, just do a #else #include "malloc_c.cpp" with a pure-c/cpp implementation. This way everyone can use the malloc and those with matching CPUs can benefit from acceleration.
SixSigma 13y ago
GNU make, that's the last thing I would recommend!
- sillysaurus3 13y ago
  You should really be using conditionals in your make file to select source code files. If you start moving your programming logic (even compiletime logic) into any kind of makefile, you make life much harder for gamedevs, because it becomes harder to port your code to Windows. If you care about open source, then this is less inclusive a way to write code. You'll be excluding a segment of your programming community (gamedevs) because they're forced by the nature of the industry to compile their code on Windows. That's changing, but it's changing slowly. In the meantime, some people don't care about that, but it would be nice to get some sympathy when it's so easy to write the code in a way that can include more groups of programmers, which is what open source is all about.
  - dllthomas 13y ago
    The gamedevs I have worked with use cross-platform makefiles (CMake, IIRC, but it's been a while) for their builds.
    - sillysaurus3 13y ago
      CMake is pretty awesome. If that's what they were recommending, then I apologize. It sounded like they were talking about standard make though. Does plan9 use CMake?
      - dllthomas 13y ago
        I doubt plan9 uses cmake, though one could presumably use cmake on plan9. The general point they were making was "use your tooling to build different files, rather than different versions of the same file." Nit-picking at particular tools misses the point. Building it that way means you just need to pick a compatible set of source files and build them. Writing your code with a bunch of #ifdefs set up with autotools is going to be harder to get working on Windows not easier.