[litwindow-users] Re: Now implemented : Re: <map> as container

[Hajo K. <mai...@ha...>]

Hi,

> When I run, I get the assertion during startup:
> 	std::runtime_error: from_accessor method not implemented
> 
> The assertion appears to be correct.  The from_accessor looks like it is not
> implemented when <pair> is declared ...ADAPTER_NO_COPY.  However, without
> NO_COPY there will be problems because of operator=.  Why doesn't it want to
> play with the list?

that is unfortunate. Hm. The problem here is that indeed the pair<> does 
not have a copy constructor or = operator. But the list code wants to 
access map elements by value. from_accessor does the same thing as 
from_string: it sets the value of an object pointed to by an accessor 
from a different accessor, whereas from_string would read the value from 
a string.

I will have to think about how to solve this problem. This wasn't an 
issue with vector<>, because the elements of the vector could be copied 
and thus ...ADAPTER without NO_COPY could be used.

I may have to introduce a type_traits class that encapsulates 
assignment, comparison and other operations. That way you can specialize 
  the type_traits template when you know how to copy an object but there 
is no = operator or copy constructor available.

In this case it would mean writing something like

template<>
void type_traits<pair<string, int> >::assign(pair<string, int> &to, 
const pair<string, int> &from)
{
   to.first=from.first;
   to.second=from.second;
}

The entire = and copy constructor issue is causing many problems with 
the data adapter design. Here is where the problem actually stems from:

When you define get/set properties you have to be able to copy elements. 
If it were all member variables I could simply pass a pointer to the 
object around. But I cannot pass a pointer to the result of a 
get_property call. So the data adapter mechanism tries to do both: use 
pointers when possible and use the copy scheme when get_/set_ property 
methods are used.

Some objects don't have a copy constructor or = operator. The first 
distinction then is the one between ...ADAPTER and ...ADAPTER_NO_COPY. 
The ...ADAPTER_NO_COPY creates a data adapter with more limited 
functionality. from_accessor is not defined for example, because 
from_accessor tries to assign an object.

Hmm. Difficult.

Hajo