3 ms·
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
by quietbritishjim 3y ago
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));
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 agoI personally will prefer something I can just copy a header file to use to something introduces another dependency on any day.
- mrcode007 3y agoIt’s part of c++23 and requires no dependencies
- deleted 3y ago[deleted]
- up2isomorphism 3y agoI will much prefer this to something that will require the newest C++ compiler support.
- philip82148 3y agoYes, this dumps recursively, so it also supports with nested ones. Why I made this is written in my new comment.