CPP - Convert source code from Windows to Linux [closed] - c++

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a single-file CPP app, built for Windows and is running in command line only.
I am trying to make it compilable also for Linux.
The only libraries the app is using are:
#include <iostream>
#include "setjmp.h"
#include "windows.h"
#include "time.h"
It also uses all kinds of unsigned integers (uint8, uint16, uint32, uint64).
Other than this there aren't any other Windows-specific APIs.
My question is how to convert the code so it will be compatible with Linux?
Is there an easy way to do this?

Do it the other way round. Code, probably using some cross-platform framework like Poco or Qt (which is also usable in non-GUI code, e.g. using QtCore without QtGui), or Boost, in some Windows independent way and compile it regularly on both OSes.
BTW setjmp.h is C++ unfriendly (messing and incompatible with C++ exceptions), even on Windows.
So remove
#include "setjmp.h" /// wrong in all C++ programs
#include "windows.h" //// specific to Windows
then fix the code (e.g. all compilation errors; but on Linux compile with all warnin & debug info, e.g. with g++ -Wall -Wextra -g), probably using some framework like the ones I mentioned.
Don't convert C++ code (from Windows to Linux) but do try hard to write portable C++ code, thanks to some well chosen framework.
Perhaps your application could be written in some pure portable C++11 (but then, no need to #include "windows.h"). Command-line utilities like wc, cat, grep (with a subset of all features) could probably be written in portable C++11 -and might not even require any additional framework.
PS. Without having your source code and without any idea about what that application is, it is impossible to help you more. Your first task is to understand that code precisely and what it is supposed to do on Windows. Perhaps rewriting it in clean C++11 (maybe with some additional framework....) is the quickest way to do it.

Related

C++: Static analysis tools that will warn of missing headers [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am compiling a large project for several platforms using GCC and Clang. The issue I have is that I do all of the bug fixing and testing on one platform (Ubuntu 18.04), and even run static tools like cppcheck and clang-tidy to find bugs. As part of the bug fixing, I even try to compile with several compilers on Ubuntu to make sure that the code is ready to ship.
However, several times I have run across the problem where a developer on another system can't compile the update due to a simple missing include.
A recent example is where we introduced some new functionality which was heavily tested in GCC and Clang on Ubuntu. Then a dev on MacOS got some compiler errors which turned out to be due to a missing #include <array> in one file, and missing #include <sstream> in another. I mean, when you look at the offending files, they were indeed using arrays and stringstreams, so I get it. But I am just surprised that the static tools didn't catch those errors.
So how do I solve this problem? They definitely are programming errors, not compiler bugs since it was obvious that I should have included the files.
You are looking for include-what-you-use. From their docs:
"Include what you use" means this: for every symbol (type, function variable, or macro) that you use in foo.cc, either foo.cc or foo.h should #include a .h file that exports the declaration of that symbol.
Compiling it yourself isn't trivial as the inner workings of this tool is tightly coupled to the Llvm internals. But you might be lucky to find a pre-built package in your distro. Still, once you get it running, it's not a silver bullet. The problem it tries to solve is hard, there might be false positives etc.

Do I need to type -std=c++17 (or whichever standard I want to use) every time I need to compile a C++ program? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I have the Windows 10 OS, use VS Code to write my C++ code and use CMD to compile my programs. I don't really know which standard the compiler in my PC (MinGW, gcc version 6.3.0) uses, but I just want to endure that it uses the latest one like C++14 or 17. Unfortunately, I need to type in -std=c++17 every time I need to compile my program using that standard. How do I set the desired standard as default?
Unfortunately, I need to type in -std=c++17 every time I need to compile
This is why build scripts exist. There are many arguments that you want to pass to your compiler at some point:
Source files (you may have multiple translation units = .cpp files)
Include directories
Libraries to link
Optimization level
Warnings
C++ standard
Symbol defines
...and many more compiler flags...
In bigger projects you may also have multiple build targets (and thus compiler invocations) and you don't want to do all that by hand every time either.
As a simple solution, you could write a .bat script that invokes the compiler with the right arguments for you. However, there are tools that do a way better job at this, such as make (generally only found in the Linux world) or MSBuild (part of Visual Studio). Then there are also tools that generate these scripts for you, such as CMake and several IDEs with their own project configuration files.
I just want to endure that it uses the latest one like C++14 or 17. Unfortunately, I need to type in -std=c++17 every time
-std=c++17 is exactly how you ensure that you're using the C++ version you want (in this case C++17).

Difference between Turbo C++ and Borland C++ compiler [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I compiled two code using Turbo C++ 3.0 and Borland C++ 5.02 compilers and come across some odd things my cods are like these :
First Code
void main()
{
}
Second Code
#include<iostream.h>
#include<conio.h>
void main()
{
}
and i got these results from them :
- Borland C++ (First Code) : 51KB
- Borland C++ (Second Code) : 51KB
- Turbo C++ (First Code) : 5.89KB
- Turbo C++ (First Code) : 16.3KB
I checked two Borland execute files with a hex viewer and realize they are exactly the same.
I examined the First Code form these compilers in IDA pro and come across these graphs :
Turbo C++
Borland C++
Now i have these question i'd like you to answer
1-Why Borland C++ compiled files are the same when one of them clearly dosen't have some include and another have?
2-Why Boland C++ compiled files are that big? (nearly 10 times bigger) and what is compiled that have that much size?
3-When i submit First Code to this Site i can see the assembly code of simple void main function and i realized that Borland C++ code is very much the same but Turbo C++ assembly code is very very complicated and isn't the same, why?
4-Why this simple Code that compiled with Turbo C++ create this much functions that you can see in it's graph?
Sorry about this long question but if you can clarify this to me that would be awesome i'm so confused right now.
I will do my best at answering these, but you may need to post your questions to the Borland forums for detailed answers. In any case, upgrade your compilers.
1-Why Borland C++ compiled files are the same when one of them clearly dosen't have some include and another have?
Your program has no functionality and is incorrect. (The main function returns an int, always.)
You can include all the header files you want. You don't use them, so there is no additional code generated.
Your program doesn't require any header files. The have the same functionality.
2-Why Boland C++ compiled files are that big? (nearly 10 times bigger) and what is compiled that have that much size?
There are many possibilities. You'll have to either look at the assembly code generated, machine code generated or post to the Borland forums.
This also depends on whether you compiled in Debug mode or in Release mode. It also depends on whether you compiled for static libraries or dynamic libraries.
Fundamentally, the Borland Compiler may be generating code that meets the standards required by later versions of Windows than Turbo C++ was required to support. Research the difference between ".com" and ".exe" formats.
3-When i submit First Code to this Site i can see the assembly code of simple void main function and i realized that Borland C++ code is very much the same but Turbo C++ assembly code is very very complicated and isn't the same, why?
See my answer to #2.
4-Why this simple Code that compiled with Turbo C++ create this much functions that you can see in it's graph?
Most likely because you are compiling in Debug mode; or because Turbo C++ is a simpler compiler, it doesn't optimize the libraries and code as much as Borland does. In Debug mode, there are symbolic information placed into the executable file.
By the way, the size of the executable may not be the size of the executable code placed in memory. The executable format allows for stuff other than executable code to be placed in the file, such as program symbols an line numbers.
Don't worry about program sizes anymore. Get the program working correctly, robustly and safely before optimizing for size.

Best practice when building large libraries for project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am currently working on a Raspberry Pi project that uses the OpenCV library, among others. The OpenCV library is quite large, and the build process for it is decently extensive. I found a script which downloads and installs the latest version of OpenCV, and following some suggestions from this question, I was able to build the library, and begin using the functions within OpenCV.
Considering the actual build process for OpenCV took considerably longer than building our project would, is it acceptable to just build the library once, as opposed to building the library each time we build our project?
While I realize this is probably personal preference, I am wondering how others handle situations similar to this.
As you probably already know, code that does not change does not need to be recompiled. This is true for executables and libraries alike.
A library is supposed to provide you addictional functionality in a neat, pre-packaged form. The difference between additional code you add to your project and a library is that the code included in a library is supposed to be in a stable state, so that once built the user will be able to use its features without any maintenance hassle; the APIs will be available and they will always work. You will be able to discard any implementation files, and just work with the header files - which provide you with the API within your code - and the library files, which contain the compiled implementation.
You are pretty much pre-compiling part of your program; a part that will also be able to be used in other projects, again without recompiling.
Note that C++ itself is an example of this: an implementation of the C++ standard library (for example libc++) is already included with your compiler, so that you are able to use the standard C++ headers without the need to recompile C++ whole every time you try a "Hello World!" program.
You can even extract libraries out of parts of your project that you feel are already completed and stable: this can allow you to reduce the time required to compile your project even though it becomes bigger. These reasons are part of why modularity is so strongly encouraged when programming.
TL; DR: Recompiling a library only once is not only acceptable, is most probably what you want to do.
It is normal to compile once and then only link the library. For that reason the compilers can detect whether there are changes in source files.

How C++ libraries work? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As i know Windows operating system used the assembly language to interact with the hardwares.
When they did this,they could use c,c++ or any other language to the rest work.
As i know C++ header files actually call the windows api for the implementaion.
So where are header files located? Are them installed by compilers ? or they come with the operating systems?
What keyword or code do the header files use to interact with the sutable api(for example std::cout on windows,calls a function in a dll file and in linux an other)?
For example is iostream.h different on linux from windows?
And how that how they find suitable libraries?
And my last question is that,how libraries interact with assembly code?(so assembly code interacts with hardware)
TIA.
The following passage isn't meant to be any sort of complete description of how libraries, compilation processes or system calls invoking works but rather a bird-eye view of what OP asked, thus lacks several details and important passages which will have to be studied in-depth by the OP himself
By "C++ library" I assume you're referring to the C++ standard library (although the considerations here are valid for any other library as well).
The C++ standard library isn't mandatorily present on any operating system by default, it usually comes shipped with a compiler installation or with a secondary package. That doesn't mean you can't execute C++ compiled routines, you just need headers and the library in order to compile your programs along with a compiler which supports it.
The C++ standard library is usually compiled platform-specific and you can't just copy the headers and lib files from one operating system to another one (you'll end up in tears).
Everytime you import the declarations from a header file with something like
#include <iostream>
you're rendering your program aware of the moltitude of data structures, functions and classes provided by the standard library. You can use them as you want as long as you provide the .lib file (in a Windows environment) where the code of the routines is usually defined (in Visual Studio this is usually referred as the Runtime Library with /MT /MD options) for linking.
Once you've linked your executable against those .lib files, you have a compiled executable which, opened in a disassembler, might have something like (for a simple hello world, snippet from here - not a windows environment)
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
thus eventually every C++ function or routine provided by the standard library either implements an algorithm and/or eventually call some operating-system specific routines through System Calls. There are several design and implementation differences between the various operating systems (and even the boundaries of the system call points) in addition to a thousand of layers for security checking (not to mention ring3/ring0 switches) so I won't spend more words here about that.
You may try to install the Windows SDK and check the %PROGRAMFILES%\Microsoft SDKs\Windows directory.