lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [lmi] Re: Input copy ctor


From: Vadim Zeitlin
Subject: Re[2]: [lmi] Re: Input copy ctor
Date: Thu, 26 Feb 2009 16:06:42 +0100

On Thu, 26 Feb 2009 14:44:05 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2009-02-26 14:26Z, Vadim Zeitlin wrote:
GC> > On Thu, 26 Feb 2009 14:22:14 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Please try the ugly idea in my 2009-02-26T14:10Z message first. If
GC> 
GC> That seems to have "worked" well enough to get us past the immediate
GC> obstacle, so...

 Will you commit this fix to LMI CVS then? I'm asking just to know if I
should wait until it propagates into our bzr repository from the upstream
or if I should maintain it as another local modification.

GC> > GC> that doesn't "fix" the problem, at least well enough to get us past
GC> > GC> the immediate obstacle, then I guess we'll have to transplant some
GC> > GC> of the "magic" into the copy ctor (and operator=() too).
GC> > 
GC> >  The fix is enough for me but I think it would be really better to do it 
in
GC> > copy ctor and operator=() -- why not? After all, the object is supposed to
GC> > be completely and not just partially copied by these functions.
GC> 
GC> Why not? Because I fear we'd be patching around a symptom instead of
GC> confronting the underlying problem, which I think lies deeper.

 I agree but I think that the magical rectification hack still needs to be
self-consistent as long as it exists. I.e. I totally support the long(er)
term goal of getting rid of it completely but for now I think it would be
preferable to avoid omitting some objects fields in copy ctor/assignment
operator as this is very unexpected (especially as it doesn't seem to be
documented anywhere).

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]