----- Original Message ----- From: "Gennaro Prota" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 9:26 AM Subject: [boost] Re: Boost Array: read/write access to entire data
> On Wed, 6 Nov 2002 16:21:34 -0300, "Fernando Cacciola" > <[EMAIL PROTECTED]> wrote: > > > >OK, my fault. > >I wasn't thinking of directly using StrongStorage<T>... > >I was thinking of borrowing its idea, so I meant that using some variation > >of the double-buffer technique, you could achieve no-throw. Though I should > >have said so explicitely, sorry. > > > Yeah, I understood that (I'm not so 'inelastic'! :-). However your > insistence on no-throw made me go to the original code to show that > not even there there's a no-throw guarantee. Of course, I agree with > you that the technique allows us to have the strong guarantee. > OK. I see. > [...] > Well, I agreed with you since the beginning that the technique is > useful for the strong guarantee. I hope that's clear now. My objection > concerned "no throw". > I still 'feel' like it would allow a no-throw swap, but I'll stop insisting on it until I have a realistic implementation that proves it. > > > >Now, without the double buffer, my only answer to the question above *would* > >be the 'traditional' implementation I've shown. However, even that doesn't > >work because the restore cannot be made to succeed, AFAICT, in the presence > >of throwing copy ctor. > > > >So, since *I* do not have a clue about how to implement a swap with at least > >strong guarantees without the double buffer, I propose it. > >However, you or someone else might know how to do the same without this > >complicated scheme (and without relying on the presence of a no-throw T's > >swap). In that case, though, I will love to hear about it. > > > I don't know either. However I'm still not convinced that a strongly > exception-safe swap is really useful for an array-like class like > that. I'm not saying it isn't, only that I'm not convinced it is. Do > you have any example that can make me change my mind? > Good point. It is reazonable to try to determine how practically useful it would be. Personally, I can't think of a swap() which doesn't give at least the strong guarantee. This is because of the way I use 'swaps' and because most of the times swaps yield at least the strong guarantee. For example, I like to swap sequences to instrument transactional semantics in updating/modifying code: I do the changes in a local sequence and if everthing went right, I swap the real and the temporary sequences to commit the state. This idiom won't work if the sequence swap gives just the basic guarantee -or less-, because 'preserving the consistency within the final sequence' is not enough; I also need the changes to be fully commited. In my typical code, not having the changes fully commited is usually as disasterous as leaving the sequence inconsistent. Anyway, no-throw is not really required in this scenario. > > >> > if ( storage_initialized_[mirror_idx] ) > >> > lhs_mirror->~T(); > >> > >> Who says you that you can invoke the destructor on all the N elements? > > > >This code is destructing the element which has been previously stored in the > >'mirror' storage. > > I think you missed my point. You don't know how many Ts have been > successfully constructed in the storage. Let's say N=8 and the 3rd > copy constructor fails: you must destroy only the first 2 elements. > But that was a minor note that I had better left aside considering the > extemporaneousness of the code. Furthermore that's trivial to fix by > preserving the value of i and looping backward. > OK, I did miss your point. Now I got it, and you were right :-) > > Ok so far. Now that we have understood each other it's time for > another problem :-) Can you think of a situation where a swap between > arrays with different values of N is useful? I think that swaps between arrays of different sizes is quite useful for transactional updates. > That adds special cases > to the code, of course: suppose e.g. you want to swap an array<T, 10> > that happens to have 12 elements and an array<T, 15> that has 5 > elements. It's easy but you have to stuff the code with several ifs. Good example. I didn't think of a mixed case like this. > And that's one of the aspects I was thinking to when saying that a) > I'm not sure there's a remarkable gain in performance (of course there > can be for some values of N but... maybe on your platform only, maybe > for some scenarios only... a complex story IMHO) and b) if a gain > exists, if it is worth the complexity. > > > Also note that, in the end, the user can only count on the strong > guarantee for swap. One wants to know in compile-time what are the > guarantees, of course. Our array<T, N>::swap() instead offers > different guarantees depending on whether it has more than N elements > or not. Obviously this means that, generally, the designer of the > client code will rely on the weakest of the two. > Agreed. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
