Re: [Boost-users] [Multi-Index] crash on iterator copy or assignment
Hi Dominique ________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Dominique Devienne [ddevienne@gmail.com] Enviado el: jueves, 12 de marzo de 2009 21:46 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] [Multi-Index] crash on iterator copy or assignment
On Thu, Mar 12, 2009 at 3:36 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
After filling in enough to make your code compile, it works for me. I've attached what I did. If this works for you, can you post a minimal and complete example that fails?
Hi Steven,
Your example works for me as well, since you've found the same fix my colleague found, which is to write
std::auto_ptr<ByTypeFooIterator> iter_ptr(new ByTypeFooIterator);
instead of
std::auto_ptr<ByTypeFooIterator> iter_ptr = new ByTypeFooIterator;
I was trying to reproduce your problem locally but as usual Steven outdid me :) FWIW, the last line should not compile, and the fact that it does in VS2005 is a compiler bug: http://tinyurl.com/abl9cj Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Thu, Mar 12, 2009 at 3:55 PM, JOAQUIN M. LOPEZ MUÑOZ <joaquin@tid.es> wrote: Hi Joaquín
std::auto_ptr<ByTypeFooIterator> iter_ptr = new ByTypeFooIterator; FWIW, the last line should not compile, and the fact that it does in VS2005 is a compiler bug:
This is getting to be off topic, but I don't really understand why the line above is a bug in fact. I'm not C++ expert for sure, but so far I've assumed that writing "type var = rhs;" was equivalent to "type var(rhs);" and was not really an assignment but a construction in disguise. I'm surprised that the compiler would prefer the non-explicit Ctor taking the ref, which implies an implicit builtin conversion of ByTypeFooIterator* to void* and a non-builtin implicit conversion of the void* to auto_ptr_ref, to the explicit auto_ptr Ctor that perfectly matches the signature of the arg to the declared auto_ptr. Does using the explicit keyword precludes the "type var = rhs;" <==> "type var(rhs);" equivalence that I've assimilated (incorrectly?) into my mental model of C++? If someone could shed some light on this for me, I'd appreciate, so I can avoid repeating this mistake and possibly correct my understanding of these "initialization assignments". Thanks, --DD template<class _Ty> class auto_ptr { ... explicit auto_ptr(_Ty *_Ptr = 0) ... { ... } auto_ptr(auto_ptr_ref<_Ty> _Right) ... { ... } ... };
Dominique Devienne:
Does using the explicit keyword precludes the "type var = rhs;" <==> "type var(rhs);" equivalence that I've assimilated (incorrectly?) into my mental model of C++?
Yes. T x = v; causes an implicit conversion of v to T, with which x is then copy-constructed. This is routinely optimized to T x( v ); but the compiler is still required to check for the presence of an implicit conversion (which 'explicit' prevents) and an accessible copy constructor.
Peter Dimov wrote:
T x = v; causes an implicit conversion of v to T, with which x is then copy-constructed.
I've started routinely writing T x(v); and then changing it when a target compiler misreads it as a scoped function declaration. :-( I would be very pleased if C++0x kills off The Most Vexing Parse.
Nat Goodspeed wrote:
Peter Dimov wrote:
T x = v; causes an implicit conversion of v to T, with which x is then copy-constructed.
I've started routinely writing
T x(v);
and then changing it when a target compiler misreads it as a scoped function declaration. :-(
I would be very pleased if C++0x kills off The Most Vexing Parse.
Doesn't T x((v)); avoid that problem? Jeff
Jeff Flinn wrote:
I've started routinely writing
T x(v);
and then changing it when a target compiler misreads it as a scoped function declaration. :-(
Doesn't T x((v)); avoid that problem?
I'll try that next time I bump into it -- thanks!
Nat Goodspeed:
Peter Dimov wrote:
T x = v; causes an implicit conversion of v to T, with which x is then copy-constructed.
I've started routinely writing
T x(v);
and then changing it when a target compiler misreads it as a scoped function declaration. :-(
I would be very pleased if C++0x kills off The Most Vexing Parse.
In C++0x one would be encouraged to use T x{v};
participants (5)
-
Dominique Devienne -
Jeff Flinn -
JOAQUIN M. LOPEZ MUÑOZ -
Nat Goodspeed -
Peter Dimov