[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

Robert Osfield robert.osfield at gmail.com
Thu Jun 7 02:20:36 PDT 2018


On Thu, 7 Jun 2018 at 08:49, Björn Blissing <bjorn.blissing at vti.se> wrote:
> 1. Use modern CMake - this will make the project much easier to use.

Modern CMake and xmake are on the short list.

> 2. Minimize external dependencies - Preferably the project should be able to be used without any external dependencies included at all.

C++11 and Vulkan are the only current planned non optional
dependencies (apart form the build tools :-)

I don't know yet whether we should have loaders within the core
VulkanSceneGraph project or outside in additional
libraries/frameworks, it's the loaders that cause the 3rd party
dependency issues.

> 3. Try to follow the ISO-cpp guidelines as close as possible - This will ensure a consistent style when used together with other modern c++ programs. This will also help when using static code analysis tools.
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

Heh...  I just so happened that to the list of 3rd party resources
that I'm referencing this morning.

> And maybe this time we will get header files with the .h extension. ;)

Maybe, no decisions made yet, but I'm also not polling for opinions,
the VulkanSceneGraph isn't a design by committee.

My initial code experiments have .hpp but frankly it's ugly as hell as
well as stupid - there's no header plus plus language so I'm rapidly
tiring of .hpp. Code should to be a thing of beauty not some ugly
kludge.  .h makes sense as it's a header, .cpp makes sense for source
files as it's C++.  However, public headers are placed into include
directories and that's their role, we know they are headers because
that's why we put them there, so the .h should be superfluous for
public headers and the standard C++ headers illustrate this.  If 3rd
party tools/editors can't even handle the extension less C++ standard
library headers then they aren't really up to the job.

Cheers,
Robert.


More information about the osg-users mailing list