Coffee Space – Coffee Space

Single File Headers

I really quite like the idea of small single-file header libraries. I have been a big fan of [@nothings](https://github.com/nothings)’ single_file_libs for C/C++. The rules are:

Libraries must be usable from C or C++, ideally both

Libraries should be usable from more than one platform (ideally, all major desktops and/or all major mobile)

Libraries should compile and work on both 32-bit and 64-bit platforms

Libraries should use at most two files (one header, one source)

This is a discussion about my adventure into this space.

My Rules

These rules are inspired, but not exactly the same as the ones defined by @nothings - I have different requirements after all. My rules are:

Written in C.
Usable from Unix. Other platforms are a bonus.
Libraries should work on most architectures where possible (32 bit, 64 bit, x86, ARM, etc).
Libraries should be one header file, no more than 256 lines and no more than roughly 80 characters wide - with comments!
Should not require anything other than standard libraries that can be reasonably expected to exist on Unix platforms.

Ideally these libraries follow the ethos of the Unix philosophy where possible:

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface.

JSON

A while back I wrote json.hh and JSON.java as part of an effort to role a small, strings only JSON parser that supports both Java and C++.

This needs to be rewritten. It is in C++, is far too long, is literally broken and relies on objects.

Things I liked were:

Everything is a string - parsing the strings is the responsibility of the user of the library.
String escaping worked relatively well.
Ability to create new JSON data structures. (It’s not entirely clear I can replicate this within the constraints I have.)

A few things I would change are:

Only retrieve data that is specifically requested.
There is no real meaningful difference between objects {} and arrays [].
Return string data in place (and avoid copying).

uServer

After initially planning a server concept, I eventually wrote the code to uServer, a very small single-threaded server. I am quite happy with the implementation and it supports even more features since I last wrote about it, with MIME support and content caching in RAM (for files only).

For now it is highly usable and ready for real-time testing. I will think of a small but useful project soon to put it through its paces.

Future Projects

These are the following planned projects that are within the defined rules:

uDatabase - I have a concept for a small key-value database I would like to implement. It should be exceptionally performant when compared to other databases, but of course is much more restricted. The aim here would be to create something suitable for small embedded projects that have little resources available.
uJSON - As previously mentioned, I want to rewrite the JSON parser.
uXML - I want a small XML parser capable of parsing both XML (such as RSS) and HTML (a superset of XML?).
uLog - Many times I have now re-invented logging and I finally want to address it in some meaningful way, with rolling logs that self-overwrite with timestamps, etc.
uParse - A ‘generic’ parser that replaces one wrapper with another.