Boost logo

Boost :

Subject: Re: [boost] [XInt] Some after thoughts
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2011-03-10 17:01:52


On 3/10/2011 11:14 AM, Simonson, Lucanus J wrote:
[...]
> Throughout this review I never saw anyone make the case for COW that seems most relevant to me.

Agreed.

> Most usage of built in integer types in a generic context uses pass by value explicitly rather than using the type traits.

I'm guessing you mean call_traits, right?

> This means that libraries like ratio and random or whatever else will probably pass multi-precision integer types by value in all of their functions.

Yes, that's unfortunate.

> COW is the only way to mitigate all that copying around.

Well...not the only way, but the least intrusive way.

> Perhaps this was so obvious or covered so early in the review that it went unstated recently, but I think ET on COW enabled (or COW+move enabled) objects is a perfectly valid design choice.

I agree that the above example is actually a valid *and* compelling
argument for CoW.

However, as I've stated before, I believe any CoW infrastructure would
be best built on top of a non-CoW infrastructure, since non-CoW indeed
has its own advantages, and building a non-CoW infrastructure on top of
a CoW infrastructure likely compromises many of the non-CoW advantages.

> We need ET code to have access to the low level algorithms so that it can make optimizations such as stack allocation of temporaries, of course. It is cleaner if the library providees a good interface for that access.

Agreed.

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk