From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-04-22 03:40:49
> 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
> 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
> 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
> 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:
> "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
> should not be timecritical, but why wasting cycles for _NO_ clear
> 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
> - 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
> 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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk