What problems can there be with cross-platform programming? It is advisable to explain in detail the essence of the problem and a brief solution to it.

Need a problem for research work on the topic "Cross-platform programming", that is, a problem of any type, better that which is well explained

Closed due to the fact that it is necessary to reformulate the question so that it is possible to give an objectively correct answer by the participants Athari , aleksandr barakin , LEQADA , insolor , Suvitruf ♦ 25 December '15 at 23:53 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • More in detail ... Cross-platform concept is loose - you can cross-platform to write under C / C ++ (redefining types via #define), or you can use C # / Java on top of the virtual machine. In general, we need details - Barmaley
  • Need a problem for research work on the topic "Cross-platform programming", that is, a problem of any type, better that which is well explained - Dmitry Alekseevich
  • View the Linux kernel source, the arch folder. There all kitschit cross-platform. - igumnov
  • Are there any problems there? I just need the problem and its solution) - Dmitry Alekseevich
  • 2
    And immediately forget. He is still hell, if you do not use something ready. And then I wrote somehow a class combining WinAPI and XWindow. Good fun came out. - mikelsv

6 answers 6

Cross-platform programming involves programming and you should not interfere with virtual machines here.

As a variant of the problem: to make a program on c ++ cross-platform. There is a certain program under windows which needs to be ported on Linux. For simplicity: the console program. The task is simple in principle, compiled in a new operating system, but when you try to do it, you understand that everything is not so simple. There are no header .h files, some classes are missing, and some functions are also missing. Then it remains to persistently search for solutions for each problem: find analogs of .h files with a description of the necessary functions and write cross-platform functions that, depending on the OS, will call the necessary system functions.

Example: the Sleep(int t) function in Windows pauses at t milliseconds. In Linux, there is only usleep(int t) to which time is transmitted in microseconds. A new feature was written for Linux: void Sleep(unsigned int i){ usleep(i*1000); } void Sleep(unsigned int i){ usleep(i*1000); }

The task of cross-platform to make it work equally on multiple operating systems.

  • The perfect solution, thank you so much. Consider that it was not I who defended the work, but you :) - Dmitry Alekseevich
  • one
    Not only different operating systems, but also different processor architectures - alexlz
  • > In Linux, there is only usleep (int t) to which time is transmitted in microseconds. What kind of nonsense? There is a sleep that gets a second. - skegg
  • @mikillskegg, as waited. The second is very, very long. And sometimes it only takes to stop the program so that it does not load the processor in vain. - mikelsv
  • one
    I like your fantasies. What else is unnecessary to fasten? ) Excessive complication, okay, it would add new features, so no, it does the same thing, but more difficult. That is what I dislike cygwin. - mikelsv

The simplest and lying on the surface is the input-output (stdin / stdout) of Russian letters in windows and * nix. The program should also work correctly when redirecting ( > , < ) to a file (from a file).

Play around for an hour or two and you will have a lot of specific questions.

  • one
    And the close problem of locale and internationalization is skegg

If we mean by cross-platform programming - programming on top of virtual machines, then the main problems are:

  1. The presence of the actual virtual machine under one axis or another.
  2. The physical presence of a virtual machine in a particular station (even if there is a port of a virtual machine for a given axis, its presence is not always guaranteed in a particular case). A related issue is the smooth installation of the virtual machine. Usually, administrative rights to install a virtual machine are required, so the issue of portability sticks to the question of user rights.
  3. The problem of versioning a virtual machine. If the program is written for one version of the virtual machine, it may not work under an earlier version.
  4. The problem of speed of work - with other things being equal, usually a cross-platform application is slower than a native application. Of course, there are ways to solve it, such as JIT compilers, etc., but this still does not solve the problem.
  5. The problem of joining cross-platform applications with native parts. Sometimes, in order to increase the speed of work, some critical parts of the program are written in native codes, when porting, the problem of transferring these parts immediately arises.

Well, something like this.

  • But how can I investigate this or that problem? Suppose if we take the problem of VM and Python versions and try to run the same program under different versions of VM, there will be no errors. Need to use something else? I just think the problem should be chosen more globally. - Dmitry Alekseevich
  • If the program will use VM features of a more recent version, then it will not work under the old VM, or if everything is well sharpened, it will require to install a new version of VM. Try this. - Barmaley
  • Yes, but this is not a problem. She is too easily solved, and I do not think that they will accept this in my work. Can there be any problems with the use of any library or without? Ie, test with the library and without on the Linux and Windows operating systems. - Dmitry Alekseevich
  • "If we mean by cross-platform programming, programming on top of virtual machines ..." Java is not a cross-platform tool. This is a separate platform ((c) I do not remember whose) - alexlz
  • Virtual machine - not at all necessary - Vladimir Gordeev

The problem, for example, is that although languages ​​determine the sizes of variables of different types and the ranges of values ​​that they can accept, they can behave differently on different platforms. For example, the int type when compiling under DOS is 16 bits wide, 32 bits when compiled under win32, and 64 bits when compiled under linux x64.

Then problems can cause different behavior of standard functions. Not to mention that if you need to work with third-party libraries. It may easily turn out that on any particular platform there is no vital function for software operation ...

As noted by @avp , it is very often the problem of localization of programs, and this so that the program works everywhere. This is due to the fact that in different systems their approaches to solving this issue. There are, of course, standard language tools in c ++ for localization, but you cannot call them sufficient ...

  • Dos like everything. And under my int int 32 bits. Not to be confused with long, yes, it becomes 64 bit. I try myself to steer a bit in order to avoid various unexpected problems. Until they think of redoing the char, short, int, and double digits, I’m calm. ) Functions yes. Do not give a couple of examples of standard functions working in different ways? Third-party libraries are a separate song, especially if they are only under one system or are not transferred at all. - mikelsv
  • > Do not give a couple of examples of standard functions working in different ways? readdir () :-) - user6550
  • Hmm, readdir () is only under Linux and I don’t remember that it worked somehow wrong. FindFirstFile () has a different implementation, but it works in the same way. - mikelsv
  • @klopp And working with windows registry under unix-like is not at all in an arc. (By the way, we can recall the recent discussion of peekb) - alexlz
  • I have no idea why you're bringing the picopok here and the registry. Actually, I’m saying that not every standard is implemented everywhere, and even elementary (the same!) Tasks have to be solved everywhere differently. Here is an example of "cross-platform" :-) - user6550

You can also recall the problem of cross-platform GUI.

    The use of non-standard libraries leads to the problem of cross-platform programming. The problem is fixed by installing the necessary libraries, if they are for this platform.

    • @perfect, just installing the missing libraries is not the solution . An example of a solution at the build level from source can be seen when you run configure and the script generates the correct makefile depending on the presence of already installed libraries. A similar approach is possible when running an executable module. It dynamically loads the necessary shared libraries (switching to a more efficient algorithm, if the necessary library is installed). Naturally, the call to functions in this case is indirect, with the address being prefetched by the name of the function. - avp
    • Not all platforms are binary compatible. It is possible that the program will need to be recompiled, if not changing the source code for a specific platform. - gecube
    • Strange, but I always watched if there was a necessary library, for example, under the nix and win platform, and on the basis of this I decided to use it or not. ps For example opengl library - perfect
    • @perfect, this (see if there are libraries for the platform), of course, is also the right approach to the design of the program. There is no familiar library in XYZ - we do not make a program for the XYZ system. - avp