

Author: “No Bugs” Hare Follow: Job Title: Sarcastic Architect Hobbies: Thinking Aloud, Arguing with Managers, Annoying HRs,

Calling a Spade a Spade, Keeping Tongue in Cheek

At CPPCON2017 day 1, interesting (and IMO good <smile />) things were happening.

A Chance to Get Readable Formatting: {fmt}

– Maybe there’s still hope?

– Nope

— Garfield the Cat —

IMO, the most important thing which has happened on Day 1 was a series of discussions about a potential to adding an alternative to overloaded operator << in iostreams .

Those who know me for long enough, probably know that I am one of those people who is guilty of considering printf() (with all its type safety problems – though they can be alleviated by Lint-ing) being a lesser evil than cout’s operator << (that is, for text formatting purposes; I don’t have much problems using << for serialization etc.). Fortunately, for quite some time there is a solution which is both type-safe and readable (and also is extensible, translatable, stateless, faster-than-<<, you-name-it).

On Day 1 of CPPCON2017, there were two things which were related to this problem (which I consider one of those having the largest annoyance/work-needed-to-fix ratio). First, there was a talk by the author of the {fmt} (previously cppformat) library, Victor Zverovich:

Side note: BTW, I fully agree with the name “Chevron Hell” – along with LOTS of the developers out there (from what I’ve seen – 80%, and IMNSHO would be even more if not for each and every book on C++ pushing << operator down our throats).

Most importantly – the {fmt} library (and recent P0645R0 proposal) by Victor Zverovich solves all the problems of both printf() and cout <<. In particular, it is (a) type-safe, (b) readable, (c) translatable, and (d) extensible. As the icing on the cake, it is also faster than cout << (and just barely slower than printf()):

The second thing related to this proposal was that, during a late-night “Grill the Committee” session,

(BTW, here is your chance to see people who are at the same time most-revered and most-hated in the C++ world <wink />1)

I asked the question about better opportunities to the << operator, and the answer was like “IF there is a better option, we would consider it”. Hey, there IS a formal proposal P0645R0 (which was already discussed and encouraged to continue on Toronto meeting, and IMNSHO it would be really nice if at least one of those 15 people present on the stage would read the proposal before implying such a thing is impossible; this is not to mention that the library is out there for like 5 years now). Still, the answer does open the potential to fix this long-standing-and-very-annoying issue not just by using a 3rd-party library (which lots of us, including myself, are already doing) – but also at standard level.

Just in case if some of WG21 committee members are reading this <wink />, here are the advantages of the {fmt} over cout << (again, for text formatting purposes, which include both end-user-oriented-strings and logging):

{fmt} is much better readable. While I know that Bjarne2 disagrees with 80% of the industry on the readability of cout << being poor (and while readability is indeed subjective), let’s just compare two pieces of code below.

boost::io::ios_flags_saver ifs(x); std::cout << "The value is " << std::setprecision(2) << std::fixed << 1.23456 << "

";

and

fmt::print("The value is {:02f}

", 1.23456 );

Not sure about Bjarne, but I will take the second version over the first one every day of the week. NB: in the first example, the idea of boost::io:ios_flags_saver is to save-in-constructor-and-restore-in-destructor those sticky formatting flags; even if it is not really necessary for the flags I’m currently using because they happen to be not sticky, I really hate to think which of the flags are sticky and which aren’t (and whether I am changing a non-sticky one to a sticky one), so I have to use ios_flags_saver pretty much all the time.

{fmt} is much better translatable (which is important for end-user-oriented formatting). I am not going to go into a lengthy discussion on this one – but I was involved in i18n into 20+ languages, and can say that all the translations always go by whole phrases (and never ever by those-chunks-between-cout-chevrones). This, in turn, makes i18n of the <<-based code a nightmare (while it is fairly straightforward for printf()- and {fmt}-based stuff – we just need to replace the format string, that’s it). As one of the closely related benefits – positioned arguments are also perfectly working in {fmt} (as “{0}”, “{1}”, etc.)

{fmt} works seamlessly both over iostream and over FILE* (and adding new stream to the mix is really simple too)

{fmt} is substantially faster than cout << (in experiments – like 2x, which is not to be ignored unless we’re are really big fans of premature pessimisation).

{fmt} supports named arguments such as “{value}” (though it seems not to be a part of the proposal).

As for the undisputable benefits of cout-over-printf() – the same benefits exist for {fmt} too:

pretty much like operator <<, {fmt} is type-safe. If you specify an impossible format (such as “{:d}” for a string) – you’ll get an exception, not memory corruption <phew />

pretty much like operator <<, {fmt} is easily extensible. Adding formatting for your own class to {fmt} is certainly doable and is pretty easy too.

BTW, actually, I am not really insisting on the {fmt} (and even less – on its current implementation): using the line of argument by WG21 members, “if you give me a library which is type-safe, readable, and translatable, I will be happy”; it is just that << fails on 2 counts out of three mentioned, and {fmt} happens to comply with all these 3 requirements (and is extensible too).

Let’s just hope that this small-but-really-annoying issue won’t get buried under WG21 paperwork (and that Victor Zverovich will have enough energy to push it through; good luck, Victor – you’ll need it but we’re keeping our fingers crossed for you).

Other stuff of Day 1

Of course, I wasn’t able to attend all the sessions (lots of them were in parallel); out of those I was able of attend – the following one was of most interest:

an (as always, brilliant) presentation by Bjarne Stroustrup, on “Learning and Teaching Modern C++”. When it becomes available on Youtube, you really should take time to listen to it even if you’re NOT teaching C++. Among the most interesting and not-so-obvious things mentioned were that:

at least trying to understand how-hardware-works IS important

“DON’T BE TOO CLEVER!” “‘Clever’ is a swear word”

Still, however audacious it is, here my two (rather minor) points of disagreement:

I don’t really feel that “how cool it is” should be taken into account (unless, of course, we’re speaking about increasing course attendance). Otherwise – and as we see in practice – there are way too many developers who’re all about “cool” things (with “cool” very often leading to “being too clever” <sad-face />).

Also, I am not that keen of the very idea of “teaching C++ as such”; rather – I’d strongly prefer somebody to start “teaching C++ to do this kind of tasks”. After all, however sacrilegious it sounds on a conference-dedicated-to-C++, programming language is inherently secondary to our task as developers (and it is the task itself which is primary).

Phew, it was a long day – and there is another one coming. I hope to continue my reports from CPPCON2017 tomorrow.