f



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

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.

-- 
Andrew Tomazos <andrew@tomazos.com> <http://www.tomazos.com>


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
andrew3888 (273)
11/28/2011 10:31:51 PM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

9 Replies
671 Views

Similar Articles

[PageSpeed] 23

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

Andrew Tomazos <andrew@tomazos.com> spake the secret code
<8ce7855d-ade8-4d83-ad8e-9fec2266c72b@b32g2000yqn.googlegroups.com> thusly:

>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/>
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
jeeves (202)
11/29/2011 6:58:16 AM
On 29/11/11 07:58, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Andrew Tomazos<andrew@tomazos.com>  spake the secret code
> <8ce7855d-ade8-4d83-ad8e-9fec2266c72b@b32g2000yqn.googlegroups.com>  thusly:
>
>> 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
0
vladaspams2 (160)
11/29/2011 1:16:30 PM
In comp.lang.c++ Richard <legalize+jeeves@mail.xmission.com> wrote:
> 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.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
11/30/2011 6:24:10 AM
On Nov 29, 7:58 am, legalize+jee...@mail.xmission.com (Richard) wrote:
> 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.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
andrew3888 (273)
11/30/2011 6:26:28 AM
On 2011-11-28 23:31, Andrew Tomazos wrote:
> 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::ostream& 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


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
11/30/2011 6:33:56 AM
[Please do not mail me a copy of your followup]

"news" <newsmaster@tdcnet.fi> spake the secret code
<4ed490d1$0$2782$7b1e8fa0@news.nbl.fi> thusly:

>In comp.lang.c++ Richard <legalize+jeeves@mail.xmission.com> wrote:
>> 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.

See
<http://www.boost.org/doc/libs/1_48_0/tools/bcp/doc/html/index.html>
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
jeeves (202)
11/30/2011 8:45:48 PM
On 2011-11-29 22:33, Daniel Kr�gler wrote:
> 
>>         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).

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.

-- 
Seungbeom Kim


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
musiphil (33)
12/2/2011 1:54:26 PM
Seungbeom Kim <musiphil@bawi.org> writes:

> 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,

-- 
Jean-Marc


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
jm749 (345)
12/3/2011 6:33:41 AM
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


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
12/3/2011 6:35:00 AM
Reply: