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

Discussion in 'C++' started by Andrew Tomazos, Nov 28, 2011.

  1. 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 <> <http://www.tomazos.com>


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Andrew Tomazos, Nov 28, 2011
    #1
    1. Advertising

  2. Andrew Tomazos

    Richard Guest

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

    Andrew Tomazos <> spake the secret code
    <> 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! ]
     
    Richard, Nov 29, 2011
    #2
    1. Advertising

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

    On 29/11/11 07:58, Richard wrote:
    > [Please do not mail me a copy of your followup]
    >
    > Andrew Tomazos<> spake the secret code
    > <> 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
     
    Vladimir Jovic, Nov 29, 2011
    #3
  4. Andrew Tomazos

    news Guest

    In comp.lang.c++ Richard <> 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! ]
     
    news, Nov 30, 2011
    #4
  5. Re: C++11 Variadic Templates: Format("I %%% about %%% of%%%","dream", 7, 9) == "I dream about 7 of 9"

    On Nov 29, 7:58 am, (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! ]
     
    Andrew Tomazos, Nov 30, 2011
    #5
  6. 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::eek: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


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Daniel Krügler, Nov 30, 2011
    #6
  7. Andrew Tomazos

    Richard Guest

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

    "news" <> spake the secret code
    <4ed490d1$0$2782$> thusly:

    >In comp.lang.c++ Richard <> 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! ]
     
    Richard, Nov 30, 2011
    #7
  8. size_type and size_t

    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! ]
     
    Seungbeom Kim, Dec 2, 2011
    #8
  9. Re: size_type and size_t

    Seungbeom Kim <> 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! ]
     
    Jean-Marc Bourguet, Dec 3, 2011
    #9
  10. Re: size_type and size_t

    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! ]
     
    Daniel Krügler, Dec 3, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Walters
    Replies:
    2
    Views:
    526
    Ben Pfaff
    Feb 13, 2004
  2. Ross A. Finlayson
    Replies:
    19
    Views:
    604
    Keith Thompson
    Mar 10, 2005
  3. Replies:
    2
    Views:
    351
    Dave Thompson
    Feb 27, 2006
  4. Replies:
    5
    Views:
    367
  5. Andrew Tomazos
    Replies:
    0
    Views:
    259
    Andrew Tomazos
    Nov 28, 2011
Loading...

Share This Page