Re: [lmi] Re: Input copy ctor

[Greg Chicares]

On 2009-02-26 15:06Z, Vadim Zeitlin wrote:
> 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.

Done 20090226T1557Z, for msvc only (let me know if it doesn't work), because:

> 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).

I wasn't willing to run any realistic risk of perturbing the MinGW gcc
production system, at least not without spending a couple of hours
testing it very carefully--time that would be better spent elsewhere.

One may say that applying this change unconditionally makes the program
less incorrect, because it prevents a demonstrably disastrous behavior
(which however is not observed in production). OTOH, the "magic" function
is a dustbin into which I swept all the appalling cruft in this class's
predecessor (now banished to the cvs attic). I know how that cruft came
into being: I added it, one crufty layer at a time, because it seemed
expedient to compound the problems instead of eradicating them. I am most
anxious not to start repeating that serial mistake.