Non-portable C++ for Beginners

[S6k9GNh0]

So, I've been holding my tongue when people mention non-portable methods of accomplishing things on the Beginners and General C++ Programming forums. My issue is that C++ is a portable language while their methods are not, which I think may degrade the quality of new programmers only because they don't know of the alternatives. I've found that most people who use the WinAPI directly do so only because they aren't actually aware of the alternatives (although I have nothing to prove this other than my word which may be partially biased). I don't even use *nix-based libraries directly if I can help it (which I've always successfully accomplished).

I find *nix programmers to be quite a bit more open minded when it comes to such solutions as well. Win programmers tend to have the mindset of "I don't use anything but Windows so I don't really care" while *nix programmers tend to have the mindset of "I don't know what the user is using so I'll support everything I can as long as it doesn't bother me". For instance, someone recently wanted to poll for key events. A veteran member of the forum asked him to use "GetAsyncKeyState" from the WinAPI when SDL, SFML, and several others provide cross-platform solutions to the same problem, possibly in a more convenient and safer manner (abstraction of strange behaviors). If that person actually ends up making viable software, it will clearly be Windows based simply because that's how he was taught. Isn't that irresponsible?

[chrisname]

I generally avoid Windows-only stuff, but I use POSIX functions because I know that if I compile with Cygwin or MinGW it'll work on Windows anyway.

The exception to my no-Windows-only-stuff policy is when I'm writing a program that will never need to be run on a non-Windows OS. A current example is my Skyrim launcher. Skyrim can only run on Windows, so there's no need for my launcher to run on other operating systems. Therefore I took the easiest option and used Visual C# Studio's GUI designer to make the GUI.

[maeriden]

IMO one shouldn't provide advice which relies on platform-dependent solutions unless specifically asked for because it limits the helpfulness of the solution.
But on the other hand, if one has the will the improve himself he will start out with the limited solution and then find a better one as he gets more experienced. Unless he intends to target only a specific platform, in which case there is nothing much that advice can do

[3hM2Nwbp]

Platform dependent code isn't a problem if:

A) It's clearly labeled as such
B) The translation unit is protected by preprocessor conditionals.
C) Said code doesn't employ hungarian notation.

The most important point is C, clearly...

[NGen]

I'd say that non-portable methods are acceptable when the development allows it. Unless you're consciously thinking of what your target platforms are, whether or not you use non-portable methods is irrelevant because, in the end, whether or not it's portable will most likely not make a difference anyway. It's not something that is intended to be portable or it isn't something that's important enough where portability is an issue.

In the example of GetAsyncKeyState, the person asking for help would have then had the option of simply calling the GetAsyncKeyState function, or importing an entire library/upending their current code to implement code that would make use of SDL/SFML. Cross-platform compatibility isn't something that I disagree with, but it can be a relative hassle. The GetAsyncKeyState was an unfortunately good example for not using a cross-platform solution, but as with all things, it's a best-tool-for-the-job situation.

tl;dr it's an issue of ease-of-use in programming vs cross-platform compatibility.

[cire]

Why hold your tongue? Chip in with your own advice.

[htirwin]

Unless you're consciously thinking of what your target platforms are, whether or not you use non-portable methods is irrelevant because, in the end, whether or not it's portable will most likely not make a difference anyway.

Most programmers, or at least beginners, are making toy programs, practice programs, or crappy irrelevant software which can't compete with what's already out there. In this case, it doesn't really make much of a difference who can use it, because nobody wants to use it anyways.

If your software is good, and people want to use it, then there is a big difference wether or not people can use. And even if it is good, in some cases, many people will not use it because it is platform dependent, even if they primarily use that platform.

Even if your just writing practice programs, you might as well get used to writing platform independent code; to prepare for the day you might write something valuable.

[Disch]

A veteran member of the forum asked him to use "GetAsyncKeyState" from the WinAPI when SDL, SFML, and several others provide cross-platform solutions to the same problem

There's the practicality factor, as well.

If someone is making a dopey console program that will never see the light of day, and they just want to check realtime status of a key... GetAsyncKeyState is the simplest option. Yes, SDL and SFML can do it too, but they add additional dependencies and are significantly more work for a beginner to set up just to do something basic.


So IMO it's not really practical to recommend crossplatform solutions in many of these cases. Though I share your general sentiment that platform-specific code should be avoided when teaching newbies.

I solve this problem by simply not responding to those threads. Dopey console programs are a waste of time IMO anyway. Though that probably isn't a very good solution either.

[chrisname]

You guys are thinking of the short term pros and cons, though. There's more to be gained from learning to do something the cross-platform way, even if the initial investment of time is greater.

[Disch]

That's my mentality, as well, which is why I used to try to steer people away from the console. But a lot of people got on my case about that so I just stopped replying to those threads.

[z05DSL3A]

...and if your cross-platform library of choice doesn't do what you want?

[S6k9GNh0]

Then it's not an alternative in the first place. It doesn't make sense to use a library for functionality that doesn't do what you want in the first place.

Grey Wolf, I'm not really sure what you're getting at but that mentality almost seems like you're underestimating what can be abstracted to provide a universal API.

[z05DSL3A]

What I'm getting at? Have you never decided on a library to find that at some point you need to extend it? When one of the platforms introduces a new feature...You either wait for the library to be updated or you extend it yourself. To extend it you have to have a good understanding of the library and the platforms that you are targeting. So I guess my point is that I see it as top down verses bottom up learning...I personally prefer bottom up learning.

I will also admit that I prefer cross-platform data and logic with native UI.

[S6k9GNh0]

Grey Wolf, not really. A lot of C libraries leave some of the implementation to you and simply provide bare necessities (libevent and variants) and most of the libraries I rely on are mature to the point of being considered a standard (such as Boost libraries, SDL, or similar). Although, to be fair, I've not really developed anything in a specialized field as of yet.