
Single-file cross-platform C/C++ headers implementing self-contained libraries - ingve
https://github.com/RandyGaul/cute_headers
======
AJRF
I write C for a living but i'm not terribly experienced.

I was wondering is there a reason C and C++ code favours comments over
descriptive names? I'm almost certain i'm not making this up, but go into any
random file here and look at the names. Structs will have members called p
with a comment saying "position". It seems very silly.

~~~
enriquto
> Structs will have members called p with a comment saying "position". It
> seems very silly.

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.

~~~
ddebernardy
Assuming you have been writing code with single letter variables for long
enough, try opening a medium to large sized project you wrote a few years ago
and no longer use or maintain. See if you still understand your own code.

Descriptive variables are about maintainability. And when it comes to the
latter, the guiding principle is:

> Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live.

^
[https://stackoverflow.com/q/876089/417194](https://stackoverflow.com/q/876089/417194)

~~~
jjoonathan
I have had success using long names to good effect in non-mathematical code,
but in mathematical code, I have never gotten them to work very well.

I've tried many times over the years, but I just never seem to be able to
squeeze all the relevant information into the names without making them
excessively long, and even then I usually find upon rediscovery that I have
omitted an important detail. Mathematics seems to thrive on a kaleidoscopic
abundance of subtle but important variations on similar themes and this really
frustrates the ability to encode information in the names. Also, the necessity
of building an abstract-mathematical mental picture separate from the code
obviates the need. The value proposition of verbose naming conventions
entirely falls apart under these conditions, and once it does, the benefits of
concision rule the day.

------
paulddraper
It's a sad truth of the state of C/C++ build systems that header-only and
single-file libraries (which take very long to compile) are so sought after.

~~~
jchw
I highly recommend you give Bazel a look if you haven't. I'm coming from a
biased perspective, since I work at Google where we have a nice build setup.
But, I like Bazel so much I use it and hack on it in spare time.

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.

~~~
misnome
How does this solve the build time problem the parent post was lamenting?

I’ve looked a little bit at bazel but haven’t spent long on it. It seems to
really, really want you to do things in its specific googly way ( that seems
to stem from monorepo style and always knowing the exact build path and never
needing to distribute to users) which is hard if e.g. trying to to convert an
existing project that doesn’t perfectly fit (us: combined C++/Python with some
legacy fortran generation)

Or a project that has external dependencies currently being chain-built but
isn’t itself built with bazel (e.g. most the planet) - we don’t all have
dedicated build teams to accurately and bug free reproduce other libraries
build procedure (also getting away from a buggy reproduced build is part of my
system rewrite intention).

I seem to remember the documentation also had the usual problem that the easy
examples were well documented but hard to tell how to do anything more
complex, but maybe I didn’t dig enough. CMake has a similarish problem except
the problem is finding more modern ways of doing things that don’t suck (I’m
aware of all the talks about this, many of them are big on ambition but low on
details, and usually just teach transient dependencies).

~~~
misnome
Ignore the first sentence, I think I misread what you were specifically
commenting on for that.

------
int_19h
These are kinda misleading - "single-file" is a technically accurate term, but
if you think that implies that you can just #include them, it's not that (i.e.
not what is normally called "header-only"). It's basically a header and
implementation combined into a single file, with the implementation part
#ifdef'd. So you need manually instantiate that implementation in one of your
existing translation units, or add a new one specifically for that purpose. At
that point, I don't see how this is preferable to just having an .h/.cpp as
usual, and zipping it for distribution purposes.

~~~
pmarin
less messing with build systems.

~~~
slavik81
You could still #include the .cpp file even if they were seperate files. You
wouldn't even need the define.

------
bla3
[https://github.com/nothings/stb](https://github.com/nothings/stb) is another
set of good header only libraries.

(I'm not the author and don't know them, I'm just a happy user.)

------
quizotic
Don't C++ 20 modules solve this problem?

