Files / Namespaces / Tests strucutre

[ptheywood]

We should aim to be consistent with file structures in separate directores - i.e. unit tests should reflect the filestructure of what is being tested.

This would be also be an opportunity to refactor a little to improve naming,

• i.e. the pop and sim namespaces should be population and simulation respectively
• where does cuRVE belong? in gpu rather than runtime? why not in externals given that it is a (semi) third party library
• etc.

[ptheywood]

Namespaces we definately want:

• flamegpu - The main namespace which everything belongs to
• flamegpu::visualiser - The namespace for everthing vis related
• flamegpu::util - helper functions and other utilities.

Namespaces that we probably want?

• flamegpu::host - for host only bits of a model/simualtion
• flamegpu::device - for device bits of a model / simulation. Maybe cuda instead?
• Impl - a namespace for (somewhat private) implementation details - i.e. not the api, but has to go in headers. This will likely be a per-namespace subnamesapce. i..e flamegpu::impl, flamegpu::visualiser::impl, etc.
  • flamegpu::impl::visualiser might be the more conventional way to do this. I.e. boost uses boost::variant and boost:detail::variant.

Namespaces that we might want to plan for?

• flamegpu::experimental - somewhere to put things that are not stable. Probably not needed (yet)

Outstanding questsions

• device vs cuda for the device API. Not a huge deal as any introduction of a non-cuda Simulation backend will be a breaking change anyway
• model/simualtion/ensemble - could have their own namespace, but they probabyl just belong in flamegpu as they are expected to be used by the user.
• Can abstract classes go in the impl namespace if what implements them is not.
  • I.e. if flamegpu::CUDASimulation is a thing, should Simulation be flamegpu::Simulation or flamegpu::impl::simulation?
• Thrust and co uses specific namespaces such as thrust::sytem::cpp which are then exposed via an alias into the top level thrust namespace as thrust::cpp. I'm not sure if this is worthwhile for us yet.
• Do we want to go more granular, i.e into flamegpu::population as a namespace? This was my original intention but I'm now less sure.

Based on the google styleguide (which we are implicitly following via cpplint), namespace flamegpu { goes at the top of header and source files, "after includes, gflags definitions/declarations and forward declarations of classes from other namespaces.".

I may have been more verbose than that while trying to achieve partial compilation before adding every header / source file to the namespace (and after reading some opinionated discussion on SO)