headers
Robert Jones | 1 May 2012 10:09
Picon

Re: Use boost::shared_ptr with boost::adaptors

On Mon, Apr 30, 2012 at 11:13 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> wrote:
On Mon, Apr 30, 2012 at 3:05 AM, Robert Jones <robertgbjones <at> gmail.com> wrote:
When you put it that way I can see your point, but just from the code the OP presented the intermediate shared_ptr's should persist until
the end of the expression.

I'm not sure what you mean here; do you mean there's a bug on the boost side of the things in the original code listing?

Hmmm...., a bug... no... that might be overstating it I think. From your imagined function it's just an intrinsic limitation of a
pragmatic implementation. But what I meant was that the OP's problematic statement was

 boost::for_each(vec
                        | transformed(bind(&trasform, _1))
                        | indirected,
     bind(&foo::bar, _1));

which is a single expression, so it's reasonable to anticipate that 'temporary' shared_ptrs created in the course of evaluating
this expression should persist until the end of the expression. Ok, I know there's lots of holes in that if you analyse it carefully,
not least that the shared_ptrs in question are not ever explicit, so the rules aren't required to apply, but it might be reasonable to
expect that they would persist.

I'm really not nailing my colours to the mast here, just speculating, so be gentle!

- Rob.


_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 1 comment |
headers
Jeffrey Lee Hellrung, Jr. | 1 May 2012 10:49
Picon

Re: Use boost::shared_ptr with boost::adaptors

On Tue, May 1, 2012 at 1:09 AM, Robert Jones <robertgbjones <at> gmail.com> wrote:
On Mon, Apr 30, 2012 at 11:13 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> wrote:
On Mon, Apr 30, 2012 at 3:05 AM, Robert Jones <robertgbjones <at> gmail.com> wrote:
When you put it that way I can see your point, but just from the code the OP presented the intermediate shared_ptr's should persist until
the end of the expression.

I'm not sure what you mean here; do you mean there's a bug on the boost side of the things in the original code listing?

Hmmm...., a bug... no... that might be overstating it I think. From your imagined function it's just an intrinsic limitation of a
pragmatic implementation.

Okay, just checking!

But what I meant was that the OP's problematic statement was

 boost::for_each(vec
                        | transformed(bind(&trasform, _1))
                        | indirected,
     bind(&foo::bar, _1));

which is a single expression, so it's reasonable to anticipate that 'temporary' shared_ptrs created in the course of evaluating
this expression should persist until the end of the expression. Ok, I know there's lots of holes in that if you analyse it carefully,
not least that the shared_ptrs in question are not ever explicit, so the rules aren't required to apply, but it might be reasonable to
expect that they would persist.

I'm really not nailing my colours to the mast here, just speculating, so be gentle!

I thought this was what you meant, and I sympathize :) It is nontrivial and opaque why that construct will not work, and I'd even agree that it's reasonable to expect it to work. This does leave me with a somewhat unsatisfactory feeling, but...I don't immediately see a satisfactory fix (other than "don't do that") :/

- Jeff

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Lars Viklund | 1 May 2012 14:09
Picon
Picon
Picon
Favicon
Gravatar

Re: async_read_some

On Sat, Apr 28, 2012 at 10:56:49AM +0200, Christer Borgqvist wrote:
> Hi,
> Im playing around with the /boost_asio/example/http/server3
> and using POST method.
> The bytes_transferred is 231, but thats only the header and ends with 
> \r\n\r\n, need to read the rest.
> Sometimes i get bytes_transferred to 1032, the right amount of data,
> sometimes i get bytes_transferred = 231, but if i print the buffer_  i have 
> all the 1032 bytes.
> Is it right that the bytes in the buffer_ and the bytes_transferred is not 
> the same?

Only the first 'bytes_transferred' octets are the ones you asked for,
the rest are indeterminate (or well, likely whatever they were before
you made the read).

The language doesn't know how many of the elements you consider "valid"
or "real", it just knows about the size of the storage. If you've got a
container that fits 1032 bytes, it stays so after the call, as the
read/read_some functions only work with existing dumb storage.

read_some is a low-level function that doesn't give that many promises
in number of bytes read. The reason it's used here is because the length
of a HTTP message or header is unknown and it's happy enough just
reading repeatedly in arbitrary chunks until it has enough to parse the
request.

Last, but not least, TCP is a stream protocol. The chunks you write data
to the connection are not preserved in any way across the stream. When
the data arrives at the recieving end, it's just a boundary-less
sequence of bytes, which your underlying platform tends to give you in
chunks of uncorrelated size.

--

-- 
Lars Viklund | zao <at> acc.umu.se
Permalink | Reply | 0 comments |
headers
Lars Viklund | 1 May 2012 14:12
Picon
Picon
Picon
Favicon
Gravatar

Re: fatal error C1001 with VS2010, boost 1.49, and shared_ptr.hpp

On Mon, Apr 30, 2012 at 11:56:26AM -0600, Phillip Hellewell wrote:
> On Mon, Apr 30, 2012 at 11:14 AM, Phillip Hellewell <sshock <at> gmail.com> wrote:
> >
> > Good news.  Luckily I was able to pinpoint the exact line of code
> > causing VS to crash, and two different workarounds:
> >
> > Crashes VS:
> >        return Foo_ptr(new Foo());
> >
> > Workaround 1:
> >        return boost::shared_ptr<Foo>(new Foo());
> >
> > Workaround 2:
> >        Foo_ptr ret(new Foo());
> >        return ret;
> 
> Oops, I didn't even notice this but the return type on my function is
> Foo_const_ptr (boost::shared_ptr<const Foo>), not Foo_ptr.
> 
> So this is the right fix:
>         return Foo_const_ptr(new Foo());
> 
> I guess VS gets all flustered when:
> 1. Converting an r-value shared_ptr to a non-const object, to a
> shared_ptr to a const object,
> 2. when typedefs are involved,
> 3. in Debug x64 (other configurations weren't crashing).
> 
> There must be some other factors too because when I wrote up a sample
> 10-line program to illustrate the problem, it didn't crash.

Please file a bug over at Connect [1]. ICEs are never good, especially
as this one seems to occur on reasonably well-formed code.

[1] http://connect.microsoft.com/VisualStudio

--

-- 
Lars Viklund | zao <at> acc.umu.se
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Petros | 1 May 2012 20:34
Picon

multiarray sub_array

Hi,
I want to be able to create an array view on a subset of a multi_array(MA)’s dimensions.
So, say I have a MA of dimension M and I want to choose N (N <M) dimensions of it which I put on a boost::array.
Say, I want to keep the entire range for each dimension.
Is there a way to do this in a general fashion, i.e. w/out the use of the subscript operator on the indices object ?
The documentation mentions something like :
 
typedef boost::multi_array< double, 3 > Grid3D;
typedef Grid3D::size_type size_type;
typedef Grid3D::index index;
typedef Grid3D::index_range index_range;
 
typedef Grid3D::array_view<2>::type Slice2D;
index_range r1; //( 0, iMax);
index_range r3; //( 0, kMax);
Grid3D::index_gen indices;
Slice2D sliceJ2 = grid[indices
    [r1]
    [2]
    [r3]
    ];
but this is not sufficient for a generic construction.
 
And also, what is the difference between array_view and subarray ?
 
Thank you very much in advance,
Petros
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Scott Meyers | 2 May 2012 02:25
Favicon

[Boost.Integer] On Win32, boost::uint_t<65>::fast has 64 bits?

The type yielded by boost::uint_t<N>::fast seems pretty clear: "The 
easiest-to-manipulate, built-in, unsigned integral type with at least N 
bits."

But when I run the following program, which prints the number of bits in 
the type returned by boost::uint_t<65>::fast (i.e., a type with at least 
65 bits), I get 64.

#include <iostream>
#include <climits>
#include <boost/integer.hpp>

int main()
{
   std::cout << "boost::uint_t<65>::fast has "
             << CHAR_BIT * sizeof(boost::uint_t<65>::fast)
             << " bits\n";
}

I get the same results with VC10, VC11 beta, and gcc 4.7 on Win32 with 
Boost 1.49.  I must be doing something wrong, right? But what?

Thanks,

Scott
Permalink | Reply | 10 comments |
headers
Ryan Lichtenwalter | 2 May 2012 03:37
Picon
Favicon

multiprecision (/sandbox/big_number/) - pow function

I am using the multiprecision library from /sandbox/big_number
compiling with boost 1.49.0. Specifically, I am using cpp_int.

I can successfully compile and run the following example:

#include <boost/multiprecision/cpp_int.hpp>
using namespace boost::multiprecision;
cpp_int u = 1;
for(unsigned i = 1; i <= 100; ++i)
    u *= i;
std::cout << u << std::endl; // prints 100!

which I obtained from:

https://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

When I add the following code:

cpp_int x;
x = pow( u, 2 );

I receive the following compiler error (g++ 4.1.2):

./boost/boost/multiprecision/detail/functions/pow.hpp: In function
‘void boost::multiprecision::default_ops::eval_pow(T&, const T&, const
U&) [with T = boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, U = int]’:
./boost/boost/multiprecision/detail/default_ops.hpp:1250:
instantiated from ‘void
boost::multiprecision::detail::pow_funct<Backend>::operator()(Backend&,
const Backend&, const Arithmetic&) const [with Arithmetic = int,
Backend = boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >]’
./boost/boost/multiprecision/mp_number.hpp:1089:   instantiated from
‘void boost::multiprecision::mp_number<Backend,
ExpressionTemplates>::do_assign_function_2(const F&, const Exp1&,
const Exp2&, const boost::multiprecision::detail::terminal&, const
boost::multiprecision::detail::terminal&) [with F =
boost::multiprecision::detail::pow_funct<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> > >, Exp1 =
boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::terminal,
boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, true>, void, void>, Exp2 =
boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::terminal,
int, void, void>, Backend =
boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >, bool ExpressionTemplates = true]’
./boost/boost/multiprecision/mp_number.hpp:1084:   instantiated from
‘void boost::multiprecision::mp_number<Backend,
ExpressionTemplates>::do_assign_function(const Exp&, const
mpl_::int_<3>&) [with Exp =
boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::function,
boost::multiprecision::detail::pow_funct<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> > >,
boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, true>, int>, Backend =
boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >, bool ExpressionTemplates = true]’
./boost/boost/multiprecision/mp_number.hpp:973:   instantiated from
‘void boost::multiprecision::mp_number<Backend,
ExpressionTemplates>::do_assign(const Exp&, const
boost::multiprecision::detail::function&) [with Exp =
boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::function,
boost::multiprecision::detail::pow_funct<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> > >,
boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, true>, int>, Backend =
boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >, bool ExpressionTemplates = true]’
./boost/boost/multiprecision/mp_number.hpp:570:   instantiated from
‘void boost::multiprecision::mp_number<Backend,
ExpressionTemplates>::do_assign(const
boost::multiprecision::detail::mp_exp<tag, Arg1, Arg2, Arg3>&, const
mpl_::true_&) [with tag = boost::multiprecision::detail::function,
Arg1 = boost::multiprecision::detail::pow_funct<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> > >, Arg2 =
boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, true>, Arg3 = int, Backend =
boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >, bool ExpressionTemplates = true]’
./boost/boost/multiprecision/mp_number.hpp:95:   instantiated from
‘boost::multiprecision::mp_number<Backend, ExpressionTemplates>&
boost::multiprecision::mp_number<Backend,
ExpressionTemplates>::operator=(const
boost::multiprecision::detail::mp_exp<tag, Arg1, Arg2, Arg3>&) [with
tag = boost::multiprecision::detail::function, Arg1 =
boost::multiprecision::detail::pow_funct<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> > >, Arg2 =
boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u,
true, std::allocator<unsigned int> >, true>, Arg3 = int, Backend =
boost::multiprecision::backends::cpp_int_backend<0u, true,
std::allocator<unsigned int> >, bool ExpressionTemplates = true]’
vcp_translator_test.cpp:24:   instantiated from here
./boost/boost/multiprecision/detail/functions/pow.hpp:89: error:
invalid application of ‘sizeof’ to incomplete type
‘boost::STATIC_ASSERTION_FAILURE<false>’

Different invocations of pow with the arbitrary precision argument as
the base, exponent, or both yield different compiler errors, but all
of them seem to be broken. Am I doing something wrong? Is there some
other fast way to achieve exponentiation with this library?

Thanks,

Ryan
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 2 comments |
headers
Steven Watanabe | 2 May 2012 07:40
Picon

Re: [Boost.Integer] On Win32, boost::uint_t<65>::fast has 64 bits?

AMDG

On 05/01/2012 05:25 PM, Scott Meyers wrote:
> The type yielded by boost::uint_t<N>::fast seems pretty clear: "The
> easiest-to-manipulate, built-in, unsigned integral type with at least N
> bits."
> 
> But when I run the following program, which prints the number of bits in
> the type returned by boost::uint_t<65>::fast (i.e., a type with at least
> 65 bits), I get 64.
> 
> #include <iostream>
> #include <climits>
> #include <boost/integer.hpp>
> 
> int main()
> {
>   std::cout << "boost::uint_t<65>::fast has "
>             << CHAR_BIT * sizeof(boost::uint_t<65>::fast)
>             << " bits\n";
> }
> 
> 
> I get the same results with VC10, VC11 beta, and gcc 4.7 on Win32 with
> Boost 1.49.  I must be doing something wrong, right? But what?
> 

Obviously this isn't going to work unless
the compiler supports a 128-bit int.  I
suppose it would be better to cause a
compile error if there isn't a sufficiently
wide integer type.

In Christ,
Steven Watanabe
Permalink | Reply | 4 comments |
headers
Scott Meyers | 2 May 2012 07:46
Favicon

Re: [Boost.Integer] On Win32, boost::uint_t<65>::fast has 64 bits?

On 5/1/2012 10:40 PM, Steven Watanabe wrote:
> Obviously this isn't going to work unless the compiler supports a
> 128-bit int.  I suppose it would be better to cause a compile error
> if there isn't a sufficiently wide integer type.

That's what it's documented to do.  Here's the full spec for
boost::uint_t<N>::fast :

> The easiest-to-manipulate, built-in, unsigned integral type with at
> least N bits. The parameter should be a positive number. A
> compile-time error results if the parameter is larger than the number
> of bits in the largest integer type.

If I change 65 to 66, the code fails to compile. Can something this
simple really be a bug in the library?  Yes, I know, I could check the
source code, but I'm being lazy right now.  If this is not a clear case
of pilot error, I'll take a look.

Thanks,

Scott
Permalink | Reply | 3 comments |
headers
John Maddock | 2 May 2012 09:21
Favicon

Re: [Boost.Integer] On Win32, boost::uint_t<65>::fast has 64 bits?

> The type yielded by boost::uint_t<N>::fast seems pretty clear: "The 
> easiest-to-manipulate, built-in, unsigned integral type with at least N 
> bits."
>
> But when I run the following program, which prints the number of bits in 
> the type returned by boost::uint_t<65>::fast (i.e., a type with at least 
> 65 bits), I get 64.
>
> #include <iostream>
> #include <climits>
> #include <boost/integer.hpp>
>
> int main()
> {
>   std::cout << "boost::uint_t<65>::fast has "
>             << CHAR_BIT * sizeof(boost::uint_t<65>::fast)
>             << " bits\n";
> }
>
>
> I get the same results with VC10, VC11 beta, and gcc 4.7 on Win32 with 
> Boost 1.49.  I must be doing something wrong, right? But what?

I seem to remember fixing that as a bug fairly recently - what Boost version 
are you using?

John.
Permalink | Reply | 4 comments |

Gmane