[boost] Re: boost::format rant

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-04-22 03:40:49

> Hello,
>
> there are several aspects of boost::format which I don't like. Due to work
> issues, I managed to completely miss the review. I had a parallel proposal
> back in time, but I didn't have time to push it enough. I guess I can
start
> a discussion about what I don't like, so that maybe people can explain me
> why I'm wrong.

I am not that familiar with current state of boost::format. Though I do
remember having several issues with it's design and implementation. But
let's be fair. Let see what you proposing.

> Now, let's see my counter proposal. It's the library I'm already using. I
> also modified it to make it compatible with Boost.Format interface and
> format specifiers to be sure I was not missing something big in it.
> Description is:
>
> - String formatting is a need in everyday code. And it's a basic need: you
> usually want to print integers/strings formatted within strings. You
> _rarely_ need
> advanced formatting options like %-10d, let alone weird stuff like tab
stops
> or manipulators (people that like printf() usually it's because they don't
> need manipulators to specify "print this in hex"). In C++, you also want
> positional arguments, since it's typesafe. I'm not against adding advanced
> formatting options, but the library should be tuned for easy uses, which
> means easy and direct interface.

I personally would not accept a formatting library claiming to be a analog
of printf in C++ world and does not support all of it's features. I agree
though that library may provide advanced and simplified interfaces.

> - No class boost::format. No function boost::format. It's just template
> <typename T> std::string operator%(std::string, T whatever), and you
inject
> it into your global namespace (a clash is _very_, _very_ unlikely). That's
> all you need: a function that lets you format a single parameter into a
> string and get the new string as result. In a perfect world, I'd like that
> operator% to be defined into namespace std.

1 .I could not imagine how could you implement this efficiently without
making constant copying/appending of string objects.
2. Having anything in global namespace is as good/bad as adding using
boost::format statement everywhere. And you claimed it's unacceptable.

> - Notice that you don't *even* need to convert to string explicitly most
> of the times:

Instead you need to copy these strings all the time.

> void Error(std::string msg);
> [...]
> Error("Sorry, there are only %d apples in the basket" % numApples);
>
> Because it gets default-converted! The same code with Boost.Format is:
>
> Error(
>     boost::io::str(
>         boost::format(
>             "Sorry, there are only %d apples in the basket") % numApples
>     )
> );

To make fair comparisons we need to add using statements effectively making
above almost identical to your version.

> It gets a bit better if you inject everything, but hey, not everybody can
> afford it. And I don't dare measure the performance difference. I realize
it
> should not be timecritical, but why wasting cycles for _NO_ clear
advantages
> in the syntax or semantic?

Do you believe to win in performance contest? Even though boost::format is
huge (I do not know why) it should not be copied in most cases (correct me
if I wrong here)  while you will spend 90% of time copying strings, isn't
it?

> - This default conversion (syntactic sugar) does not happen when using
> streams, like in:
>
>   std::cout << "%d" % 3 << std::endl;  // doesn't compile
>   std::cout << std::string("%d") % 3 << std::endl;  // ok
>
> But if you really want, you can do:
>
> void cout(std::string msg)
> {
>     std::cout << msg;
> }
>
> cout("%d\n" % 3);

So you does need another object. Plus another copying.

> My implementation is very light, and can be compiled on almost all the
> compilers around. It uses Spirit to parse the format specifiers, so the
code
> is small. To be fair, it's hardcoded for std::string since I don't need
> wchar_t stuff, but I don't see adding this as a big problem. It does not
> support
> advanced formatting or complex stuff, but I can't see a problem in adding
> additional features, and they are not going to change the flexibility and
> immediateness of use.

Lets add all those "advanced" features, wchar support, all Spirit headers
you pull in and then we could compare implementation complexities and
performances.

> I'd like to know your opinions on this. I think I have some good points to
> propose a radical change to Boost.Format.

I do think that there is a field for enhancements with boost::format. But,
frankly, your points not that convincing to me yet.

Regards,

Gennadiy.