http://d.puremagic.com/issues/show_bug.cgi?id=5058



--- Comment #7 from Peter Alexander <peter.alexander...@gmail.com> 2010-10-27 
23:52:41 PDT ---
(In reply to comment #4)
> All it takes is assigning to a public member variable or a reference to 
> private
> member data, and you can invalidate an invariant. Granted, having an invariant
> with a type where you can do that, isn't necessarily the best idea, but it's
> quite possible to have a type where you have an invariant and it's invalid
> before opAssign() (or any public function) is called, and, unlike most public
> functions, there's no need for the invariant to be true before opAssign() is
> called.

1. The whole point of invariant is to ensure that invariants are always true.
If your class allows people to invalidate the invariant by assigning to public
member variables then the class is outright broken and you need to fix it. In
this case the invariant will fire (before opAssign or any other function),
which is correct and desired behaviour.

2. As I explained above, there is a need for the invariant to be true before
opAssign in the case where objects have resources to release prior to building
up the new value.


> Of course, what would really help here would be proper default constructors 
> for
> structs, but no one has been able to figure that one out yet it seems.

I agree with this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to