Re: [boost] String formatting library: interest?

From: Giovanni Bajo (giovannibajo_at_[hidden])
Date: 2002-05-12 16:44:43

----- Original Message -----
From: "Dirk Gerrits" <dirkg_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, May 12, 2002 11:05 PM
Subject: Re: [boost] String formatting library: interest?

> But by 'extension' do you mean 'implemented in terms of'? Because I'm not
sure that
> this
> boost::basic_string (or whatever it will be called) *should* be
implemented
> using
> std::basic_string.

I understand that my message turned out to be a bit confusing.

My original idea used to be to submit an official proposal for a future
extension to std::string. My first implementation was a class derived from
std::string with the new arg() method. This design worked quite fine, but
had indeed a glitch: basic_string destructor is not virtual, so the
polymorphic behaviour of the class was undefined.
At a certain point, I wanted to add something like:

int value = 12345;
std::string a = mystring("%1").hex().align(left).pad(5).arg(value);

instead of:

std::string a = mystring("%1).arg(value, 16, left, 5); // what's the order?
what if I want defaults? etc

But that wasn't feasable, because it would have required additional member
variables (which couldn't be destroyed polymorphically). I'm fairly sure
that pretty much nobody uses std::string through a pointer, but still I
wouldn't like to start with such an issue in the design.

I lately realized that there is no real need for a mystring class type,
since its normal use is via unnamed temporaries (see the examples). So, my
current idea would be to remove the mystring type, and add a format()
function instead:

std::string a = format("%1").arg(100);

where format returns an implementation-defined type that can be implicitally
converted to std::string, and supports arg(). This way we wouldn't have to
take the hazard of deriving from std::string, where I foresee troubles
everywhere with dozens of different (and maybe also half-broken) standard
libraries, and we are not losing (almost) anything syntax-wise.

> If it were implemented internally as a
> std::basic_stringstream
> for example, then the parameters to arg, operator+=, etc could be any
class
> that overloads the proper stream insertion functions. A lot nicer and less
> limiting.

As a matter of fact, my current implementation internally uses stringstream
within arg() to perform the argument substitution. So, it's feasable to add
a template arg() member function that would match any type that supports
operator<< towards a stream.

Giovanni Bajo