Hacker News Reader

Comment by rwj | Hacker News Reader

The library {fmt} (http://fmtlib.net/latest/index.html) is on track to be included in the standard.

Wow, this is so much better. I hope they deprecate cout and its inane operator overloads. Call me old-fashioned but I like an operator to do something at least logically consistent with its intended use. Shifting shouldn't print or read from a stream, what on earth made them think that's a good idea?

One thing that drives me crazy about C++ is that if you incorporate a few different third-party libraries you often end up writing a few different DSLs. Everyone has their own subset of operator overloads that do different things in different contexts and you just have to remember which one does what based on your receiver type -- which is often 'auto' these days anyways. It's maddening. Worse still, the STL plays this game. Time to move on.

Why? I think there’s a reason behind it. I always imagined it to to be shifting bits along the stream.

It's about violating the principle of least surprise. If you create a culture of redefining any and all operators all the time to effectively create DSLs, you can't infer what anything does. You can even override operator, for some reason. Just looking at a piece of code you have no idea what it's actually intending to do.

I agree with you that there are some DSLs which are very difficult to understand at first look. However, to me shifting, and pushing/pulling over streams are not so dissimilar.

There are lots of cases where overriding operators makes sense and is intuitive to the reader, for instance when you are dealing with monoids, groups or rings.

The issue is not that each one in isolation is particularly problematic, the issue IMO is when they get assembled by an end-user into a pile of mixed metaphors.

  fmt::memory_buffer out1;
  std::ostream out2 = std::cout;
  auto out3 = printer(stream);
  auto out4 = my_printer();

  format_to(out1, ...)
  out2 << "Hi..."
  out3.print(5);
  out3 += 6;

These all do the same but it's a total mess.

Anyone who writes like that needs to have a chat with Uncle Bob.

Haha, that's fair :) I'm trying to convey that sometimes as an end developer, you pick a number of third party libraries based on what they do -- not what their API definition looks like. Then you end up in an awkward mix-n-match of DSLs that are hard to reason about without a deep knowledge of each because the operators you normally key off of are redefined. Maybe thats why I'm not a C++ developer haha.

Oh that’s great! Where have you seen that it might be included in the standard?

Has been presented to the committee, first steps in any case. The proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p064...

Interesting, thank you for sharing. Nothing new since 2017 if I understand correctly? I understand that the C++ proposal system is very slow, still it would be nice to know if that’s still something people are working on. I would personally love to see something like this in the standard!

A lot of work has been done since 2017: the proposal is at its 9th revision (http://fmtlib.net/D0645R9.html) and is prioritized (but not accepted yet) for C++20.

Awesome, thank you for sharing

FWIW {fmt} already supports formatting of containers, tuples and ranges as of version 5.0 (https://github.com/fmtlib/fmt/releases/tag/5.0.0), for example:

  #include <fmt/ranges.h>

  std::vector<int> v = {1, 2, 3};
  fmt::print("{}", v); // prints {1, 2, 3}

This reminds me very strongly of Google's string::Substitute(). Super convenient, and IIRC it was faster than sprintf as well.

Looks like it's now public as a part of Abseil: https://github.com/abseil/abseil-cpp/blob/bf29470384a101b307...

Reply on news.ycombinator.com