Boris Zbarsky [:bzbarsky] Reporter
	Description • 18 years ago

I see no reason why the copy constructor of nsAutoPtr and the  nsAutoPtr(Ptr) constructor need to be implicit.  And apparently, the fact that they are causes some sort of issues with code like:

  nsAutoPtr<SortKey> key = new SortKey;

(because we get an explicit constructor on the RHS, then the operator= that takes nsAutoPtr is used, and then apparently something breaks with some compilers).

	Peter Van der Beken [:peterv]
	Comment 1 • 18 years ago

I'm not sure that that solves the problem of |nsAutoPtr<SortKey> key = new SortKey;|, the exact error message that it gives is:

error: conversion from 'txNodeSorter::SortKey*' to non-scalar type 'nsAutoPtr<txNodeSorter::SortKey>' requested

I could swear we had a bug about it at some point, but can't find it now.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 2 • 18 years ago

what breaks is probably that it constructs the left-hand autoptr by converting the temporary one for the right hand one to a T*, which would be bad. This sounds familiar to me... bug 316782 comment 37 perhaps?

why does that line use operator=? it shouldn't...

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 3 • 18 years ago

oh, you want that line of code to work?

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 4 • 18 years ago

(with explicit constructors that line will definitely fail to compile)

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 5 • 18 years ago

Either the line should work, or it should fail to compile on all compilers.

IIRC some compiler failed to compile that properly, so our only option is to make it fail to compile everywhere.