C++11 Variadic Templates: Format("I %%% about %%% of%%%","dream", 7, 9) == "I dream about 7 of 9"

[Andrew Tomazos]

I wanted to write a function that takes a string containing a number
of placeholders and a corresponding number of other parameters
(perhaps non-pod) and returns a string with the placeholders replaced
with stringified versions of the parameters:

For example:

Format("I %%% about %%% of %%%","dream", 7, 9)

....would evaluate to...

"I dream about 7 of 9"

....in a similar way to what...

ostringstream os;
os << "I " << "dream" << " about " << 7 << " of " << 9;
return os.str();

....would do.

I'm using gcc 4.6 in -std=c++0x mode so Variadic Templates are
available.

I haven't used Variadic Templates before. My first draft is below. It
appears to work, but it's using a linear recursion. My question is,
is there a way to write it iteratively?

Basically in my recursive solution I define...

Format(s):
output(s)

....as the base case and then...

Format(s, head, tail...):
divide s into three substrings: (eg "foo %%% bar %%% baz")
1. before_first_placeholder (eg "foo ")
2. first_placeholder (eg "%%%")
3. after_first_placeholder (eg " bar %%% baz")

output(before_first_placeholder)
output(head)
output(Format(after_first_placeholder, tail))

....as the recursive case.

Working code and a test case is below. Feedback/thoughts appreciated.

============================ CUT HERE
==========================================
// (C) 2011, Andrew Tomazos <http://www.tomazos.com>

#include <string>
#include <sstream>
#include <iostream>

using namespace std;

class StringFormatException {};

const string g_sPlaceholder("%%%");

template <class ... T>
inline string Format(const string& sFormat, const T& ...);

template <class ... T>
inline string Format(const string& sFormat)
{
size_t iFirstPlaceholderPos = sFormat.find(g_sPlaceholder);

if (iFirstPlaceholderPos != string::npos)
throw StringFormatException();

return sFormat;
}

template <class Head, class ... Tail>
inline string Format(const string& sFormat, const Head& head, const
Tail& ... tail)
{
stringstream os;

size_t iFirstPlaceholderPos = sFormat.find(g_sPlaceholder);

if (iFirstPlaceholderPos == string::npos)
throw StringFormatException();
else
{
string sFront(sFormat, 0, iFirstPlaceholderPos);
string sBack(sFormat, iFirstPlaceholderPos +
g_sPlaceholder.size());

os << sFront << head << Format(sBack, tail ... );
}

return os.str();
}

int main()
{
if (Format("I %%% about %%% of %%%","dream", 7, 9) == "I dream
about 7 of 9")
cout << "pass" << endl;
else
cout << "fail" << endl;

return 0;
}
============================ CUT HERE
==========================================

Tested as follows:
$ cat > test.cpp
<paste above>
$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
$ g++ -std=c++0x test.cpp
$ a.out
pass

Enjoy,
Andrew.

 

[Richard]

[Please do not mail me a copy of your followup]

Andrew Tomazos <[email protected]> spake the secret code

I wanted to write a function that takes a string containing a number
of placeholders and a corresponding number of other parameters
(perhaps non-pod) and returns a string with the placeholders replaced
with stringified versions of the parameters:

For example:

Format("I %%% about %%% of %%%","dream", 7, 9)

...would evaluate to...

"I dream about 7 of 9"

Is there some reason you're reinventing boost.format instead of just
using boost.format?
<http://www.boost.org/doc/libs/1_48_0/libs/format/>

 

[Vladimir Jovic]

[Please do not mail me a copy of your followup]

Andrew Tomazos<[email protected]> spake the secret code

I wanted to write a function that takes a string containing a number
of placeholders and a corresponding number of other parameters
(perhaps non-pod) and returns a string with the placeholders replaced
with stringified versions of the parameters:

For example:

Format("I %%% about %%% of %%%","dream", 7, 9)

...would evaluate to...

"I dream about 7 of 9"

Is there some reason you're reinventing boost.format instead of just
using boost.format?
<http://www.boost.org/doc/libs/1_48_0/libs/format/>

looks like an exercise

 

[news]

Is there some reason you're reinventing boost.format instead of just
using boost.format?

Boost is an excellent library, but it has one slight problem: If you
would need only a very small part of it (eg. just one utility) and you
don't want to require the entire Boost to be installed in the system,
it can sometimes be hard to isolate it from the rest.

 

[Andrew Tomazos]

Is there some reason you're reinventing boost.format instead of just
using boost.format?
<http://www.boost.org/doc/libs/1_48_0/libs/format/>

Yes, the reason is as follows:

$ wc -l MySolution.cpp
46 MySolution.cpp

$ find /usr/include/boost/format -type f | xargs wc -l
168 /usr/include/boost/format/format_class.hpp
277 /usr/include/boost/format/feed_args.hpp
60 /usr/include/boost/format/internals_fwd.hpp
70 /usr/include/boost/format/free_funcs.hpp
201 /usr/include/boost/format/internals.hpp
42 /usr/include/boost/format/detail/workarounds_stlport.hpp
86 /usr/include/boost/format/detail/compat_workarounds.hpp
56 /usr/include/boost/format/detail/msvc_disambiguater.hpp
97 /usr/include/boost/format/detail/config_macros.hpp
34 /usr/include/boost/format/detail/unset_macros.hpp
162 /usr/include/boost/format/detail/workarounds_gcc-2_95.hpp
103 /usr/include/boost/format/exceptions.hpp
504 /usr/include/boost/format/parsing.hpp
329 /usr/include/boost/format/format_implementation.hpp
313 /usr/include/boost/format/alt_sstream_impl.hpp
176 /usr/include/boost/format/alt_sstream.hpp
49 /usr/include/boost/format/format_fwd.hpp
684 /usr/include/boost/format/group.hpp
3411 total



I've obfuscated my question with this format stuff I think...

My question was: is there a way in C++11 to process variadic arguments
from a variadic template parameter iteratively rather than
recurisvely?

ie

template<class ... T>
print_to_cout(const T& ... args)
{
foreach (arg in args) // ???
cout << arg;
}

Is there any way to write this function?
-Andrew.

 

[Daniel Krügler]

I wanted to write a function that takes a string containing a number
of placeholders and a corresponding number of other parameters
(perhaps non-pod) and returns a string with the placeholders replaced
with stringified versions of the parameters:

Yes, the idea is nice, but let me comment on some parts.

I haven't used Variadic Templates before. My first draft is below. It
appears to work, but it's using a linear recursion. My question is,
is there a way to write it iteratively?

Yes, see below.

#include<string>
#include<sstream>
#include<iostream>

using namespace std;

class StringFormatException {};

const string g_sPlaceholder("%%%");

template<class ... T>
inline string Format(const string& sFormat, const T& ...);

This function template is no-where use. You should get rid of it.

template<class ... T>
inline string Format(const string& sFormat)

There is no reason to declare this as a variadic template. Just declare
it as a non-template function:

inline string Format(const string& sFormat)

{
size_t iFirstPlaceholderPos = sFormat.find(g_sPlaceholder);

Either use string::size_type or - more preferably auto to determine the
type of iFirstPlaceholderPos. In theory there is no guarantee that
size_t and string::size_type have the same type or even the same maximum
value (which is relevant when using string::npos).

if (iFirstPlaceholderPos != string::npos)
throw StringFormatException();

return sFormat;
}

template<class Head, class ... Tail>
inline string Format(const string& sFormat, const Head& head, const
Tail& ... tail)
{
stringstream os;

size_t iFirstPlaceholderPos = sFormat.find(g_sPlaceholder);

Same problem here.

if (iFirstPlaceholderPos == string::npos)
throw StringFormatException();
else
{
string sFront(sFormat, 0, iFirstPlaceholderPos);
string sBack(sFormat, iFirstPlaceholderPos +
g_sPlaceholder.size());

os<< sFront<< head<< Format(sBack, tail ... );
}

return os.str();
}

int main()
{
if (Format("I %%% about %%% of %%%","dream", 7, 9) == "I dream
about 7 of 9")
cout<< "pass"<< endl;
else
cout<< "fail"<< endl;

return 0;
}

In regard to your question, whether an iterative solution is possible:
Yes, at least in the sense that you can serialize your expansions. The
following code demonstrates this:

//----------------------------
#include <string>
#include <sstream>
#include <iostream>
#include <cstddef>

class StringFormatException {};

const std::string g_sPlaceholder("%%%");

struct void_{};

template<class T>
void_ DoFormat(std:stream& os, const std::string& sFormat,
std::string::size_type& curr, const T& t)
{
auto nextPos = sFormat.find(g_sPlaceholder, curr);
if (nextPos == std::string::npos)
throw StringFormatException();
else
{
os.write(&sFormat.front() + curr, nextPos - curr);
os << t;
curr = nextPos + g_sPlaceholder.size();
}
return {};
}

template <class... Args>
inline std::string Format(const std::string& sFormat, const Args&... args)
{
std::stringstream os;
std::string::size_type curr = 0;
std::initializer_list<void_>{DoFormat(os, sFormat, curr, args)...};
auto nextPos = sFormat.find(g_sPlaceholder, curr);
if (nextPos != std::string::npos)
throw StringFormatException();
if (!sFormat.empty())
os.write(&sFormat.front() + curr, sFormat.size() - curr);
return os.str();
}

// ... Your test main() follows here unchanged
//----------------------------

You may wonder about the astonishing void_ type as well as the
std::initializer_list<void_>{DoFormat(os, sFormat, curr, args)...}
expression.

What I'm realizing here is to create an initializer-list expanded with
sizeof...(Args) expressions that have type void_. Unfortunately I cannot
use void here, because this is no object type. Even more unfortunate is,
that I cannot use a function call e.g.

template<class... T>
void swallow(T&&...){}

....

swallow(DoFormat(os, sFormat, curr, args)...);

This will compile, but since the order of the evaluation of function
arguments is not determined, there is no guarantee that this works in a
portable manner, because each function call modifies the arguments os
and curr. There exists a special rule in C++11 that ensures that
initializer-lists are evaluated in a strict order, this is the reason
why I'm creating an otherwise unused std::initializer_list<void_> here.

As elegant as it looks, I'm very unhappy about the need to create such a
hack here. It would be great, if there would exist a further expansion
pattern that allows me to write e.g.

DoFormat(os, sFormat, curr, args)...;

such that DoFormat may have type void as well.

I hope nonetheless that this suggestion gives you another idea how to
proceed.

HTH & Greetings from Bremen,

Daniel Krügler

 

[Richard]

[Please do not mail me a copy of your followup]

"news" <[email protected]> spake the secret code

Boost is an excellent library, but it has one slight problem: If you
would need only a very small part of it (eg. just one utility) and you
don't want to require the entire Boost to be installed in the system,
it can sometimes be hard to isolate it from the rest.

See
<http://www.boost.org/doc/libs/1_48_0/tools/bcp/doc/html/index.html>

 

[Seungbeom Kim]

Either use string::size_type or - more preferably auto to determine the
type of iFirstPlaceholderPos. In theory there is no guarantee that
size_t and string::size_type have the same type or even the same maximum
value (which is relevant when using string::npos).

I agree that it's preferable to use string::size_type instead of size_t,
at least semantically. However, string is defined to be basic_string<char>,
whose size_type is defined to be allocator<char>::size_type, which is
in turn defined to be size_t. Therefore, in this particular (and common)
case, string::size_type is identical to size_t.

Of course, there can be other instantiations of basic_string which use
an allocator other than the standard one which defines its size_type
to be a type different from size_t. My question is: in such cases, does
an implementation exist where size_type is bigger than size_t, or can
one ever exist? On all of not-so-many implementations I have ever
experienced, size_t was the biggest unsigned integer type, so I have
a hard time imagining an unsigned integer type bigger than size_t.

 

[Jean-Marc Bourguet]

I have a hard time imagining an unsigned integer type bigger than
size_t.

Having a 32 bit size_t and an 64 bit unsigned long long seems still
common.

But with the continuousness constraint on std::string, I'm not sure this
is relevant.

Yours,

 

[Daniel Krügler]

Am 02.12.2011 14:54, schrieb Seungbeom Kim:

On 2011-11-29 22:33, Daniel Krügler wrote:
I agree that it's preferable to use string::size_type instead of size_t,
at least semantically. However, string is defined to be basic_string<char>,
whose size_type is defined to be allocator<char>::size_type, which is
in turn defined to be size_t. Therefore, in this particular (and common)
case, string::size_type is identical to size_t.

You are right, I should have made clearer that my concerns do refer to
programming in template context or any "indirect" context, where you
depend on some type chains. Sometimes I forget that I'm not in such an
"indirect" role ;-)

Of course, there can be other instantiations of basic_string which use
an allocator other than the standard one which defines its size_type
to be a type different from size_t.
Yes.

My question is: in such cases, does an implementation exist where size_type
is bigger than size_t, or can one ever exist?

I'm interpreting your question to refer to general allocators, not to
std::allocator. But when I do this, the term "implementation" makes me
wonder a bit (which in this context can also be read as "Library
implementation"), nonetheless I assume you mean the implementation of
some user-defined allocator, I hope this is what you meant.

On all of not-so-many implementations I have ever
experienced, size_t was the biggest unsigned integer type, so I have
a hard time imagining an unsigned integer type bigger than size_t.

There is no indication in either C or C++ that std::size_t corresponds
to the std::umaxint_t from <cstdint>, size_t typically reflects the
"bitness" of the underlying platfom. On my 32 bit machine gcc 4.7 gives
me the following program compiles successfully:

#include <cstdint>
#include <climits>

constexpr std::uintmax_t c1 = UINTMAX_MAX;
constexpr std::size_t c2 = SIZE_MAX;

static_assert(c1 > c2, "Error");
static_assert(sizeof(std::size_t) * CHAR_BIT == 32, "Error");
static_assert(sizeof(std::uintmax_t) * CHAR_BIT == 64, "Error");

I expect that reflects typical PCs with 32 bit architecture.

HTH & Greetings from Bremen,

Daniel Krügler