Hi Gennadiy,

Yes I would like to know  how I need to write my own main in this case?

Also I was wondering if there is any workaround that was found other than re-writing the main?

Thanks,
Deepa

Here is what I am trying to do, may not be the best way, but trying to re-run the test suite ts1 - 3 consecutive times to test for repeatability:

bool init_unit_test_suite(int argc, char **argv)
    {
        test_suite* ts1 = BOOST_TEST_SUITE( "SKUResourcesTestSuite" );
        ts1->add( BOOST_TEST_CASE(&TestCase1) );
        ts1->add( BOOST_TEST_CASE(&TestCase2) );
        framework::master_test_suite().add( ts1 );

        for(int i = 0;i < 3;i++)
        {
            framework::master_test_suite().add( ts1 );
        }
       
        return true;

    }


Deepa S <mslvada <at> yahoo.com> writes:

> Wanted to check if there was any resolution to the error indicated
> in this post:
> http://lists.boost.org/boost-users/2010/06/59564.php
>
> I am running into a similar issue and would like to know how to resolve it.

What exactly is the issue?
Do you want to write your own main?

Gennadiy



On Monday, February 10, 2014 10:30 PM, "boost-users-request@lists.boost.org" <boost-users-request@lists.boost.org> wrote:
Send Boost-users mailing list submissions to
    boost-users@lists.boost.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.boost.org/mailman/listinfo.cgi/boost-users
or, via email, send a message with subject or body 'help' to
    boost-users-request@lists.boost.org

You can reach the person managing the list at
    boost-users-owner@lists.boost.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost-users digest..."


Today's Topics:

  1. Re: Regarding post: Using Boost.Test in Iteration
      (Gennadiy Rozental)
  2. [container.string] why isn't memcpy used in the    internals?
      (Adam Romanek)
  3. Re: [container.string] why isn't memcpy used in the
      internals? (Ion Gazta?aga)
  4. [property_tree] Compilation Problem when #including
      <boost/property_tree/json_parser.hpp> (Adi Shavit)
  5. Re: [property_tree] Compilation Problem when    #including
      <boost/property_tree/json_parser.hpp> (Edward Diener)


----------------------------------------------------------------------

Message: 1
Date: Mon, 10 Feb 2014 07:16:06 +0000 (UTC)
From: Gennadiy Rozental <rogeeff@gmail.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Regarding post: Using Boost.Test in
    Iteration
Message-ID: <loom.20140210T081523-687@post.gmane.org>
Content-Type: text/plain; charset=us-ascii

Deepa S <mslvada <at> yahoo.com> writes:

> Wanted to check if there was any resolution to the error indicated
> in this post:
> http://lists.boost.org/boost-users/2010/06/59564.php
>
> I am running into a similar issue and would like to know how to resolve it.

What exactly is the issue?
Do you want to write your own main?

Gennadiy



------------------------------

Message: 2
Date: Mon, 10 Feb 2014 09:18:20 +0100
From: Adam Romanek <romanek.adam@gmail.com>
To: "boost-users@lists.boost.org" <boost-users@lists.boost.org>
Subject: [Boost-users] [container.string] why isn't memcpy used in the
    internals?
Message-ID: <52F88B4C.40707@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi!

Recently I've been trying to improve the performance of a code that
makes heavy use of std::string (lots of constructions and destructions).
My first thought was to use boost::container::string as it does not use
reference-counting and uses small-string optimization, so it should be a
perfect replacement for std::string when it comes to performance.

Right... But the problem is that switching to boost::container::string
only made things worse in the general case. I wrote "in the general
case" because when strings to be held are small and SSO may be applied
then boost::container::string outperforms std::string considerably.
However, in the general case constructing boost::container::string from
a C string is significantly slower than constructing std::string.

My investigation showed that std::string uses memcpy to copy the C
string into its buffer while boost::container::string does not. The
memcpy comes from std::char_traits::copy so maybe
boost::container::string could use it too? I guess the rest of
operations from std::char_traits (find, move, assign etc.) could be
utilized too as std::char_traits has been carefully crafted with
performance in mind.

Should I create a ticket for this issue?

Best regards,
Adam Romanek



------------------------------

Message: 3
Date: Mon, 10 Feb 2014 09:54:36 +0100
From: Ion Gazta?aga <igaztanaga@gmail.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [container.string] why isn't memcpy used in
    the    internals?
Message-ID: <52F893CC.8020703@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

El 10/02/2014 9:18, Adam Romanek escribi?:
> Hi!
>
> Recently I've been trying to improve the performance of a code that
> makes heavy use of std::string (lots of constructions and destructions).
> My first thought was to use boost::container::string as it does not use
> reference-counting and uses small-string optimization, so it should be a
> perfect replacement for std::string when it comes to performance.
>
> Right... But the problem is that switching to boost::container::string
> only made things worse in the general case. I wrote "in the general
> case" because when strings to be held are small and SSO may be applied
> then boost::container::string outperforms std::string considerably.
> However, in the general case constructing boost::container::string from
> a C string is significantly slower than constructing std::string.
>
> My investigation showed that std::string uses memcpy to copy the C
> string into its buffer while boost::container::string does not. The
> memcpy comes from std::char_traits::copy so maybe
> boost::container::string could use it too? I guess the rest of
> operations from std::char_traits (find, move, assign etc.) could be
> utilized too as std::char_traits has been carefully crafted with
> performance in mind.
>
> Should I create a ticket for this issue?

Yes, please. I'm slowly trying to benchmark and improve Boost.Container
performance, I haven't started optimizing basic_string so your ticket
could be a good start point.

In a quick inspection I see that the constructor is dispatched to
basic_string::assign(It, It) and that assignment is not optimized at
all. I should definitely write a assignment function that dispatches to
std::char_traits::copy, as it could be used to optimize several member
functions.

Best,

Ion


------------------------------

Message: 4
Date: Mon, 10 Feb 2014 12:29:39 +0200
From: Adi Shavit <adishavit@gmail.com>
To: boost-users@lists.boost.org
Subject: [Boost-users] [property_tree] Compilation Problem when
    #including    <boost/property_tree/json_parser.hpp>
Message-ID:
    <CAEWUs4h_ExtG5fG9L=x2p0hss_f=r_eVyrwoPaTN-RYyJPcH0g@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

  On VS2010, the following code does not compile if I restore the commented
out #include:

*// #include <boost/property_tree/json_parser.hpp>*

struct X
{
    enum Labels { ERROR, ONE, TWO, THREE };
    // problem => ^^^^^
};

void f()
{
  X::Labels r = X::ERROR;
  // problem =>    ^^^^^
}

The VS2010 errors are:

t.cpp(5): error C2059: syntax error : 'constant'
t.cpp(5): error C2143: syntax error : missing ';' before '}'
t.cpp(5): error C2238: unexpected token(s) preceding ';'
t.cpp(7): error C2059: syntax error : '}'
t.cpp(7): error C2143: syntax error : missing ';' before '}'
t.cpp(7): error C2059: syntax error : '}'
t.cpp(11): error C2589: 'constant' : illegal token on right side of '::'
t.cpp(11): error C2059: syntax error : '::'


It seems that somewhere inside the #include hierarchy the symbol ERROR is
#defined to cause this code to fail.
Renaming ERROR to something else avoids this problem.

I think I tracked it into '
boost/spirit/home/classic/iterator/impl/file_iterator.ipp' but I'm not sure
where exactly it is coming from.

Adi
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 5
Date: Mon, 10 Feb 2014 10:47:10 -0500
From: Edward Diener <eldiener@tropicsoft.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [property_tree] Compilation Problem when
    #including <boost/property_tree/json_parser.hpp>
Message-ID: <ldas9j$3ra$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 2/10/2014 5:29 AM, Adi Shavit wrote:
> Hi,
>
>    On VS2010, the following code does not compile if I restore the
> commented out#include:
>
>    *// #include <boost/property_tree/json_parser.hpp>*
>
>    struct X
>    {
>          enum Labels { ERROR, ONE, TWO, THREE };
>          // problem => ^^^^^
>    };
>
>    void f()
>    {
>        X::Labels r = X::ERROR;
>        // problem =>    ^^^^^
>    }
>
> The VS2010 errors are:
>
>    t.cpp(5): error C2059: syntax error : 'constant'
>    t.cpp(5): error C2143: syntax error : missing ';' before '}'
>    t.cpp(5): error C2238: unexpected token(s) preceding ';'
>    t.cpp(7): error C2059: syntax error : '}'
>    t.cpp(7): error C2143: syntax error : missing ';' before '}'
>    t.cpp(7): error C2059: syntax error : '}'
>    t.cpp(11): error C2589: 'constant' : illegal token on right side of '::'
>    t.cpp(11): error C2059: syntax error : '::'
>
>
> It seems that somewhere inside the #include hierarchy the symbol ERROR
> is #defined to cause this code to fail.
> Renaming ERROR to something else avoids this problem.

I do not know where ERROR is occuring. But it is certainly not a good
idea to have an enumeration name be a common all-uppercase name.

>
> I think I tracked it into
> 'boost/spirit/home/classic/iterator/impl/file_iterator.ipp' but I'm not
> sure where exactly it is coming from.



------------------------------

Subject: Digest Footer

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

------------------------------

End of Boost-users Digest, Vol 3709, Issue 1
********************************************