Show HN: A C++ dump func. that can print multi-D vectors, maps, tuples, and all
Didn't check whether it hardcodes support for std::pair and std::tuple, but the "correct" way to do this is to rely on `std::tuple_size` and `std::tuple_element` for all tuple-like types. User types may well have these customizations defined already for e.g. structured binding support.
What I want to do with this library is to make a C++ version of JavaScript's console.log(), PHP's var_dump(), or Python's print(objs...). In other words, this library aims to print variables of any types easily for debugging.
BTW, actually I made this for competitive programming. The reason the library has some macros is also the macros are useful for competitive programming. And I thought it might be useful also for debugging productions, so I created this post.
I am learning a lot from everyone's advice. New advice is welcome, too. (I don't want harsh advice, though. :smile:)
fmt already supports containers. Does it not support nested ones? The docs aren't clear.
Even if not, this library would surely be best implemented in terms of fmt. You could define a utility class "dump" that just holds a reference to the object you want to format. Then you can use it like this:
fmt:: print("{}", dump(foo));
I've been using something similar lately for my "quick and dirty print debugging" needs [1]. It's much nicer and requires less effort than just using printf/cout. I feel like many of the critical comments here are missing that that's probably the intended use-case of this.
Most of these libraries are in my opinion quite misguided.
What you want when dumping/logging is a structured machine readable output. You just want to provide an API where you can define how any type is structured. Then use that information to emit any format you want (JSON, BSON, CSV, arrow, whatever).
From that you can then build your pretty printer in any way you want the data to be printed.
https://www.xkcd.com/2835 ... c++ syntax ...
Mmm, hard-coding std::clog, using std::endl, not professional-grade stuff.
Im not sure why exsctly you would prefer this over just a few overloads of "operator<<"?
Why is it all macros? That seems ancient. Again, you could do this more cleanly with concepts and a templated operator<<, which then also supports more than just std::clog (fmt/std::format will happily use operator<< for example)