Re: [boost] Re: Boost Array Initialization Technique
In-Reply-To: <20050601173608.GA77601@compsoc.man.ac.uk> cow@compsoc.man.ac.uk (Jonathan Wakely) wrote (abridged):
Actually, it's moot because it's been semi-standardised in TR1, not because you now understand the design goals ;)
Really? My impression was that TR1 had not been reviewed in detail. When the hashing library was submitted to boost, I understood it to be the same as TR1 yet we found several problems with it. We did not blindly accept it just because it was in TR1. -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
In-Reply-To: <20050601173608.GA77601@compsoc.man.ac.uk> cow@compsoc.man.ac.uk (Jonathan Wakely) wrote (abridged):
Actually, it's moot because it's been semi-standardised in TR1, not because you now understand the design goals ;)
Really? My impression was that TR1 had not been reviewed in detail. When the hashing library was submitted to boost, I understood it to be the same as TR1 yet we found several problems with it. We did not blindly accept it just because it was in TR1.
Work on TR1 is finished. The hash library is not part of TR1. Jonathan
Jonathan Turkanis wrote:
Dave Harris wrote:
Really? My impression was that TR1 had not been reviewed in detail. When the hashing library was submitted to boost, I understood it to be the same as TR1 yet we found several problems with it. We did not blindly accept it just because it was in TR1.
Work on TR1 is finished. The hash library is not part of TR1.
I haven't been following this thread, and Dave's email program has broken the threading, so I'm missing the context here. But std::hash is specified in section 6.3.2 of TR1 (a little confusing as it's in the header <functional> but specified in the container section). None of Dave's objections to Boost.Hash applied to the TR1 specification, all of them were with the implementation or the extensions. And I think the distinction was pretty clear. Daniel
Daniel James wrote:
Jonathan Turkanis wrote:
Dave Harris wrote:
Really? My impression was that TR1 had not been reviewed in detail. When the hashing library was submitted to boost, I understood it to be the same as TR1 yet we found several problems with it. We did not blindly accept it just because it was in TR1.
Work on TR1 is finished. The hash library is not part of TR1.
I haven't been following this thread, and Dave's email program has broken the threading, so I'm missing the context here. But std::hash is specified in section 6.3.2 of TR1 (a little confusing as it's in the header <functional> but specified in the container section). None of Dave's objections to Boost.Hash applied to the TR1 specification, all of them were with the implementation or the extensions. And I think the distinction was pretty clear.
Sorry for being unclear. I was talking the extensions. Jonathan
On Sun, Jun 05, 2005 at 06:10:00PM +0100, Dave Harris wrote:
In-Reply-To: <20050601173608.GA77601@compsoc.man.ac.uk> cow@compsoc.man.ac.uk (Jonathan Wakely) wrote (abridged):
Actually, it's moot because it's been semi-standardised in TR1, not because you now understand the design goals ;)
Really? My impression was that TR1 had not been reviewed in detail. When
I don't think that's true, see the issues list for a lot of discussion. I'm most familiar with the shared_ptr bits and there were lots of issues raised about the design, many of which Peter Dimov had an instant reply to, since the design and implementation were mature and he had already thought about most of it before work began on TR1. Even so, Christopher was proposing adding user-defined ctors to boost::array, which would be completely incompatible with std::tr1::array and would make aggregate initialisation impossible.
the hashing library was submitted to boost, I understood it to be the same as TR1 yet we found several problems with it. We did not blindly accept it just because it was in TR1.
I didn't mean to suggest that, although I do believe there has been a consensus not to introduce needless incompatibilities between TR1 components and the Boost libraries that inspired them. jon
participants (1)
-
brangdon＠cix.compulink.co.uk -
Daniel James -
Jonathan Turkanis -
Jonathan Wakely