6 ms·
Show HN: A C++ dump func. that can print multi-D vectors, maps, tuples, and all
- sylware 3y agohttps://www.xkcd.com/2835 https://www.xkcd.com/2835 ... c++ syntax ...
- philip82148 3y agoI thought it would be odd to use C++ as an analogy for C++ itself. But it might be confusing. I'll reconsider. Thank your for the feedback!
- lionkor 3y agoIm 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)
- toxik 3y agoIt’s macros because it dumps the expression. There is a non macro variant.
- philip82148 3y agoThe macro version is for printing the variable's name. But it also has a function version. Why this library has some other macros is written in my new comment. Also, (though I hadn't mentioned competitive programming before my new comment,) as far as competitive programming is concerned, I prefer `dump()` to operator<<, which has more letters/types(`cout << variable << endl;`).
- quietbritishjim 3y agofmt 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)); Then define a formatter for dump that uses constexpr if to decide whether to format the underlying object directly or to use your custom iteration logic. That is more extensible (it can format anything that fmt can), it avoids macros, and it's more efficient (it can format directly into the target buffer).
- quietbritishjim 3y ago[flagged]
- quietbritishjim 3y agoToo late to edit, but just to add: I do know that, sometimes, rarely, it is justifiable to use goto (at least in C, much more rarely in C++). So the above comment was not just a knee jerk reaction. However, this is not one of those occasions. A quick look at the code shows that it's just an unnecessary mess.
- up2isomorphism 3y agoWhat is the problem of this goto use in particular, except that you don’t like see goto?
- quietbritishjim 3y agoThis is a classic low-effort comment that requires a high-effort response. Still, I've finally caved in and written one. It's like asking why do you not like driving this car in particular while it's on fire? Disliking a use of goto does not need individual justification. All the usual reasons apply, from all the way back to the 1970s when structured programming was introduced. (Although, back then, goto could jump into totally different functions so was enormously worse.) And I already said that, in this case in particular, refactoring to avoid it would improve the code clarity. The goto I referenced in particular was to re-attempt formatting after an initial attempt did not finish within some limits. But the core element that is attempted twice could be put in its own function and simply called (up to) twice in the outer function. This would make things clearer by itself, but in addition it also means the many local variables (also a bad sign) could be split across the two functions. More importantly – and I think this implication was always clear – this is such a fundamental and easily avoided mistake that it reflects worryingly on the developer writing the code. In short, this function is not writen by someone whose code I would want any production software to depend upon.
- up2isomorphism 3y ago
- mgaunard 3y agoMost 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.
- deleted 3y ago[deleted]
- zem 3y agothis is not so much for logging as for printf debugging. add this to your project, sprinkle a few dump commands through your code and you're good to go.
- bregma 3y agoMmm, hard-coding std::clog, using std::endl, not professional-grade stuff.
- up2isomorphism 3y agoThis is why people don’t want to share nice things. BTW, the source is there, go change it to what you like.
- infamouscow 3y agoI too can make snarky comments that contribute literally nothing of value
- nor-and-or-not 3y agoSomeone coded something, possibly just for themselves. They happen to share it on a platform for sources. Then it ended up here. And it seems to fall into the area of your interest because it was important enough for you, to leave a degrading comment about it, when you simply could have opened an issue or – even better – created a pull-request improving it. But no. I'm advising you to reflect on your words on how they do or don't add professional value.
- philip82148 3y agoWould you tell me what I should use instead of std::clog and std::endl? (Is it a deleted comment? I'm not used to HN because this is the first time for me.)
- MauranKilom 3y agoDidn'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.
- quietbritishjim 3y agoIt just hardcodes std::pair and std::tuple https://github.com/philip82148/cpp-dump/blob/main/hpp/export_tuple_like.hpp https://github.com/philip82148/cpp-dump/blob/main/hpp/export...
- philip82148 3y agoIt supports both std::pair and std::tuple. But I used std::get instead of std::tuple_element. I'll change it. Thank you for your advice!
- MauranKilom 3y agoI actually initially also wrote "std::get and std::tuple_size", until I double-checked. :D Is there a reason not to just handle/accept everything that has a valid `std::tuple_size` specialization?
- philip82148 3y agoOh, I forgot to mention this, but I am already using std::tuple_size. There is no reason not to handle/accept everything that has a valid `std::tuple_size` specialization. (I am not a native speaker, so I might have misunderstood your reply.)
- philip82148 3y agoSorry, plz ignore this comment. I just changed the source. I used std::tuple_size to handle everything that has a valid `std::tuple_size` specialization.
- izoow 3y agoI'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. [1] https://github.com/sharkdp/dbg-macro https://github.com/sharkdp/dbg-macro
- nick__m 3y agoI might use this, or the one from the title, for print debugging my personal project when I have enough rom space and I don't feel like plugging a jtag adapter. To philip82148, don't let the critics pull you down, you made it to the front page after and they probably haven't. You can still learn from them (your use of a goto when a while would have been probably sufficient) but ignore the negativity.
- philip82148 3y agoThank you for your advice! I appreciate it and I'll do so.
- deleted 3y ago[deleted]
- philip82148 3y agoWow, I didn't know about this. Does this also support formatting nested containers with auto indent? I couldn't figure it out from the README.
- philip82148 3y agoWhat 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:)