Driving Compilers
Comments
bregma
electroly
Microsoft does officially call their implementation of the C++ Standard Library in MSVC "the STL." This is due to historical confusion, of course, but it persists to this very day in official materials. Check out the name of this repository and the way that they refer to it in the readme text. Always the acronym "STL" and never "Standard Template Library" so we can all pretend it simply stands for "C++ Standard Library" now.
gumby
You can just say `make hello` — no Makefile required! And then run with `./hello` instead of invoking the more obscure a.out
Obviously that doesn’t scale, but for a beginner it’s simple.
vdm
TIL
$ ls
$ cat >a.c <<EOF
int main(){return 42;}
EOF
$ make a
cc a.c -o a
$ ./a; echo $?
42
$gumby
I don't know about `ls`, but I typically type something so short on one line:
$ echo 'int main(){return 42;}' > a.c; make a && ./a; echo $?Too
This is because of built in implicit rules in gnu make. https://www.gnu.org/software/make/manual/html_node/Implicit-...
For bigger projects they are considered an anti-pattern and should be disabled (-r), because they can cause all kinds of surprises, (actually, using make to begin with is sortof an anti-pattern) . For example, implicit rules may try to compile using Fortran if it finds a file ending with .f, that's just the tip of the iceberg, getting unexpected outputs or missing outputs is another danger. There are also claims that disabling them can give a performance boost.
diffxx
I found the section on forward declarations at least partially off. I have never needed to use forward declarations for single recursion like the fibonacci example he gave. Mutual recursion does of course require forward declarations.
irq-1
Great article but K&R shouldn't be blamed for lacking this material:
> Print the words
hello, world
> This is a big hurdle; to leap over it you have to be able to create the program text somewhere,compile it successfully, load it, run it, and find out where your output went. With these mechanical details mastered, everything else is comparatively easy.
stefantalpalaru
[dead]
ybj
[dead]
I'm a maintainer of the compiler driver for a major commercial real-time embedded operating system and I can assert with some authority that this is an excellent basic introduction to how the C and C++ toolchain works in most environments today. It is clear, well presented, and mostly correct, although biased entirely towards Linux and other ELF-based platforms -- Mach-O and PE/COFF work essentially the same way but details differ and it's still essentially informative.
My biggest quibbles would be (and these are really quibbles) these.
- The name of the C++ standard library is not "the STL". The STL was a library that was partially included in the C++ standard library back in 1997. The part of the STL that was included makes up parts of the container, iterators, and algorithms sections of the C++ standard library. At this point (C++23) that's maybe 5 or 6 per cent of the entire library. The name of the C++ standard library is "The C++ Standard Library".
- In C++, ::operator new() is a part of the C++ language runtime. It's not just a template in the header <new>, although that header has to contain the (overloaded) function's declarations so they can be replaced.
- The article should distinguish between the loader (generally a part of the operating system kernel) and the dynamic loader (part of userspace), since it's common to build static binaries that do not use the dynamic loader at all. Also, the loader uses the PT_INTERP segment to find the dynamic loader, not the .interp section even though they point to the same offset because the entire section table can be stripped.
All in all an excellent introduction to what's going on under the hood when you build software using a compiled-to-machine-instructions language on a modern operating system.