More quality-of-life improvements: Hash and printers for collections

[guicho271828]

Ported from the private code base.
I could use more complex templates to remove all redunduncies, but avoided doing so because personally C++20 metaprogramming (e.g. std::enable_if_t ) is too much for me :(

[salome-eriksson]

Thanks for the PR! While we decided against pursing to add the hash functions due to feature bloat (the code base currently doesn't need them and they can be easily added when needed), we would like to integrate some of the printer functions for data structures that are commonly used, concretely pair, tuple, sets, unordered_set, map and unordered map. We do already have one for vectors in logging.h; this is also where we would like the others to live.
As a next step it would be great if you could alter the pull request by removing the hashing part and moving the printing for the mentioned datatypes to logging.h; then we will do a more detailed code review.

[maltehelmert]

One of the things that would be nice to see is less code duplication. Some of the functions are literally identical character by character; for others the differences are small and could be factored out (printing "{}" vs. "[]"). Perhaps we can have a more general "print_sequence"-style template that the more specific printing functions could call, but sometimes this kind of stuff is difficult with the way that C++ templates work.

[guicho271828]

As I briefly mentioned on the code comment, with C++20 features (e.g. concepts and require) those duplicates can be merged into one. The question is whether such code is debuggable / beginner-friendly and whether such criteria is a priority. I made a safe bet.

[guicho271828]

Hi,

I insist keeping the hash functions, but for the sake of quicker merging, I will move the hash functions to a different PR and discuss the pros/cons of adding them in the new PR.

[guicho271828]

I do not think logging.h is the right place even for the vector printer that currently already exists.

Logging and printing are orthogonal features. Logging specifically deals with log levels (error, warn, info), timestamps, and the logging scope (which code produced that log), in many logging libraries across multiple programming languages. (Python's logging module, Java's log4j, Common Lisp's log4cl, Ruby's logger class, Go's log package ...)

Printing is sometimes used to generate a log message, but it is fundamentally unrelated. Its purpose is to turn an object to a string for either debugging or serialization. (For example, Python has __str__ and __repr__ as separate methods.) We would use it mostly for debugging purpose.