Even it might be annoying but i think the eigen way is good: Initialize members by default on debug-level, keep them unitialized when on release. needs_opt (with debug-symbols) should be uninitialized too.
Reason: - During development-cycle it might be annoying if you forgot to initialize values and need long debug times here. - When "defining" a component as release, it has to be check in any case, so if then an error occur the developer might not think on the initialization at the first place, but he will think on this. (or google at it). - This solves the overhead for initialization for production systems, and safe time on out every day life. So a mix between a and c is the best way i think. Best, Matthias On 10.11.2014 14:00, Jakob Schwendner wrote: > Hey, > > I would like to reopen a discussion for uninitialized values in base/types. > This was triggered by the following merge request: > https://github.com/rock-core/base-types/pull/17 > > The question boils down to how we want to handle default constructors in > base types. > Options: > a) Leave uninitialized (like e.g. Eigen does) > b) Initialize to zero or whatever equivalent > c) Initialize to unknown (represented as NaN) > > I think we currently have a) in some places and c) in others. > > My contribution to the discussion: > b) seems even more dangerous than a, as it wouldn't even be picked up by > valgrind. No good. > a) May be slightly more efficient in some special cases > c) seems like the right thing to do. > > RigidBodyState tries a mix between a) and c). Maybe this could be the way > forward? > > Cheers, > > Jakob > -- Dipl.-Inf. Matthias Goldhoorn Space and Underwater Robotic Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel.: +49 421 178 45-4193 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
