* Adds Atom atom map and rlabel apis
* Moves RLabels to their own namespace, adds other properties.
* Removes namespaces, liberally adds Atom to function names.
* move detail::computedPropName to RDKit::detail::computedPropName
* Adds RDAny (smaller generic holder) Updates all used dictionaries
This is an API compliant version of the current rdany system,
but uses a lot less memory in practice.
* Removes code duplication
* Converts CHECK_INVARIANT to TEST_ASSERT
* Fixes DoubleTag issue
* Adds Bool to DoubleMagic implementation
* Removes reference to property pickler
o rdkit gains a RDKit::common_properties namespace that contains common string value properties
o Dict.h and below gain getPropIfPresent that attempts to retrieve a property and returns
true/false on success or failure. This is used to optimize access.
o rdkit learns how to pass property keys by reference, not value.
A new namespace has been added to RDKit, common_properties
that contains the std::string values for commonly used
properties. This helps to avoid typos in string values
but also avoids a creation of std::strings from character
values. All accessors (has/get/clear and getPropIfPresent) now pass
the key by reference.
Additionally, getPropIfPresent removes the double lookup
of hasProp/getProp which can be a significant speedup
in the smiles and smarts parsers (10-20%)
instead of using the property map interface.
A nice side-effect is that the wart of having to use property maps to loop over bonds or atom neighbors
is now gone.
This potentially breaks lots of client C++ code.
http://sourceforge.net/tracker/index.php?func=detail&aid=1968930&group_id=160139&atid=814650
In order to fix the problem, the value of the query function for atomMass queries
is being multiplied by a constant factor (currently 1000) before converting
to an int. This allows distinguishing between things like [CH4] (where the
C has mass 12.011) and [12CH4] (where the C has mass 12.000).
http://sourceforge.net/tracker/index.php?func=detail&aid=1942657&group_id=160139&atid=814650
This was handled by adding error/consistency checking to Atom.calcExplicitValence()
This includes another pretty big scale modification:
the allowed valence list for atoms (in atomic_data.cpp) can now contain a -1 at the end. If this is the case, the atom will tolerate valences above the ones listed.
This is done to allow "flexible" atoms (i.e. transition metals and the like) to accept arbitrary coordination numbers without generating errors.
