Hello Dominik,
Dominik Rau wrote:
> Am 22.09.2008 um 18:29 schrieb Carsten Neumann:
>>> Could you move this to public please? (Same for the MF ...)
>> hm, I don't like the idea very much as it seems to encourage a style
>> of
>> programming that seems quite error prone to me. You have to make
>> sure to
>> mark the field as changed manually at the right spot.
>> Also, I'm not convinced what the gain is, as you still need to keep a
>> pointer to the container around for the call to editSField, so you
>> could
>> call editSFTranslation() on it instead ?
>
> Indeed, it looks dangerous (and propably it is). However, this has
> something to do with the internal structure of my software: The point
> is, that I'm using very generalized templates tha allow me a wrapped
> access to these values and also to all the components of the vector
> (or color or whatever). This template takes SField<T>*, a
> fieldcontainer pointer a field mask and that's it. If I don't have
> that functionality, I have to use very strange boost::bind()
> constructs that allow me to use editSFTranslation...
hm, I might miss some ugly details here, but using boost::bind does not
sound so bad to me. Instead of the mask you pass in a member function
pointer and bind it to the container pointer for the actual call [1]. Do
you (expect to) run into cases where it gets more messy ?
> If you're
> interested in what happens exactely I'll send you the code of the
> list...
> However: I think that if there is the possibility to get non const
> references to the values of the field, you should be able to keep them
> and work with them.
They are not really meant to be kept around (just like references to
elements of a std::vector are dangerous). Admittedly it does not say so
anywhere, but to be honest I had not thought of that use so far.
> However, I'm open for suggestions (this is work in
> progress). Maybe we could add something like
> editSFieldDangerousForDominikOnly()? ;) Or maybe a big fat warning as
> a comment (...a what?!) would already do?
Hm, do you think your wrapper templates would be useful to others? Would
you be willing to contribute them? If they were part of OpenSG, we could
perhaps make them friends of FieldContainer and solve the problem that way?
Another alternative could be that you keep a (fairly simple) local patch
that makes the change only on your end. I see your point with this, but
I'd rather examine the alternatives first before opening that interface up.
Thanks,
Carsten
[1] I'm thinking of something along the following lines:
template <class SFieldTypeT>
class SFAccessWrapper
{
public:
void init(SFieldTypeT *sField, OSG::FieldContainer *fc,
boost::function<SFieldTypeT *(OSG::FieldContainer *)> func)
{
_sField = sField;
_container = fc;
_editFunc = boost::bind(func, _container);
}
SFieldTypeT *editField(void)
{
return _editFunc();
}
const SFieldTypeT *getField (void)
{
return _sField;
}
SFieldTypeT *_sField;
OSG::FieldContainer *_container;
boost::function<SFieldTypeT *(void)> _editFunc;
};
This can be used as follows (I think making init a member function
template can get you around the reinterpret_cast):
OSG::DirectionalLightRefPtr light = OSG::DirectionalLight::create();
SFAccessWrapper<OSG::SFVec3r> sfaw;
sfaw.init(light->editSFDirection(),
light,
reinterpret_cast<OSG::SFVec3r
*(OSG::FieldContainer::*)(void)>(&OSG::DirectionalLight::editSFDirection));
sfaw.editField()->setValue(OSG::Vec3r(0.0, 1.0, 2.0));
OSG::commitChanges();
std::cout << sfaw.getField()->getValue()[0] << " "
<< sfaw.getField()->getValue()[1] << " "
<< sfaw.getField()->getValue()[2] << std::endl;
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
