Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No initialization (Like Eigen) #112

Closed
ibtaylor opened this issue Oct 9, 2017 · 3 comments
Closed

No initialization (Like Eigen) #112

ibtaylor opened this issue Oct 9, 2017 · 3 comments

Comments

@ibtaylor
Copy link
Contributor

ibtaylor commented Oct 9, 2017

Eigen does not initialize via default constructors (for performance reasons??). Instead, they provide initializer methods like Zero() and Identity().

Would it make sense to be consistent with this in Sophus and, for instance, have SO3::Identity(), SE3::Identity(), etc and not default initialize?

I can see this being a significant enough change to maybe have to be done during a major version increment since some users probably rely on this default initialization.

@strasdat
Copy link
Owner

strasdat commented Oct 13, 2017

Personally, I do not like c++/Eigen's philosophy to default to the efficient version, instead to the safe one:

int i;
std::cout << i << std::endl; // reading uninitialized value

In practice, there are only few cases where this is a performance bottleneck, and we really don't want to initialize the variable i.

In a perfect world

int i; // initializes to 0
int j [[uninitialized]]; // leaves j uninitialized

I can't change c++ built in types, but I can write libraries in such a way.

Long story short, I'd be okay to add a

static SE3<...> uninitilized();

factory which leaves the element uninitialized, if there is demand for it.

@ibtaylor
Copy link
Contributor Author

Yeah, what I a mess. I thought this was sort of the reason for the new syntax int j{}; http://en.cppreference.com/w/cpp/language/value_initialization

I guess I was thinking about the situation where you have a std::vector of SE3d and want to resize() vs reserve()/push_back(). Afaik, you're forced to pass over and initialize all of the memory during the resize even if you plan on initializing with a loop after if your default constructor fully initializes.

@strasdat
Copy link
Owner

I'd say reserve()/push_back() is clearly the better approach in general, since you don't have to worry about how expensive the default constructor is for a type Foo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants