I said it depends.  You can segregate, but that just makes 'porting easier' - but it doesn't make it non-descript.  You still need to consider the OS-specifics (architecture specifics, filesystem specifics) in a separate module/lib/dynamiclib/etc.
I mentioned Qt (didn't I - you can double check that). :P  Yes, I agree and was saying this, but there are other things to consider.  Unless you expect people to play by specific rules, current filesystems can handle much more than Posix path structures (I've specifically run into this with MacOSX and zlib - where zlib uses fopen()).  The problem is that MacOSX and Windows allow Unicode folder/file naming.  fopen() doesn't - of this I am 1000% certain - been using fopen() since, hmmm, before some of you (gen.) were born (in the original C libs).  There are variants like Microsoft's _wfopen() but these are platform-dependent (not good) and not part of the standard.  Don't know if fstream has been updated since then, but then zlib doesn't use fstream without some third-party wrapper.

Both D|S and I have to contend with, speaking of legacy, something from Poser - MacOS Resources.  Poser still uses them - although they are basically legacy that doesn't mean that they don't exist.  I assure you that they are still alive and well on my Mac in Poser 4/PP.  Handling them using CodeWarrior and the 'old' Mac API (ala Carbon for MacOSX) was relatively simple.   Handling them using Xcode in the new Mac API is very frustrating - as Resources are 'shunned' (no longer supported) in favor of Bundles.

Again, it all depends on what your application needs to do.  Mine needs to dig its tentacles into the OS API here unfortunately.  :) I have no idea how D|S handles them - if it even does or if it preprocesses them out to .rsr or .png.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone