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