Re: New compose and format API

[Daniel Elstner <daniel kitta googlemail com>]

Am Dienstag, den 14.08.2007, 16:18 +0800 schrieb manphiz:

> Well, fixed number of arguments is still a restriction after all, and 
> IMHO variadic function might help better in this case. It reminds me for 
> the case of boost::tuple, whose implementation is very complicated and 
> verbose since it was implemented when there was no variadic template 
> arguments and function template default arguments, which are added into 
> C++0x now partly because of these issues.

There is no restriction beyond what's imposed by the placeholder syntax,
which only goes up to "%9".  I think nine arguments are more than enough
for the purpose of generating user-visible message strings.

> Operator% is somewhat weird at a first glance, but gains the power of 
> type safety; and function calls is more familiar together with the 
> inevitable trade off. Well, since it could be implemented in either way, 
> it's now becoming a question of personal taste.

Both are type safe.  Variadic functions are definitely out of the
question.  I don't have qualms with the operator%() syntax, but I'm not
sure the minor syntax difference is worth the additional bloat required
to implement it.  (It would be necessary to accumulate and concatenate
the results of the operator at each step.)

> Btw, from a big picture, I think the compose and format stuff might be 
> implemented outside of a particular string class, which will make them 
> useful for std::string as well.

Well, we aren't trying to replace boost or the STL.  The main concern is
proper internationalization of GUI applications.  Using a multi-byte
encoding such as UTF-8 as the internal encoding in an application was
never anticipated in the design of the C++ STL.  The implementation of
ustring::format() does some pretty crazy stuff to get everything right,
such as passing everything through a wide-character stream and doing the
necessary conversions from and to UTF-8.  A generic implementation would
be an entirely different beast.  But as I said we aren't trying to
replace boost, and nothing is stopping you from converting the result of
ustring::format() to a different string type.

> And, according to the C/C++ standard 
> committee documents, there are proposals to provide unicode character 
> type(UTF-{8,16,32}) for C/C++, which might then eliminated the 
> requirement of gchar/guchar or Glib::ustring or any transitional UTF-8 
> solution, though it won't be something happening very soon.

That would be great indeed.  However, if they ever do this it'll require
fundamental changes to the design of the string and locale interfaces.

> Being 
> implemented as separate algorithm, it might adapt any string types from 
> the old ones to the new ones, just as flexible as boost::format.

It's not just string types, it's also about locales and using UTF-8 as
the single encoding for everything.  Trying to make this feature generic
would defy the original goal of providing a straightforward way to get
internationalization right in the context of gtkmm applications.  Right
now there so many little gotchas involved that you have to be an expert
in internationalization to get it right.

Cheers,
--Daniel