Will C++ code be compiled differently on different computers?

[Grime]

Will standard C++ code always be portable? Will something compiled on one system to be very efficient on that system be very very inefficient on some other systems?

Then what do you do when you want to distribute your applications as executable?

Is that what installers do? Do they compile the code on the user's computer? But then you have to also include the C++ compiler itself with the installer right (or maybe you can compile using the compiler and then delete the compiler?).. What do popular applications built in C++ do? Or do they use an interpreter? Can you use an interpreter for C++?

Any reading material you can suggest for writing an installer?

Also is the concept of pointers a C++ specific thing or do other languages also have this?
Is compiled always more efficient than interpreted?

[Thomas1965]

Also is the concept of pointers a C++ specific thing or do other languages also have this?

Pascal and C# also have pointers.

Then what do you do when you want to distribute your applications as executable?

You have to build it on the platform you want to distribute it to.
Windows apps will only run on Windows - sometimes they work on Linux using Wine.
Linux apps will run only on Linux

Normally installers don't compile programs

What do popular applications built in C++ do?

Many websites offer binaries for different platforms.

[Grime]

Yeah of course, but I'm referring to different systems of the same operating system.. Then what😳

[JLBorges]

> Is that what installers do? Do they compile the code on the user's computer?

Installers that install from source code would need to compile and build the software on the target machine. Other installers install from pre-built binaries. For instance:

FreeBSD provides two complementary technologies for installing third-party software: the FreeBSD Ports Collection, for installing from source, and packages, for installing from pre-built binaries. Either method may be used to install software from local media or from the network.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html#ports-synopsis

In either case, that the installer correctly resolves software dependencies is important.

Both packages and ports understand dependencies. If a package or port is used to install an application and a dependent library is not already installed, the library will automatically be installed first.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-overview.html

> is the concept of pointers a C++ specific thing or do other languages also have this?

See: https://en.wikipedia.org/wiki/Pointer_(computer_programming)#Support_in_various_programming_languages

[TheIdeasMan]

Will standard C++ code always be portable?

Yes, if it is compiled on the target system. One cannot take an executable made on Windows and expect to run on Linux or Mac. A standard conforming compiler compiling standard C++ code should be able to produce an executable for the system which it compiling on, that same code could be compiled on another system.

Will something compiled on one system to be very efficient on that system be very very inefficient on some other systems?

No, the compilers available today do a very good job of producing efficient optimised code. I suppose someone could write a compiler that produced inefficient code, if that were the case, no one would use it.

In terms of compilers compiling differently, that is the case for different compilers, and to a certain extent what CPU is being used. The C++ standards specify what behavior is expected, but the implementation is up to the compiler writers. So MS, gcc, clang might all do things differently, but the end result (the behavior not the assembly) should* be the same. With the CPU target, there might be differences in the instruction sets available, and other things like endianess. This will alter what assembly is produced.

* While the behavior is supposed to be the same, often different effects are observed.

Anyway Happy New Year !! :+)

[jonnin]

good code won't normally vary in performance by a huge amount, but it will vary across compilers. Small changes in how they do things can make an observable difference esp for high iteration count loops where the inefficiency is multiplied by several million resulting in milliseconds+ differences in run times. Very rarely you may need to write 2 or 3 versions of an inner loop for performance critical code that runs on multiple platforms.

If you ever have a gigantic % difference across compilers for the same code, the slower one probably has a bug somewhere; this happens once in a while but is very rare.

if you ever run into this issue, or more likely, you run into an issue where you need two platforms to do the same thing but you also needed an operating system call or the like, you can do it with simple macros.

eg
#ifdef unixcompile
void foo()
{
  unixstuff;
}
#else
void foo()
{
  windowsstuff;
}

[dhayden]

Will standard C++ code always be portable?

No. Parts of the language are specifically defined as implementation dependent (such as the size of int and long). Other things specifically create undefined behavior (such as reading past the end of an array). Perhaps the hardest part is that you can write code that depends on the implementation without you even realizing it.

This is why the term "porting code" exists. Sometimes your code works fine on one Processor/OS and fails on another. The reason is that you have some dependency on the first Processor/OS.

If you're talking about, say, a windows program that runs on one system and whether it will run on anther windows system, chances are very good that it will run, but you can still create unexpected dependencies that cause the code to fail when windows is upgraded or if someone has a configuration that's different from what you expect. I'll give a personal example: my "My Documents" folder is D:\dmh. This is different from the default of C:\WINDOWS\Dave. Many programs assume that you haven't moved "My Documents."

Will something compiled on one system to be very efficient on that system be very very inefficient on some other systems?

That's very unlikely.

Is that what installers do?

Installing a program, particularly a windows program, involves more than just copying files to the hard disk. There may be registry entries that are required, DLLs that have to be installed, shortcuts to put on the desktop, and you need to provide a way to uninstall the program too. The installer does all of this. But if the program was written in C++ then the installer isn't likely to recompile anything.

Any reading material you can suggest for writing an installer?

Just this: don't do it. :). Find a program that will create the installer for you.

Also is the concept of pointers a C++ specific thing or do other languages also have this?

As someone else mentioned, Pascal has it too. I'm not sure about other languages. Java uses references for everything.

An interesting aside: the more unique operation in C++ is & (address of). This can be used to greatly simplify some algorithms like inserting into a sorted linked list. But since most languages don't support it, most algorithm books don't show you how to do it. See for example my reply here: http://www.cplusplus.com/forum/beginner/210154/

Is compiled always more efficient than interpreted?

Hmm. Probably, although some interpreted languages do "just in time compilation" where they compile bits of the code and keep it around in case you need it later. Since lots of code involves loops this can greatly speed up the interpreted code.

[jonnin]

Is compiled always more efficient than interpreted?

always is a strong word. a simple, dinky little program can probably be compiled so fast that with multiple cpus (one compiling, one running it) you can't tell.
but yes, compiled is *technically* always more efficient. By definition interpreted languages compile it every time, which means it burns the cpu to compile every time you try to run it.


in practice, unless the program is pretty beefy, you won't notice it anymore because cpus are just that fast now and techniques are really good as well. When java first came out, it was so slow and clunky I swore to never use it; it was a full order of magnitude slower for many programs. And basic was horrid too at that time. There is a huge difference between a single core 100 MHz and 4-8 core 3ghz processors!! You can compile java now anyway, if you need to.

[Grime]

Does the compiler compile depending on the specs of the system? If so is there a simple example?

In short is something compiled on a system work equally efficiently on all other systems of the same operating system?

[Peter87]

In short is something compiled on a system work equally efficiently on all other systems of the same operating system?

Not necessarily. It depends on the hardware.

If you compile on x86, GCC will by default generate an executable that works with essentially all modern x86 processors (that runs the same operating system), which means it might not take advantage of special instructions that only exist in some of the processors. You can pass -march=native to instruct GCC to generate code for the current processor architecture. This might generate faster code but the executable will probably not work at all on other processors.

[Grime]

Given that would it make sense to bundle the compiler and compile AFTER the user has gotten the application, on his own machine? Has anybody done that or it's just unreasonable because of how less difference it makes?

Juzt curiouso.

Does the version of the operating system also matter? Like Windows XP vs Windows 10? Matter a lot or matter meagrely? So if I put something compiled in Windows 10 to a windows XP, would it handle it as well?

[keskiverto]

would it make sense to bundle the compiler and compile AFTER the user has gotten the application

No. If you do that, then you do distribute the source code.

If you distribute the source code, then distribute the source code and instruct the user to compile (with whatever compiler they have).

[Grime]

Can resource files of a .exe be read? If not then can we not make the source code a resource file that is embedded in the .exe itself?

[Peter87]

Why is it so important to hide the code? If the users are supposed to run the code on their own computers, don't you think it's fair to let them know what it does?

[Grime]

Could be a game. If it were a game, then allowing the users to see the source code would also allow them to cheat! What then?

[Peter87]

So what? If they want to ruin their gaming experience why not let them? Some games even have "cheats" built in to the game.

[Grime]

I'm not building a game.. far from it. I'm just curious. Just random thoughts I have.

So can you include the source code itself as a resource file to an executable which would be the installer and then compile a new executable when it's on the user's hands.

My argument is.. (emphasis on this) if you're gonna have an installer anyway, why not also make the installer compile the source code itself. But of course if it doesn't make a difference then there's no point.

So would it make sense to also compile along with installing?

[helios]

if you're gonna have an installer anyway, why not also make the installer compile the source code itself.

It would be very shitty on the part of the developer. They'd basically be offloading their power consumption off to their users. And not merely offloading, multiplying as well: if you have a million users and they all need to build your code to use it, you're multiplying the total energy cost by a million.

[Grime]

Ok so basically it's a no no.. When I heard about C++ compiling I thought that maybe that's what installers did.. compile.. guess not! Guess they only set up the directory and files.

[JLBorges]

> My argument is.. (emphasis on this) if you're gonna have an installer anyway,
> why not also make the installer compile the source code itself.

Ideally, give both options (ready to install binary or build from source code) to the user.

Pre-built binary packages may be smaller than source code tarballs + build tools that may be required to build from source. Binaries do not require compilation; for large programs, compilation times can be long. In addition, there may be users who are not familiar with the process of building software from source.

Building from source provide far greater control to the user. A pre-built binary is usually compiled with fairly conservative options to enable it to run on many different systems; while building from source, the user can provide custom compiler options. It is also possible to provide customizable compile time options for selecting which features are to be built and installed, which libraries are to be used etc. There is also the benefit that version updates (with source code patches) are smaller because they do not require redistributing the entire package.