Answer the question
In order to leave comments, you need to log in
What prevents writing cross-platform applications in C ++?
Please tell me what makes it difficult to write cross-platform applications in C ++, because, as a result, there are so few editions for different operating systems, it seems that when compiling, the linker adds the specified loader to the code, is it really difficult to compile for different platforms, or code for different OS somehow fundamentally different from each other in a special way?
PS I was not lucky enough to go to the institute as lucky ones, so you have to ask on the Internet (which of course you should do there), like all normal people. Maybe this is a lack of plug-in libraries, some kind of API, different variables of the data storage area, maybe the language constructs are not designed for this and all that. Or is it impossible to give an unambiguous answer to this question and is it subject to immediate removal?
Answer the question
In order to leave comments, you need to log in
Yes, as it were, nothing prevents you from writing one C ++ code for many platforms. Almost all of my work experience is connected with the development of cross-platform games. I have worked with several (homemade and not so) engines and have my own brainchild, perfectly and uniquely going to 5 target platforms (Win, Mac, Linux, ios, Android), to which consoles and new platforms can be easily added.
No, I'm lying, not without difficulty. You will have to sweat over the layer of abstraction. But you will only have to sweat over it, everything else will start by itself, because. originally written in the C++ standard, without extensions for specific compilers, and using a number of approaches that are very important for cross-platform.
Cross-platform means solving a number of issues that result in an abstraction layer above the operating system. These questions are often left unanswered. I met this myself several times and they also told me about how this or that engine was first only for a specific ###, and then they decided to port it to @@@. It turned out that the compiler, which was always used to build the engine, was stuffed with language extensions, which, of course, everyone used 100%, and when changing the compiler, not a single source file was left without a good hundred errors. Those. EVERYTHING had to be rewritten .
Mercury13 did a good job of covering Unicode file paths. Drakonoved correctly noticed about file path separators. Maxim Grishinvery well reminded of the byte order. This is all part of this series of questions.
Each platform has its own API, which will not be available on another platform. But another platform will have its own API, with its own names and similar functionality. And work with the API must be abstracted from the universal code.
Also, on one platform you might have an open-loop main message loop (Win) and a closed loop on another (Android). We have to adjust. The GUI is different everywhere, you have to adapt. The very structure of the application on one platform can be monolithic, and on another - composite. Graphic and sound APIs can be cross-platform, but this does not add to their ease of use. The initialization will still be platform-specific.
In fact, even within the framework of working on one platform, a number of rules must be observed in order to be able to get both a 32-bit application and a 64-bit one from the same code. This is well written on the website of the PVS-Studio developers.
And all this is solved. In part - with the help of architectural techniques. I already showed one of these in my other answer .
And yet these questions can not be solved.
DoubleGIS, for example, has long been based on Qt, which greatly simplifies their cross-platform life. Qt solves a number of cross-platform issues.
What does not give
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question