enum { generic_type = 0,
depth = CV_8U,
channels = 1,
fmt = (int)'u',
type = CV_MAKETYPE(depth, channels)
};
// Enum example in point cloud registration
enum class RegistrationMethod { PCL, MTPCL, FAST };
struct RegistrationResult {
RegistrationMethod method;
double time_elapsed;
double fitness;
Eigen::Matrix4d transformation;
};
// Union example in PCL (point_types.hpp)
// PointXYZLAB
union
{
struct
{
float L;
float a;
float b;
};
float data_lab[4];
};
```
references: [Stackoverflow: what is the size of an enum type data in C++?](https://stackoverflow.com/a/8115895/13980439);
### return multiple values
For returning two values we can use a `std::pair` (usually typedef'd). In C++11 and newer, there's `std::tuple` for more than two return results. With introduction of structured binding in C++17, returning `std::tuple` should probably become accepted standard.
In practice, if multiple result values are needed, the best practice is to create a struct to store these values and return this struct or change it as the pass-by-reference argument.
// in C++ 11
#include <tuple>
std::tuple<int, int> divide(int dividend, int divisor) {
return std::make_tuple(dividend / divisor, dividend % divisor);
}
#include <iostream>
int main() {
int quotient, remainder;
std::tie(quotient, remainder) = divide(14, 3);
}
// Example in Open3D
// open3d/pipelines/registration/ColoredICP.cpp
Eigen::Matrix6d JTJ;
Eigen::Vector6d JTr;
double r2;
std::tie(JTJ, JTr, r2) =
utility::ComputeJTJandJTr<Eigen::Matrix6d, Eigen::Vector6d>(
compute_jacobian_and_residual, (int)corres.size());
// open3d/utility/Eigen.cpp
template <typename MatType, typename VecType>
std::tuple<MatType, VecType, double> ComputeJTJandJTr(
std::function<void(int, VecType &, double &, double &)> f,
int iteration_num,
bool verbose /*=true*/) { ... }
// Example in TEASER++
namespace teaser {
struct RegistrationSolution {
bool valid = true;
double scale;
Eigen::Vector3d translation;
Eigen::Matrix3d rotation;
EIGEN_MAKE_ALIGNED_OPERATOR_NEW
};
}
references: [StackOverflow: Returning multiple values from a C++ function](https://stackoverflow.com/questions/321068/returning-multiple-values-from-a-c-function); [Open3D/ColoredICP](https://github.com/isl-org/Open3D/blob/master/cpp/open3d/pipelines/registration/ColoredICP.cpp); [TEASER-plusplus/include/teaser/registration.h](https://github.com/MIT-SPARK/TEASER-plusplus/blob/master/teaser/include/teaser/registration.h#L30)
### std::thread
* template< class Function, class... Args > explicit thread( Function&& f, Args&&... args );
* Move constructor is allowed, but copy constructor is deleted.
* If running class member functions, an instance of the class is needed as the first argument.
```cpp
// Example from slambook2 ch13
Viewer::Viewer() {
viewer_thread_ = std::thread(std::bind(&Viewer::ThreadLoop, this));
}
void Viewer::Close() {
viewer_running_ = false;
viewer_thread_.join();
}
// Example from LeGO-LOAM mapOptimization
int main(int argc, char** argv) {
ros::init(argc, argv, "lego_loam");
mapOptimization MO;
std::thread loopthread(&mapOptimization::loopClosureThread, &MO);
std::thread visualizeMapThread(&mapOptimization::visualizeGlobalMapThread, &MO);
ros::Rate rate(200);
while (ros::ok()) {
ros::spinOnce();
MO.run();
rate.sleep();
}
loopthread.join();
visualizeMapThread.join();
return 0;
}
// Example from A-LOAM laserMapping
void process() {
while(1) { ... }
}
int main(int argc, char **argv) {
ros::init(argc, argv, "laserMapping");
std::thread mapping_process{process};
ros::spin();
return 0;
}
```
references: [C++ reference on std::thread constructor](https://en.cppreference.com/w/cpp/thread/thread/thread); [slambook2 chapter 13 source code](https://github.com/hanzheteng/slambook2/blob/master/ch13/src/viewer.cpp#L14); [LeGO-LOAM map optimization source code](https://github.com/hanzheteng/LeGO-LOAM/blob/master/LeGO-LOAM/src/mapOptmization.cpp#L1534); [A-LOAM mapping source code](https://github.com/hanzheteng/A-LOAM/blob/devel/src/laserMapping.cpp#L957);
### volatile
* It is a keyword to tell compiler that this variable may be modified from outside the program which compiler is not aware of. Therefore, please do not optimize this variable.
* It is a qualifier that can also be applied to methods/functions.
* `volatile` and `const` are two faces of the same coin.
```cpp
// Example without volatile
int some_int = 100;
while (some_int == 100) { // compilier may optimize this to while(true)
// code not related to some_int
}
// Example with volatile
volatile int some_int = 100; // tells compiler not to optimize this variable
while (some_int == 100) {
// code not related to some_int
}
```
references: [C++ keywords: volatile](https://en.cppreference.com/w/cpp/keyword/volatile); ; ;
### memory fence/barrier
* This refers to a set of instructions to synchronize memory access (read/writes occur in the order you expect). For example a 'full fence' means all read/writes before the fence are comitted before those after the fence. It is a hardware level concept, and in higher level languages we are used to dealing with `mutex`es and `semaphore`s.
* Note that the keyword `volatile` *does not guarantee a memory barrier* to enforce cache-consistency. Although It is guaranteed that volatile reads/writes will happen in the exact order specified in the source code, but volatile reads/writes can still be reordered with respect to non-volatile ones. (This is referred to as compiler reordering optimizations.)
Thread #1 Core #1:
```cpp
while (f == 0);
// Memory fence required here
print x;
```
Thread #2 Core #2:
```cpp
x = 42;
// Memory fence required here
f = 1;
```
references: ; ; ;
### hash
By default, `std::pair` and `std::tuple` are not hashable, and therefore they cannot serve as keys in `std::unordered_map`. For hashing and combining multiple values, one way is to use `boost::hash_combine` function. Alternatively, we can write our own hash functions.
```cpp
/**
* @brief Templated hash function for Eigen::Matrix class.
*
* Example usage:
* std::unordered_map>
*
* @note This implementation is oblivious to the storage order of Eigen matrix
* (column- or row-major). It will give you the same hash value for two different
* matrices if they are the transpose of each other in different storage order.
*
* The code is from `hash_combine` function of the Boost library.
*/
template
struct hash_matrix : std::unary_function {
std::size_t operator()(T const& matrix) const {
size_t seed = 0;
for (size_t i = 0; i < matrix.size(); ++i) {
auto elem = *(matrix.data() + i);
seed ^= std::hash()(elem) + 0x9e3779b9 + (seed << 6) + (seed >> 2);
}
return seed;
}
};
/**
* @brief An alternative hash function optimized to reduce collision rate for
* numerous vectors that all contain elements from a small continuous distribution.
*/
std::size_t operator()(std::vector const& vec) const {
std::size_t seed = vec.size();
for(auto x : vec) {
x = ((x >> 16) ^ x) * 0x45d9f3b;
x = ((x >> 16) ^ x) * 0x45d9f3b;
x = (x >> 16) ^ x;
seed ^= x + 0x9e3779b9 + (seed << 6) + (seed >> 2);
}
return seed;
}
```
References: ; ;
### class inheritance and polymorphism
```cpp
pcl::Registration::Ptr base_ptr;
if (method == "pcl")
base_ptr = std::make_shared>();
else if (method == "pclmt")
base_ptr = std::make_shared>();
else if (method == "fast")
base_ptr = std::make_shared>();
else
throw std::runtime_error("unknown gicp method");
// Then use base_ptr to call functions in derived class
// Note: these functions must already exist in base class as virtual functions
base_ptr->setInputSource(source);
base_ptr->setInputTarget(target);
```
### factory method
The most basic factory method
```cpp
unique_ptr makeAnimal(const string& type, int number) {
if (type == "Dog") return make_unique(number);
if (type == "Cat") return make_unique(number);
throw runtime_error("Invalid type!")
}
```
Reference: [Unforgettable Factory Registration](http://www.nirfriedman.com/2018/04/29/unforgettable-factory/)
# C++ Debug
## Debug FAQ
### error: if condition proceeds with a bool variable that is false
```cpp
fake_indices_ = false; // member variable initialized somewhere else
bool MultiviewGICP::initCompute() {
std::cout << "fake_indices_ = " << fake_indices_ << std::endl;
// this prints 0, and confirms that fake_indices_ was indeed initialized as false
if (fake_indices_) {
std::cout << "we are getting here." << std::endl;
// the weird thing is that this line of code gets printed out,
// meaning that we reached this code block, suppressing the if condition
}
// the root cause of this problem was the missing of the return statement below,
// which is required of this function.
// Without it, program proceeds with whatever code being compiled in the memory.
return true;
// if you put directly "if (false)", the above code block will not be executed,
// since they may be optimized out during compilation.
}
```
### error: variable or field declared void
```cpp
// for example it happens in this case
void initializeJSP(unknownType Experiment);
// another example (due to the missing 'typename' keyword)
template
void func(pcl::PointCloud::Ptr& cloud) {} // error
void func(typename pcl::PointCloud::Ptr& cloud) {} // correct
```
reference:
# Factory Method
## Unforgettable Factory Registration
by Nir's blog 29 Apr 2018 ([original link](http://www.nirfriedman.com/2018/04/29/unforgettable-factory/))
Using a factory is a common pattern when we are working with polymorphic objects. It exists to solve a very basic issue in C++: in order to construct something you must name its type. But the entire point of runtime polymorphism is often that we cannot name the type, because we won’t know it until runtime.
The most basic factory would just consist of some `if` statements coupled together:
```cpp
unique_ptr makeAnimal(const string& type, int number)
{
if (type == "Dog") return make_unique(number);
if (type == "Cat") return make_unique(number);
throw runtime_error("Invalid type!")
}
```
This often isn’t a great solution. In particular, we keep having to update this central piece of code every time a new derived class gets written. Under the best of circumstances, this is merely irritating and code smell. However, in some cases it can be much worse. It’s common for a library to provide an interface and a few concrete classes deriving from it. If the library uses a factory somewhere that’s written like this, it will be impossible for the user to inject their own classes into the library.
Aside from very simple use cases, better factories tend to predicated on allowing classes to register themselves for construction by the factory; this allows library code to construct user classes that were written afterwards, and avoids the issue of a central function that needs to change with each new class. This is usually by done changing the logic of the factory from code—multiple `if`s—into data, in particular an associative map. It usually looks something like this:
```cpp
unordered_map(*)(int)> factory_map;
factory_map["Dog"] = Dog::make;
factory_map["Cat"] = Cat::make;
unique_ptr makeAnimal(const string& type, int number)
{
return factory_map.at(type)(number);
}
```
### Registration
Using an associative map for this sort of thing is the way to go, but there’s still the whole issue of registration. It’s easier to forget to do, or do incorrectly. Overwhelmingly, I’ve seen macros used for this purpose; something along the lines of:
```cpp
class Dog : public Animal {
};
REGISTER_CLASS(factory_map, Dog);
```
It has to be done manually for each derived class and it’s easy to forget. We’re going to look at how to automate this process, removing boilerplate and eliminating the possibility of mistakes.
### Goal
Wouldn’t it be magical, if instead of worrying about macros, or some global dictionary, we instead could just push everything into a library? Users could just write code similar to this:
```cpp
struct Animal : Factory {
virtual void makeNoise() = 0;
...
};
class Dog : public Animal::Registrar {
public:
Dog(int x);
void makeNoise() override;
...
};
auto x = Animal::make("Dog", 3);
x->makeNoise();
```
No macros, no magic, no problems. The end user is just solving their problem. Does this seem to good to be true? Well, it’s not.
### Solution Sketch
Let’s start by a sketch of some of the functionality that we want. Because this is all going to be automated, I’m going to opt to simply inject the factory interface directly into the base class using the Curiously Recurring Template Pattern ([CRTP](https://eli.thegreenplace.net/2011/05/17/the-curiously-recurring-template-pattern-in-c)), instead of having it as a separate entity.
```cpp
template
class Factory {
public:
template
static unique_ptr make(const string &s, T&&... args) {
return data().at(s)(forward(args)...);
}
friend Base;
private:
using FuncType = unique_ptr (*)(Args...);
Factory() = default;
static auto &data() {
static unordered_map s;
return s;
}
};
```
The factory is templated on the base class that it is both injecting interface into, and that it produces unique pointers to. The `Args` template parameter represent the arguments required to produce a derived instance from the factory. Note that we use the common CRTP trick of making the constructor `private`, and the template a `friend` to make it more difficult to misuse (`class Foo : Factory