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