headers
Maarten Kronenburg | 1 Jun 2006 02:09
Picon
Favicon

Re: Infinite precision integer draft

There is another solution:
in the binary integer operators
the lhs or rhs is cloned,
but not the derived member
operators are called, but the
integer ones.
This seems reasonable as the
binary integer operators return
integers by value anyway.
Also the unary operator- returns
integer by value, and can call the
integer negate(), not the derived one.
Only when the result is assigned,
the derived operator=( const integer & )
is called, which converts the integer
back to the derived class,
and in the case of unsigned_integer,
throw an exception when the result
is negative.
This solves our unsigned_integer problem.
There is however one price: efficiency.
For example for modular_integer,
the temporary results are never made
modular, so may become larger than
when the derived member operators
would have been called.
So this is another dilemma.
But as those integer arithmetic binary
and unary operators return integer by value
anyway, in my opinion the integer member
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Witt | 1 Jun 2006 02:47
Picon
Favicon

Re: Bug list status

AlisdairM wrote:
> Marshall Clow wrote:
> 
>> <http://sourceforge.net/tracker/index.php?func=detail&aid=1480954&grou
>> p_id=7586&atid=107586>
>>
>> Assignee:     	nobody
>> Summary:      	insignificant boost::array bug
>> Bug #:        	1484104 
> 
> 
> That should be assigned to me.
> The problem is actually bigger than stated in the report - we handle
> zero sized arrays really badly today!
> 
> Thomas:  Are we prepared to allow an update to fix this for 1.34, or
> should I simply patch head and wait for 1.35?  The resolution is to
> partially specialize array for N == 0, which is effectively doubles the
> size of this class!  Plus we will need test cases.  OTOH, the code
> itself is fairly straight forward, and knocks some bugs off the TR1
> list, with TR1 being the big selling point of 1.34 for me ;?)

Go ahead and do it for 1.34.0 as well if you feel confident and have a test.

Thomas

--

-- 
Thomas Witt
witt <at> acm.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Kohlhoff | 1 Jun 2006 02:56
Favicon

Re: [tr2][filesystem][asio] header <boost/system_error.hpp> roadmap?


David Abrahams <dave <at> boost-consulting.com> wrote:
> Beman Dawes <bdawes <at> acm.org> writes:
> > What should the roadmap be for moving this header into Boost?
> >
> > Should it be a separate library? Seems smallish for that.
> >
> > Does it need a formal review? A mini-review?
> >
> > Is it OK if I put in CVS now in boost/detail?
> >
> > Opinions?
>
> As long as it is an implementation detail of other libraries,
> it can live in boost/detail.  If it's to be a public
> interface, it should get a review (mini, IMO).

The types would be definitely part of the public interface of
asio at least (i.e. error_code parameters on sync functions and
callback function objects), so I guess that would mean a review.

Is it feasible to get a review done in time for including this
stuff in 1.35? I want to avoid changing the asio public interface
after it goes out in a boost release, and switching error types
is likely to be a breaking change.

Cheers,
Chris

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Kohlhoff | 1 Jun 2006 03:20
Favicon

Re: Endian library - request for comments

Hi Beman,

Beman Dawes <bdawes <at> acm.org> wrote:
> That said, I guess there could be an argument to expose the
> templates for those who prefer them.

Here's an argument for exposing templates: it allows the
template parameter to propagate up into my own types. I'm
thinking something like:

  template <typename Endianness>
  struct my_message
  {
    integer<4, Endianness> foo;
    integer<2, Endianness> bar;
    ...
  };

This permits me to write one function template to handle
my_message structures in programs that need to deal with both
little- and big-endian at runtime (i'm thinking "receiver makes
right" protocols).

With this scheme there should probably also be a type for native
endianness so we could write:

  my_message<endian::big> msg1;
  my_message<endian::little> msg2;
  my_message<endian::native> msg3;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marsh J. Ray | 1 Jun 2006 04:22

Re: Endian library - request for comments

Beman Dawes wrote:
>  Rene Rivera wrote:
> > int_be8_t
> > int_le8_t
> > uint_be8_t
 >> uint_le8_t

I like it.

>  int_b1_t
>  int_l1_t
>  uint_b1_t
>  uint_l1_t

I'd vote to keep the 'e'.

On many fonts/displays the lowercase 'L'  and digit one are nearly 
indistinguishable. While this probably isn't an overriding concern in 
the naming of most identifiers, consider how commonly-used the 'l1' or 
'l16' versions would be. Also, 'll' is likely to be used as a prefix for 
"long long".

>
>  I tried it both ways over the years. The problem with using bit sizes
>  is that a programmer is often counts these things, and always in
>  terms of bytes. Bytes is just more convenient than bits.
>  <>
>  Also, working in terms of bytes seems to signal to readers that
>  something special is going on - int_b32_t is more likely to be
>  mistakenly viewed as just another typedef for an int32_t than bin4 or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Bonner | 1 Jun 2006 10:47

Re: Infinite precision integer draft

----Original Message----
From: boost-bounces <at> lists.boost.org
[mailto:boost-bounces <at> lists.boost.org] On Behalf Of Maarten Kronenburg
Sent: 31 May 2006 21:25 To: boost <at> lists.boost.org
Subject: Re: [boost] Infinite precision integer draft

> This problem with unsigned_integer
> throwing an exception when negative
> is already apparent for the two
> expressions
> a-b
> and
> -a+b  [presumably -b+a is intended]
[snip]

> a true unsigned infinite precision integer
> which may or may not throw exceptions in
> equivalent expressions

But those expressions are not equivalent for non-negative integers.

a-b is defined as the value x such that b+x is equal to a.

For non-negative integers that means a-b is only defined if a >= b.

I would argue that -a is not really meaningful for non-negative
integers, but the most obvious definition is that -a is the value x such
that a+x = 0.  That is only defined for a = 0 (and gives x=0).

Thus your first expression is defined for any b <= a, whereas your
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gerhard Wesp | 1 Jun 2006 10:58
Picon
Favicon

Re: Infinite precision integer draft

On Wed, May 31, 2006 at 05:35:16PM -0500, Daniel Mitchell wrote:
> already been said, but I fail to see the point of having an unsigned_integer. 

So do I.

Regards
-Gerhard
--

-- 
Gerhard Wesp
ZRH office voice: +41 (0)44 668 1878
ZRH office fax: +41 (0)44 200 1818
For the rest I claim that raw pointers must be abolished.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2006 13:09
Picon
Favicon

[Boost-bugs] [ boost-Bugs-1498778 ] operator<< for gregorian::date_duration not found

Bugs item #1498778, was opened at 2006-06-01 12:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1498778&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: date_time
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zak Kipling (zak-k)
Assigned to: Jeff Garland (az_sw_dude)
Summary: operator<< for gregorian::date_duration not found

Initial Comment:
The operator<< for boost::gregorian::date_duration (aka
gregorian::days) is not found by name lookup. This
appears to be because:

* boost::gregorian::date_duration is a typedef to:

    boost::date_time::date_duration<
boost::gregorian::date_duration_rep >

   where boost::gregorian::date_duration_rep is a
typedef to boost::date_time::duration_traits_adapted
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Stokes | 1 Jun 2006 13:07
Picon

Random: exponential_dsitribution requires a [0, 1) engine?

Maybe I'm missing something, but the implementation of the exponential
dsitribution looks like this:

  template<class Engine>
  result_type operator()(Engine& eng)
  {
    return -result_type(1) / _lambda * log(result_type(1)-eng());
  }

That seems to assume that the Engine has a rane of [0, 1). Certainly
if I pass it in (say) a mt19937 engine it goes rather badly wrong,
attempting to take the log of a large negative number.

But the documentation contains no such requirement - it merely says it
needs a UniformRandomNumberGenerator, which explicitly allows for any
range.

- Alan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Jun 2006 13:36
Picon
Picon
Favicon
Gravatar

Re: Infinite precision integer draft

"Maarten Kronenburg" <M.Kronenburg <at> inter.nl.net> writes:

> Stefan,
> Templates provide compile-time
> polymorphism, while derivation provides
> run-time polymorphism.
> For using mixed expressions with
> different types, run-time polymorphism
> is required.

No, that's why we have templates.  In fact, runtime polymorphism
breaks down horribly with mixed type expressions.  I suggest you
google "binary method problem" to see why.

Maarten, I may be speaking too soon because admittedly I have not
followed every message in this thread, but at this point it looks to
me like several of your proposed design choices are so far from what
this group would be likely to accept that there would be little point
in bringing such a library for review.  It also seems as though you'd
benefit more by trying to learn from your fellow Boosters than by
arguing with them.  I suggest you try to adopt a different approach.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 1 comment |

Gmane