<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 20, 2018 at 8:14 AM, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Scott,<br>
<span class=""><br>
On Wed, 20 Jun 2018 at 08:09, Scott Bailey <<a href="mailto:Bailey@insanegenius.org">Bailey@insanegenius.org</a>> wrote:<br>
> Wow is this ever good news!  I'm glad to see OSG will move into the future, albeit as VSG.  I'm especially excited to see modern c++ targeted.  Personally, my preference is for c++14 if only for std::make_unique<>(), but I'll take c++11 any day!<br>
<br>
</span>I guess there is chance I'll use std::unique_ptr<> and associated<br>
std::make_unique<>() at some point.  The scene graph itself will be<br>
managed using intrusive reference counting just like the OSG does for<br>
performance reasons, so I've prototyped equivalents of osg::ref_ptr<><br>
and osg::Referenced for this purpose.  I guess one could also write a<br>
vsg::make_ref<> equivalent to std::make_unique<> if one so desired.<br>
<br></blockquote><div>Before you move on, the big advantage of std::shared_ptr over intrusive reference counting is that support for weak pointers is rock solid. In the intrusive model, you can't implement thread-safe weak pointers without an auxiliary data structure, which complicates the implementation a lot. I know that one historic OSG performance win for  osg::ref_ptr  was the ability to not do the reference counting if it isn't needed, but with atomic increment / decrement implemented everywhere, do you think there is really much performance advantage for intrusive counting? Also, std::make_shared<>() allocates the shared_ptr control block in the same memory allocation as the shared object, so there need not be a memory fragmentation hit for using shared_ptr.</div><div><br></div><div>Tim</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For now I'm wider design issues, doing experiments with more modern<br>
C++ along the way to see what is possible.  My general guide is that<br>
modern C++ features deployed needs to make the code easier to read and<br>
maintain than not using it, or provide significant flexibility/power<br>
that justifies any possible complexities in following the code.  So<br>
far so good on this count - I've been able to make the VSG equivalents<br>
of OSG much simpler thanks to modern C++ features.<br>
<br>
I won't make any decision on C++11 vs 14 vs 17 until the end of<br>
Exploration Phase.  If we can do everything we'll need with just C++11<br>
and there are few features of 14 and 17 that offer significant<br>
benefits then I'll likely just stick with C++11 for better backwards<br>
compatibility to older compilers.  The backwards compatibility with<br>
older compilers isn't a priority though, just something worth<br>
maintaining if it comes at no cost to the integrity/quality of the<br>
scene graph.<br>
<br>
I have to admit, I *really* like working with modern C++, looking back<br>
to some OSG code is bit painful now.  This isn't just C++ features<br>
though, my skills as programmer have slowly advanced over the years so<br>
now can spot better ways of solving problems.  Once VSG is established<br>
there may be a few areas of the OSG that could be updated to do<br>
similar things to what the VSG will do, though backwards compatibility<br>
for the OSG is crucial - it'll be a case of asking the question what<br>
can make OSG users lives better without risking breaking things.<br>
<br>
These possibilities are all a way off yet.  Through to the end of<br>
August I'll be just learning, thinking, experimenting with C++, Vulkan<br>
and ideas for improving scene graphs, and also getting OSG-3.6.2 out<br>
the door :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
Robert.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> If you haven't already seen it, check out the Magnum Graphics Engine.  It's the only example I've found of anything close to a scene graph with a modern c++ interface.<br>
><br>
> Best luck and Thanks!<br>
> SB<br>
> [/url]<br>
><br>
> ------------------<br>
> Read this topic online here:<br>
> <a href="http://forum.openscenegraph.org/viewtopic.php?p=74083#74083" rel="noreferrer" target="_blank">http://forum.openscenegraph.<wbr>org/viewtopic.php?p=74083#<wbr>74083</a><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> osg-users mailing list<br>
> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
</div></div></blockquote></div><br></div></div>