[osg-users] C++11 for next stable release of OpenSceneGraph?

11 views
Skip to first unread message

Robert Osfield

unread,
Jun 11, 2018, 2:58:09 AM6/11/18
to OpenSceneGraph Users
Hi All,

My current focus is on the VulkanSceneGraph, exploring C+11, Vulkan
and new ideas of what a next gen scene graph should look like.
OpenSceneGraph is still very much my baby though. Stuff that is
working well on the VulkanSceneGraph could serve as a model for what
we can do to elements of the OpenSceneGraph, so potentially as
advances are made in VulkanSceneGraph would could refactor the
OpenSceneGraph to take advantage of similar approaches.

While OpenSceneGraph will remain focused on OpenGL and aim to retain
good backwards compatibility there may be opportunities to make life
easier to OpenSceneGraph users. One of these areas is taking
advantage of some of the features that C++11 has to offer. So far on
the VulkanSceneGraph side I've experimented with some low level
equivalents of things like ref counting, ref pointers, observer
pointers taking advantage of C++11 and it's a delight, the code is
SOOOO much simpler and cleaner that what's presently in the
OpenSceneGraph.

So I'd like to put out the topic for discussion about whether we could
set the min compiler version of the OpenSceneGraph to C++11 for the
next major stable release. I don't have any specific plans to this
next stable release, I'm assuming it'll be 4.0, it'll likely be
another year or so before being released. I would like to this
OpenSceneGraph stable release to sync in a bit with the
VulkanSceneGraph efforts but as this project is just beginning the
schedule for it's own releases is completely open. When I say sync a
bit, I'm really just referring to taking opportunities to cross
pollinate ideas a bit, make co-existance of the two projects easier,
what that will mean in practice I absolutely can't say, it's really
just an aspiration right now.

Back to C++11, the pros of adopting it for OpenSceneGraph-4.0 is that
we could simplify parts of the core OpenSceneGraph, making it both
easier to lean and maintain. Potentially even OpenThreads could be
removed as dependency and then from the core OpenSceneGraph and made
it's own separate project once again.

The cons of adopting C++ would be restrictions on just how old the
compilers can be to be used with OpenSceneGraph-4.x, so could limit
one aspect to backwards compatibility.

I would suggest that OpenSceneGraph-3.x series remain compilable
without needing C++11. So 3.6.x for instance we'll make bug fixes etc
but never change the compiler requirements.

Thoughts?
Robert.
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Alberto Luaces

unread,
Jun 11, 2018, 4:14:59 AM6/11/18
to osg-...@lists.openscenegraph.org
Robert Osfield writes:

> I would suggest that OpenSceneGraph-3.x series remain compilable
> without needing C++11. So 3.6.x for instance we'll make bug fixes etc
> but never change the compiler requirements.

Having that fallback (3.x) for the tiny amount of systems that don't
support C++11 is a sensible approach, and I would even dare to say
extra-conservative, given the support of C+11 among current compilers.

--
Alberto

Chris Hanson

unread,
Jun 11, 2018, 12:18:49 PM6/11/18
to OpenSceneGraph Users
I'm totally in support of moving to C++11.


--
Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging  UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]

Björn Blissing

unread,
Jun 11, 2018, 2:43:29 PM6/11/18
to osg-...@lists.openscenegraph.org
I am also in total support to move to C++11.

I am even inclined to favor moving all the way to C++17, which includes some nice features (my favorite being allowing initializers in if and switch statements). And even Visual Studio is somewhat conformant:
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/

Regards
Björn

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74041#74041

Sebastian Messerschmidt

unread,
Jun 12, 2018, 2:21:10 AM6/12/18
to OpenSceneGraph Users, Robert Osfield
Hi,

I totally support the step to use a more modern feature set of C++. It
really makes code easier to read, maintain and coding more fun. I'd
rather target C++14/17 though since almost all modern compilers are good
at keeping up with the new features (even Microsoft is doing a good job
here). If you consider this too much of a stretch, you might consider
to simply constrain the set of features allowed for now (excluding not
so well supported ones).

Another word on coding style: Lambdas, especially when the get more
complex should follow a consistent style. Else they tend to increase the
parsing effort for the human brain beyond most people's limit.

From my experience the should always be defined and named before use in
a function. This way the function of the lambda is stated by the name
which saves a lot of guesswork.

E.g.

//// the "auto" inside the lambda params is a C++14 feature btw.
auto find_name= [&token](const auto& elem){return token==elem.name;};

std::find_if(std::begin(elements), std::end(elements), find_name);

instead of:
std::find_if(std::begin(elements), std::end(elements), [&token](const
auto& elem){return token==elem.name;});


Cheers
Sebastian

Sebastian Messerschmidt

unread,
Jun 12, 2018, 3:24:43 AM6/12/18
to OpenSceneGraph Users
Hi Daniel, > Hi Sebastian,
>
>> I'd rather target C++14/17 though since almost all modern compilers
>> are good at keeping up with the new features (even Microsoft is doing
>> a good job here).
>
> you just have to consider that switching compilers isn't that easy for
> everyone, because they've constraints that aren't completely under their
> control.

But VSG is a fresh start and there are no existing projects that use it
a this point. So "switching" compilers is not an issue, right? I mean if
someone is planning on using it, using a modern compiler is simply a
prerequisite. Since the project just started I think it won't be used in
production before 2019. Until then most environments should be up2date
with C++14 conforming compilers.

>
> So going for C++11 should be fine at this point in time, but I wouldn't
> go beyond.

Most C++11 compilers I've encountered support a subset of C++14 anyways,
which is why I also pointed out, that defining a set of features might
be possible too.

Robert Osfield

unread,
Jun 12, 2018, 3:37:35 AM6/12/18
to OpenSceneGraph Users
HI Guys,

Thanks for the feedback on adopting C++11 and later for the next
stable OpenSceneGraph release.

I am not planning on radical change to OSG in this timeframe, instead
where things will be cleaned up and it's an easy change to adopt
recent C++ functionality to achieve this. I don't foresee a general
walk through of the OSG codebase changing everything we can to a
modern C++ way of doing things just because it could be done.

FYI, prior to the 3.6.1 release I stepped through making sure it built
cleanly under C++11, 14 and 17, the only thing I had to amend was to
replace the deprecated C++ usage. This means that 3.6.1 is forwards
and backwards compatible to a wide range of C++ compilers.

For me, the key thing for the OpenSceneGraph project is now stability.
I want it to be a rock solid base for people to develop and maintain
their graphics application upon.

Cheers,
Robert.

Sebastian Messerschmidt

unread,
Jun 12, 2018, 3:40:17 AM6/12/18
to OpenSceneGraph Users

Hi Daniel,

Sorry I was mixing up VSG and OSG here. For OSG you're totally right
with your concerns.

Cheers
Sebastian > Hi Daniel, > Hi Sebastian,
Reply all
Reply to author
Forward
0 new messages