Single-file cross-platform C/C++ headers implementing self-contained libraries

My own rule of thumb is: short names for 'unimportant' variables where the meaning is clear from the context. More descriptive names for the more non-obvious cases, but still keep it short and concise (e.g. I would typically use "pos" instead of "position").

Having said that, some early C dialects limited the significant number of characters in identifiers to 6 or 8. I heard that this is the reason why the C runtime library function names are short (like strcpy() instead of string_copy()).

It does not seem silly to me. Coming from mathematics, single-letter variable names are the only acceptable possibility, especially in numerical code. I tend to read contiguous letters in a formula as products.

Besides, descriptive variable names violate the principle of "don't repeat yourself". It is better to describe the variable only once, in a comment next to its declaration, instead of several times.

Programmers should understand that not everybody who programs has a background in computer science, and certainly the traditional conventions of computer science are not universal and not generally reasonable. Many of us have a scientific background, where descriptive variable names are silly. We do not want our numbers to have meaning, that's the whole point of abstraction. Thus, they are named x, y, z, and so on.

If all you have is a 300 baud terminal (a luxury for some early users), writing a 30-letter statement takes about a second. Doubling that speed by using shorter identifiers is worth it (certainly as long as all the people reading the code either wrote it, or have the writer sitting next to them)

That created a culture that persists to today.

There are different cultural streams such as Apple’s one, which originated in Pascal (for the original Mac OS). Consequently (I think), Apple’s C headers later on weren’t afraid to use identifiers with over 40 characters. Next step/Cocoa similarly aren’t afraid of long names (https://mackuba.eu/2010/10/31/the-longest-names-in-cocoa/)

Looked at several headers at random just now (including file, net) and they seem OK. Not terribly verbose, but not exactly cryptic.

In terms of 'p' vs 'position' - 'p' is an extreme and it's usually used for pointers, but the driving factor for using shorter names is usually to keep the line length in check when these vars are used in the code. Ditto for type names.

"Position" is quite often shorten to "pos", "offset" to "off", "length" to "len", etc. This is very common. Sometimes the original name is too long (e.g. "position of the last error in the first block") and lands itself to a not-so-obvious abbreviation, in which case the comment is made to clarify what it is.

It's basically about striking a balance between succinctness and verbosity, and conventionally C tends to lean towards the former.

And of coure any new C code would look out of place if it didn't follow these old shibboleths... better make new C code an unreadable mess too, no? ;)

There's really only two things that bother me:

- Windows support is alright but it's a bit weird and wants some Unixy stuff to exist. It's being worked on in small bits but it could be better. If you don't care about this you'll have a good time likely.

- Sadly it isn't widely used outside of Google, so you're mostly on your own. The only upshot is that the Starlark language makes it really easy to compose BUILD files, so I don't find it too difficult to manage a few BUILD files for things like SDL2. Unlike a lot of other build systems, like CMake for example, it would be much less hassle to consume other Bazel projects directly, since it's designed to work that way, so if it ever did gain widespread adoption it would be a really nice solution.

There's definitely some things that would turn off the average user. Like the BUILD files, in order to be predictable, contain dependency information, which either needs to be updated by hand or tools (you can guess which is preferred.) On the other hand, builds are very predictable, and it works such that you can easily express dependencies across different programming languages and even autogenerated code from another target.

Nothing is perfect, but I find Bazel is super nice for C/C++ compared to the alternatives I've used. It's a different way of approaching the problem of building software, one that I've found very novel despite the shortcomings. I'm worried it's too easy to miss what makes it special behind some of the turnoffs people initially hit.

Actually, we've been having a lot of success developing an in-house tool to solve this problem and it's helped us build agile modular systems using C++.

https://teapot.nz

It's a one stop shop for building modular C++ applications with an opinionated set of packages here: https://www.github.com/kurocha

That being said, `teapot` doesn't have any default build rules, it relies on packages to provide them, so you could build an entirely different eco-system of packages with minimal effort.

One advantage is that you don't need to mess with build systems for configuration, instead put the configuration defines before the implementation right in the source code.

Another advantage is potentially faster compilation if you put many implementations into the same implementation source. Same idea as unity-builds basically. Even though you're using dozens of header-only-"modules", the compiler only builds a single file.

In the nasty real world, these build systems introduce more issues for more people. Then linking the shared object or DLL adds management issues, naming issues, arch etc. But that's for separate dependency building as a binary.

Has every one of these side compilation steps gone perfectly for you? No. At some point they wasted your time.

This concatenation-build step is done reliably beforehand, even if simple, can be assembled and be tested by the releasing party. Saves the user some trouble.

A pre-built binary is about as easy if done sensibly. Boost is mainly header only but has some libs still requiring linking, which requires you digging into that library's particulars.

All of those are steps that have tradeoffs in time, attention, flexibility and risk.

Careful of that word "... just". Just do this! I can just do that! The full hassle/cost requires pulling out of just the compile step, in this instance.