RE: [litwindow-users] m_current as a pointer

[yrs90 <yr...@ya...>]

> I wonder if m_current as a pointer into the underlying data is
> causing a circular reference somewhere during change resolution.

I see now.  When m_current is made a pointer that points into the underlying
data, the notification process does enter a death loop.  Of course, the nice
thing about the originally implementation is precisely that it was an
independent object being monitored for changes, just like any other object
for which a rule is defined.

I considered several different options:
a) change my container to permit copying
b) add a specializable assignment template like type_traits
c) create m_current with a copy constructor version of create_object()
d) figure out how to break the recursive loop when m_current points into a
container.

The first three options use m_current as defined originally.  The last
option changes m_current into a pointer to an accessor.

a) change my container to permit copying

I considered several ways to do this, but I can't see a way to accomplish
this. Overriding the key alone isn't sufficient because it's still going to
be a constant.  I would like to override pair<>, but I don't know how to get
map<> to use the pair<> derivative unless I reimplement map<> (not
desirable).  I can't just specialize pair<>::operator= (say, with a delete
and recreate using the copy constructor) because it doesn't have an
operator=() for me to override in pair<>.

b) add a specializable assignment template like type_traits

This doesn't get around the inability to copy a constant member.  However,
this would keep the framework general while still allowing the user to
specialize the assignment so that, in my case, perhaps I only copy the value
and not the key.

This would require that I define my adapter as permitting copy.  I presume
this is okay, but I am concerned that somewhere in the framework it might
copy data into the container rather.  If it's only going to be used in
m_current then a partial copy won't be problem.

c) create m_current with a copy constructor version of create_object()

This seems like a more complete work-around for the need to use the
copy-constructor for constant member initialization.  On the other hand, I
don't know if it actually increases or decreases compatibility by moving the
requirement from operator= to copy-constructor being defined.

d) figure out how to break the recursive loop when m_current points into a
container.

This sounds like a great solution, but I don't understand the code well
enough to pursue this yet.


So what I actually pursued to completion was (b), just adding an
assign<Type>::operator()(dst,src) that defaults to dst=src, but can be
overridden to provide a partial copy of pair<>.  Now however, I'm finding
that when current is reassigned for a second time (by clicking different
list entries) that I'm getting some type of memory violation.  I must be
overlooking something.  This should have been a minimal change.


Aside: While looking through the code, I noticed that in dataadapterimp.h,
the function implementation for converter_abstract_base::destroy() throws an
exception claiming to be clone.  Perhaps that body should belong to the
function converter_abstract_base::clone(), which is declared directly before
destroy()?

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]