Hi Carsten,
Carsten Neumann wrote:
>
> For "arbitrary" type access there are still member template access
> functions in GeoVectorProperty:
>
> template <class ExternalType>
> ExternalType getValue (const UInt32 index) const
>
> that make use of getGenericValue (and carry the cost of the virtual call
> and two conversion -- to MaxType and then to ExternalType)
>
> and in TypedGeoVectorProperty:
>
> template <class ExternalType>
> ExternalType getValue (const UInt32 index)
>
> that access the data directly (these only cost a conversion if
> ExternalType is different from StoredType).
>
> Sorry, I probably should have provided this information up front.
>
No, I should have remembered them. After all, I wrote them. ;)
The idea was to have the two conversion one as a last resort that would
always work. Whenever sensible it would be overridden by faster version.
But they all have the same names so that no matter what the user does,
it will work, and work as fast as it can.
I would like to keep this property, if possible at all, the question is how.
> Actually, now that I'm writing this, set/getGenericValue probably
> could/should be protected.
>
Probably true, as they're not really necessary.
> This unfortunately gives the more efficient interface a longer name.
>
Hm, true. :(
I was hoping to get to the point mentioned above by introducing a dummy
type that holds a Vec4d for conversion, and have an interface based on
that. That would avoid the dual function problem for Vec4d, at the cost
of an additional type. But given that there are temporary objects in the
loop anyway, that might not be an issue.
What do you think?
Dirk
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
