Starting Point
I have a C++ application (working with VS2019, Window 10 64bit), which heavily relies on the Open3D library. Everything was working perfectly fine, I was using the previous version (0.14.x), which I built from source using CMAKE and Visual Studio 2019.
There are some features in the new version (0.15.1) I would like to use. Furthermore, new releases come with a binary packages, so no more building from source. So I backup my current version and download the new binaries and try to link them to my project.
Issue
To start from a clean slate I remove all the old entries for Open3D and manually insert the new ones. Here are the entries:
Project Properties --> C/C++ --> General --> Additional Include Directories:
Project Properties --> Linker --> Input --> Additional Dependencies:
Building now leads to a whole lot of linker errors all connected to fmt, a 3rd party library used by Open3D it seems. However, these seem to be caused only because, I have two additional includes with respect to Open3D in my precompiled header:
// open3d
#include "open3d/Open3D.h"
#include "open3d/core/Indexer.h"
#include "open3d/t/geometry/RaycastingScene.h"
If I remove them, all linking errors disappear, but I'm facing yet another issue: Indexer.h is needed for the TensorIterator class, RaycastingScene.h for the RaycastingScene class, both of which I'm using a lot in my project.
Question(s)
Why do I need an extra import for RaycastingScene but not for example VoxelblockGrid, which is in the same namespace?
I have already tried to clone, build and link fmt manually. It looks like I can access the library from my own code successfully, but using Open3D I still get the same linker errors.
How am I supposed to use these two classes?
A namespace has nothing to do with including files. It's just a way of grouping and organizing classes, functions, etc. For instance, vector and cout are both in the std namespace. But #include does not give you access to the vector class. Why would it? Vectors have nothing to do with I/O; it would be upsetting if the entire standard namespace had to be imported just so that I could write to standard out. But the files that you include might also include other files in turn. So maybe you've accidentally included VoxelblockGrid transitively, and that's why it works fine.
You should assume that it's not imported transitively. The standard practice is to make imports idempotent, which is to say that if you #include the same file twice, the second action is a no-op. So there's no harm in importing the file twice. Even if it has been transitively imported (which you might determine by testing, as you suggest), a future update to the package might no longer need that transitive import due to changes in implementation details, so it might remove it. If you're not also importing it manually in your own code, then your code will break.