“If the C language is system-independent, how do I use it on a PC without an operating system? Where would you "install" the compiler?”

The C language program needs to be compiled. Practical compilers are running on some desktop operating system and need a lot of stuff installed. Of course it’s also possible to create a compiler that’s running on the bare metal. An example is the Sharp PC-G850V calculator. It’s not a PC, it does not have any OS. It’s powered by a 8-bit Z80-clone CPU made by Sharp and has only 32 kilobytes of RAM. Some Psion PDA’s also had built-in C compiler, but I believe they had something that qualified as an OS.

Of course, it’s much easier to compile bare-metal applications on a different, higher performance computer, and download the binary only. An example is the BIOS of the PC’s. It’s exactly what you asked for: an application running on the bare metal without any OS. There is no compiler built into the BIOS, and there is probably no compiler installed on the computer at all.

A compiled C program does not need any OS, virtual machine, runtime environment or libraries. Nothing is needed. And contrary to popular belief, even the C standard library is optional, and it’s very often not used.

It’s not easy.

You want to use a programming language implementation that doesn’t have garbage collection, that doesn’t require a separate runtime environment, and that interfaces easily with assembly language (which you’ll need to access processor-specific features not accessible from a high-level language). C++ certainly qualifies, but so do some others.

The first step is to define exactly what the requirements of the project are. This is one of the most challenging parts, to end up with a set of requirements that is complete, clear, and unambiguous.

You would need to understand how operating systems work, how they are designed, what algorithms and data structures are appropriate, concurrency issues, etc. Of course, you would need to know the programming language(s) you’re using for implementation. You’ll very likely need to write at least a small amount of assembly language for each processor architecture you will support.

If compatibility with existing applications is important, you would need to fully understand and support the executable file formats, API functions, etc. needed for compatibility. If you’re going your own way on this, then you have to defined your own file formats, API functions, etc. and document everything, and then convince developers to develop applications for your new OS.

If compatibility with an existing OSs device driver model is important, you would need to fully understand and support the formats, APIs, protocols, etc. of the driver model. If you’re going your own way on this, then you would have to define and document all of this, and convince hardware vendors to write drivers compatible with your new OS.

Of course, you also need to develop a test plan and tests, to ensure quality. And you need to do performance testing and tuning.

A compiler is not really part of the OS. Yes, some OSs include one or more compilers, but the vast majority of OSs don’t ship with a compiler.

An OS like Windows, with tens of millions of lines of code, can take hundreds of person-years to develop and test, and the maintenance and enhancement is never-ending.

Now, if you scale back requirements, it’s not quite as daunting. A small, real-time OS for an embedded system, with not UI, might take only a few person-weeks or person-months to develop.

You could use an online compiler like

and live with any limitations they present.

You could also use deployed containers (say docker compose) to download your source into the container which contains a compiler and everything related to compiler your code. This is common on CI/CD environments, so awesome for deployment but not so great for development.*

Similarly, a lot of corporate environments are set up so developers remote into a development environment and do all their work from there. Combined with other secure practices, this keeps intellection property under their control.

So there are ways to do it, but in my opinion, nothing beats local development tools.

*I do use docker compose locally as part of my local development and local CI/CD. But it is built into my IDEs and the containers are local, so that is not the same thing.

Possible, yes. But I don’t know of any C++ compiler that runs on bare metal (compilation is not a useful bare-metal run-case) and it would have to be a special compiler with special run-time libraries designed to run on bare metal. In fact, the C++ run-time environment would have to provide most of the operating system facilities (how do you do “new <something>” with no O/S to allocate memory?). So it is possible, but very difficult, does not currently exist, and is not likely to exist.

C++ compilers generating code to run on bare metal probably *do* exist, but in most cases they will target a subset of C++. The compiler running on bare metal is not useful. Cross-compilation is much easier.

In the US, Red Hat Enterprise is probably the most sought-after certificate. You can get CentOS free, which is a community-supported version of RedHat, or get a supported version from Red Hat for $349.

Other places, Ubuntu or Suse are the ordinary server versions and they come with excellent commercial support. Some people like Slackware.

If you’re interested in programming for security reasons, Kali Linux has all the security tools built into it. Kali is the old BackTrack Linux ported into Ubuntu so it’s an easier install.

Depending on the platform you’re working with, other Linux flavors might be the best. I had a job with a wearable computer some time ago and White Dwarf Linux was what was customized for the PC104 single-board computer.

If it’s a Raspberry Pi, Raspbian aka Raspberry Pi OS is good, but other distros are stripped down for it. The Pi is pretty much a ‘full computer’ and can load and run most any OS that’s prepared for it, even Windows.

If you’re wanting to program embedded systems, you’ll probably plug it into a computer running the Arduino IDE. Some other single-board computers have an OS, usually a stripped-down Linux from one of the major distros. Although an Arduino or other single-bard computer _can_ run an OS, it’s usually configured to run one program at a time and doesn’t need a full OS.

I did a project for IBM some years back with Macs and MacBooks when they used IBM Power CPUs. Yellow Dog Linux was the best for that, which also ran fine on the IBM i5 server they gave me for the project. I introduced IBM to Red Hat soon after that and Red Hat came out with distros for IBM zSeries mainframes and pSeries servers. Recently, IBM bought Red Hat and uses it for their Linux One mainframes along with Ubuntu and Suse.

These days, I mostly stick to CentOS on the several virtual servers I tend. I like it because it’s familiar to me, and I don’t need to go looking stuff up. After decades of tending to System V compliant unices, Red Hat is what I know best. If I get into an Ubuntu or BSD unix situation, or AIX on an IBM pSeries, I can probably work in it, but I need to look up where stuff is, where stuff is logged, and what switches to use on commands. Sometimes something like a ‘-B’ means one thing in one ‘dialect’ of unix or Linux and the opposite in another.

I encourage my students, who will be looking for jobs in the US, to put up a CentOS server and get to work on the RHCE. It’s good to put Kali Linux on a notebook so they can carry it around and work, ethically, on Security+, CEH+, or PenTest+ certs, exploring networks wherever they are. And, I think it’s good to put Ubuntu on a desktop or notebook so they can see the best Linux for personal use.

If you check out Linux distribution - Wikipedia you’ll see hundreds of distros based off the major distributions of Debian, Red Hat, and Slackware. There are also a couple dozen that use Linux but aren’t based on the major distros. To all these, add iOS and Mac OSX, which have huge market share and are based on BSD unix, which Steve Jobs worked with while he was away from Apple, not Linux.

There is no one ‘best Linux’, and there are probably a couple or few that are best for what you want to do.

Short answer: Yes

Long answer: It’s somewhat involved…

1. You need to make sure your code is cross-platform because each OS provides different services. One option is to use a cross-platform toolkit (like Qt, JUCE, boost, Pico) to deal with platform level differences
2. Use a cross platform build tool — CMake works well for us across Linux, Mac, Windows
3. You will have to add at least some level of preprocessor directives to deal with nuances.
4. Packaging (setup process/distribution) is VERY different on each OS. We use a CI build chain to compile and package things. RPM’s for Linux, MSI and EXE installers for Windows, and PKG file for Mac.

To learn more about linux, you pretty much need to install Slackware Linux yourself. Or Linux From Scratch. Install them from scratch, configure everything, and read the docs. That will greatly improve your linux skills, because you'll know how things work under the hood.

However, knowing Linux OS will not make you better C++ programmer, because good portion of its software is written in other languages. Kernel is in C, for example, and C++ is not primary language on linux OS. I would say that C is more likely candidate to be a "primary" linux programming language.

The good thing is that you'll get access to proper llvm-clang compiler without using any kind of voodoo, which means bleeding edge support for C++ features. But that's pretty much it.

In order to become better C++ programmer it would make sense to learn to write in platform-independent fashion, using whatever framework you prefer. Qt, boost, GTK, or anything else - instead of concentrating on Linux. Qt in particular has fairly clean code that is worth studying.

What are you installing, and how? (You say tools and libraries, not code that you’re writing yourself - what tools & libraries?)

For standard tools and libraries, the general approach is to install the packages using your distribution’s package manager - no compiling involved. (And an awful lot of tools get installed automatically, based on what choices you make during your Linux install.)

If you’re downloading and installing from source code, then it’s usually a matter of unziping and untaring the file into /usr/local/src, cd into the directory, then

./configure; make; make check; make install

Particularly for tools, there’s a good chance that you need to be root (su or sudo), or create an account and filesystem specific to the tool (though that’s more common for servers). MAKE SURE TO READ THE README AND INSTALL FILES.

Another possibility is that ./configure fails to find necessary dependencies. Again, BE SURE TO READ THE README AND INSTALL FILES.

Now, if you’re having problems compiling your own source code, then you need to look at the errors that the compiler is spitting out - chances are you have syntax or dependency issues, or you need to pay attention to the options you’re passing to the compiler.

Remove the line:
std::ios::sync_with_stdio(false);
It will work fine.

You have another alternative:

instead of:
scanf("%lu",&i); scanf("%lu",&j);
do:
cin>>i>>j;

This will also work with std::ios::sync_with_stdio(false).

By default, C++ and C output streams are synchronized. If you do std::ios::sync_with_stdio(false), both of them run independently.
Because of this, there may be some input which cin might read while scanf will skip. Same for cout and printf statements.

Thus, the output which should have been produced, didnt get produced because:

I added a line below: scanf("%lu",&i); scanf("%lu",&j);
as printf("%lu %lu\n",i,j);

It gave output "0 0". Because your i and j were initialized to 0 and 0 respectively.
This means that scanf didn't even read your inputs.

These kind of unexpected problems arise often when we use C++ streams in conjunction with C streams, if the flag for sync_with_stdio is set to false.
So whenever you use both, make sure you dont set it to false. This will often lead to unexpected outputs.

So in case of your Windows platform, I think the OS might have overruled and not allowed the synchronization, even though you set it to false. In case of Ideone, it runs on Linux platform, where the threads are allowed to run independently.

Hope you got your answer. :)

There are many different types of package management systems used in GNU/Linux, but here I will refer to .deb, which is what I have had experience with :

In this case especially, the answer to your question is Yes, but obviously the installer files need to be available (offline) first. In the case of .deb based package management, when using command-line (apt/apt-get) or Synaptic (gui based) programs, those .deb, files are stored at /var/cache/apt/archives. If you have previously installed a program, then removed it & now change your mind, assuming said cache hasn’t been cleared & the .deb is still the current version, you can install that program again without the need to download anything at all. This can also apply to a whole bunch of programs if you like, as long as all dependencies are also met (other .debs). I’m not sure what your end goal is, but I can give you a scenario where I sometimes do this : I am a self-confessed distro-hopper … I like trying new distros. I often do it on bare-metal, on a separate partition, after first trying said distro in a VM. If (after installing the distro properly) I then decide that I also want to install my favorite programs, I can symlink my /var/cache/apt/archives folder to my main distro’s cache (same version). Wala … all the .deb files I need to install my fave software are already there, and its job-done in seconds =)

You’re probably running into one or more of the following problems:

1. Failing to install dependencies
2. Having the wrong VERSION of dependencies

Some Linux distributions contain two different kinds packages - run-time support, and development support. If you’re building software, you’ll need the development support (which typically brings along the runtime support.)

But the thing about Linux distributions is that for any “version” of the distribution, they typically organize most of the packages around a few versions of some basic packages (such as compilers, scripting languages, and other “tool chains”.) They might make local patches to these tool chains, but they seldom run with the most recent version of these packages.

Which means that if you NEED a particular version of a package where that version isn’t supported by your distribution, you’ll end up building that package and installing it so it doesn’t conflict with the distribution version. (And building all of IT’S dependencies.)

Some packages are very poorly documented as to what their dependencies are as well.

Because I’m familiar with FreeBSD’s “ports” system, I take advantage of how they include dependencies so that ports can be built from source.

Resolving dependencies like this is a rat’s nest. You really want to avoid it if you can.

Because resolving dependencies like this can involve uninstalling and reinstalling various different packages with different build options, I use “radmind” to manage this - but “radmind” is it’s own kind of nightmare (just one I’m familiar with.)

There’s no such thing as a lightweight C++ compiler for small systems.

• If you mean fast compile-times, you want clang++. (35kB + gcc)
• If you mean with best support and least hazzles, you want g++. (25Kb + clang)
• On small ARM devices Embarcadero might be a good option: C++ Compiler: Free Download (= Borland/Turbo C++)
• The OpenWatcom and the Symantec C++ compilers fell out of favor
• Intel C++ has also nice support for 32bit, Intel HW only. (1Gb)
• MSVC++ comes in some free flavors, but is certainly not recommended for “lightweight”, as it comes with a mandatory UI.
• The old CERN CINT C++ interpreter was very lightweight, but a very strange thing with ~85% dynamic C++ CINT : C++ interpreter

There are a few more esoteric ones listed at List of compilers - Wikipedia with which I had not much success with. For the really small devices you cross-compile it on a big system.

The general answer is no. In my experience, when you install the IDE you automatically get the compiler. I have extensive practical experience with VSCE (Visual Studio Community Edition – the free version) and Eclipse (also free). In both cases, I was using the C/C++ compiler. In both cases, the C/C++ compiler just worked after I installed the software (VSCE or Eclipse).

Note that I have said similar experiences with Python, PHP, and JavaScript. Of course, those are not really compiled languages.

There may be exceptions to this statement (that the compiler comes with the IDE). However, I have not found them.

It really shouldn't matter that much, I would suggest that you try out a few different ones and pick the one you like. I personally started with Ubuntu (12.04 I think?), then moved onto Kubuntu because KDE is nice and it's installed by default in Kubuntu. A year ago I moved over to Arch Linux and it's by far my favorite. If you want something that works 'out-of-the-box' and is a bit cooler than default Ubuntu I would give Linux Mint a try. Here are a few things you want to consider when choosing a distro

1. How much set-up work do you want to do? With something like Ubuntu, these days it's as easy if not easier to install and get running than Windows. If you want a challenge and something with less bloat by default, you might want to lean towards Arch.

2. What package manager do you want to use? This is important but often overlooked. I personally love pacman, but it's just a personal preference.

3. What's the default Desktop Environment? You can always swap out DE's, but it's probably easier to pick a distro that has the DE you want pre-installed (or no DE installed like Arch). If you want something lightweight, you might want to look into XFCE or LXDE. If you want something more exotic, try a tiling window manager like i3 or bspwm. DE's like KDE and Unity are nice but large and full of bloat.

But, once again, the fact that you love C/C++ shouldn't really affect you choice of distribution. If you want bleeding edge features then you probably don't want to go with something like Debian Stable, but even then you could find ways to get support for C++14/17, etc.