Not at all.  There is no built (compiled/linked for a particular instruction set) language that will give you blanket access to various platforms - unless you do command-line with no GUI (e.g.: most of Linux) or build your own GUI.  Even then, you still need different build environments for  different architectures (Intel, Motorola, Embedded). Once the code runs on an OS and you need OS API access, the codebase will have to cover each and every OS on which it will run (not just DirectX, but each OS has its own OS API for drivers, filesystem, GUI, ports, and so on) with separate builds.

Now, there are some ways to get around this with static/dynamic libraries such as Qt - but that really depends on the nature of the application and how deeply it might need to insert its tentacles into the underlying system architecture.

Also, there are build differences.  I can only support Windows 32-bit, Windows 64-bit, MacOS PPC, and MacOS Universal binary through at minimum three development environments.  You can't build UB code with Visual anything (anywhere - ever).  You can't build Windows applications with XCode (or CodeWarrior unless you have the right version - but since CodeWarrior is now collecting-dust ware, that point is moot).  XCode uses gcc (3 or 4) and lc, but it also gets you the Apple Mac Frameworks, Bundles, and dylibs to be included into the build so that you can do things that require the MacOS API (such as access the filesystem in a non-Posix way).  Same as Visual Studio gives you the libs and dlls to get at the Windows API.

Currently, I'm lucky.  I'm a plugin developer for an application - so I don't have to care about the OS APIs.  But I still need to have a codebase that considers the differences between the build environments and systems - no way around it.  Remember that this is C++ (probably still used more than any other language for application development).

These considerations are one reason that I skipped from C to Java and bypassed C++ back in the day.  Here was the promise of a language that was fast while being completely platform-independent.  That still hasn't been fully realized - not many high-end (or highly optimal) applications written in Java (or Python, Ruby et al).  But it is fully capable for applications with GUI that do real work.

A note on CodeWarrior: although I used it only for MacOS PPC builds, it had build environments for Windows, Linux, Embedded systems, MacOS, and who knows what else.  This was a build environment that tried to be one for many architectural/OS API possibilities.  It is now defunct - sold to an electronics company that only heralds it for the Embedded portion and there will be no more versions.

To this end, this is one thing about Microsoft (and Apple to an extent) that I loathe (although MS had nothing to do with CodeWarrior's demise).  In their buffoon-like rampage to quash anything that is 'ubiquitous' and outside their control (and profit margin), they destroy the best ideas at our disposal.  JScript, J++, C# are all languages that testify to MS's commitment to kill a good technology and make it totally useless (i.e.: their own standards that only work for them and with which everyone else must comply).  Basically anything that MS copies "to make better", I ignore.  Direct3D - I'll stick to OpenGL.  J++ - I'll stick to Java.  Zune - I'll stick to, well, iPod. :)  FrontPage - I'll stick with DreamWeaver.  IIS - I'll stick with Apache (thank you very much).  The list goes on...

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