[osg-submissions] Fixing osgTerrain::Layer::getFileNameproblemwith osgDotNet

[Mike Wittman]

Hi Robert,

On 9/6/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> On 9/5/07, Mike Wittman <mwittman at seismicmicro.com> wrote:
> > My understanding was that C++ standard library implementations
commonly
> > use reference counting and copy-on-write to internally manage
> > std::string data.  In that case return-by-value should be relatively
> > cheap.
> 
> I'm afraid this type of copy isn't cheap as the std::string internal
> sharing of data requires the use of mutex, which is expensive, far far
> more expensive than just passing around a point to the std::string as
> is the case for a reference.

Actually gcc's libstdc++-v3 uses atomic reference counting, so it's not
quite as bad as a mutex, but still not as good as a pointer copy.

> > Unfortunately, the difference in rules for const reference vs.
non-const
> > reference doesn't really help much in this case.  The problem occurs
> > when C++ code invokes getFileName on a wrapper's C# subclass that
has
> > had getFileName overridden.  In that case it's necessary to convert
a C#
> > string to a C++ const std::string&, which is not possible without
> > managing some semi-persistent std::string storage in the wrapper
(and
> > even then it doesn't have identical semantics).  Since the general
> > solution for this is complex and a simple one-off solution isn't
> > apparent, I'll just disable the getFileName functions in the
wrappers.
> 
> Could you not just treat the const std::string& as a std::string on
> the C# side?  Since it is const there is no mechanism for modifying
> the original string.

Yes, that's basically what I'm doing when C# calls C++: C# consumes a
const std::string&.  That works fine.

With the cross-language virtual function support I also need to handle
the C++ calls C# case: C# produces a const std::string&.  That requires
a std::string object backing the reference-return, and that object must
live at the same address for some indeterminate period after the
function call completes.

Both of those requirements can be supported, but the implementation is
non-trivial due to constraints of garbage collection and C++/C#
interoperability.  Since the only situation where this occurs is virtual
functions returning references to non-refcounted types
(osgTerrain::Layer::getFileName being the sole current case in OSG),
I'll put this on the back burner for now.  There are plenty of other
more significant issues to resolve in osgDotNet.

-Mike