[nomonkeybusiness]

Hi codeheads.
I've been wrestling with this problem, and it really gets under my skin.
I am trying to figure out a way to share data between different classes, using some kind of smart-pointer
in the process, to avoid memory-leaks and dangling pointers.
I've been trying something like this:

This is the "Property-class", the class used to represent data.
The idea is that one class can have different data-members, while avoiding long inheritance-chains.

class IProperty
{
    virtual ~IProperty( );
    virtual void* data( );
};

template <class T>
class Property
{
    T* mData;
    void* data( ) { return mData; };
};

Now for the example:

class Foo
{
public:
    template< class T >
    shared_ptr< IProperty > getProperty( string p_name )
    {
         propertyMap::iterator it = mProperties.find( p_name );
         if( it == mProperties.end( ) ){
               shared_ptr< IProperty > xProp = new Property<T>;
               mProperties[p_name] = xProp;
               return xProp;
         };
         return it->second;
    };    

private:
    typedef std::map< string, shared_ptr< IProperty > > propertyMap;
    propertyMap mProperties;
};

So far, so good, right? Well. The problem arises when I use it.

Foo* pFoo = new Foo( );

shared_ptr< IProperty > pInt = pFoo->getProperty<int>( "Crazy" ); // This works, and I now have one undefined int as a property.
int* pIntData = pInt->data( ); // This returns the data
*pIntData = 11; // and this sets the property "Crazy" to 11.

shared_ptr< IProperty > pString = pFoo->gerProperty<string>( "Crazy" ); // Since the getProperty-method will find a property with the name "Crazy", it will return it.
string* pStringData = pString->data( ); // This will try to fetch the data, in my test, the string returned was empty (but then the property was of a different class)
*pStringData = "HowCrazyIsThis?"; // This will try to set the property to "HowCrazyIsThis?", and it actually does, except the data is in fact an int, and I wind up with some bogus-value

This is clearly unacceptable. In a multi-user project it creates an almost multithreaded-like dilemma, in which you can never be sure that the data is still valid.
I could maybe try a dynamic_cast, and only change the data if the return-value is not NULL, but I don't really like that solution. Partly because I think it is bad code-standard, and partly because it is slow, and speed is a factor.
Have someone run into this dilemma before?

Regards.

[PlasticineGuy]

To share data, you can do this:

class foo;
class bar;
class foo {
    public:
        friend class bar;
    private:
        int x;
};
class bar {
    public:
        friend class foo;
    private:
        int x;
};

Now any function in foo can access bar::x, and any function in bar can access foo::x.

[muballitmitte]

I don`t quite understand what exactly you do with this code or try to achieve. You should consider returning a const pointer inside the Property class, because in the way you use the class you break encapsulation and maybe this is a bad thing. Concerning other aspects of the code I really don`t see any problems. I mean you created a class hierarchy for Property but when you add one to a Foo class you do not check for a type; you simply see if you have a property with that same name and if not you create one. You should consider adding types in that search and see when you call that getProperty method that the type of the property used on call matches the one if case you found something with a similar name. I believe in C++ there is a typeid operator so you could use it to create a getType method in your Property class. Please make sure that is what you are trying to achieve :-S (this is weird)

I read everything fast and maybe I`m missing the point here so I`m sorry if these are all senile ramblings;

This post has been edited by muballitmitte: 10 March 2010 - 12:58 AM

[Martyn.Rae]

I would move out a level and say that we had a class called foo, a class called bar that is a user of the foo data, and a class called foobar that also uses the foo data.

In this way, foo can provide get and set functions, and bar and foobar classes can be passed a reference or a pointer to foo. They are then both operating on the same data. I don't like friend ... only when you have helper classes as sub-classes of a class!

[nomonkeybusiness]

"I would move out a level and say that we had a class called foo, a class called bar that is a user of the foo data, and a class called foobar that also uses the foo data.

In this way, foo can provide get and set functions, and bar and foobar classes can be passed a reference or a pointer to foo. They are then both operating on the same data."

This is the way I do it. The problem is that you can never be sure that the data you get back is of a certain type.

Let me give you another example, which is more related.
The problem is in fact a game-programming problem. The idea is that Foo will hold different properties, and components (another class).
The component will have to use it's parent( the Foo )'s data, the properties.
For example; a Physics-component will have to have access to a tranform-matrix, but so does the render-component, and the input-component, and everyone should have the power to change it if necessary. When a property is changed, of course it should be changed for all the components. It seems stupid to incorporate some kind of message-system, when I could just use pointers.