id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 10105,graphml attribute type mapping for types not in specification,Sergey Mitsyn ,Jeremiah Willcock,"At the moment, {{{write_graphml}}} tries to convert non-standard attribute value types (that are not in specification) which it got from {{{dynamic_properties}}}, to standard ones. A type is converted to a simple form, say {{{unsigned int}}} to {{{int}}}, etc, by a predefined mapping in {{{write_graphml}}}: {{{value_types}}} and {{{type_names}}}. The conversion only affects graph metainformation ({{{}}}'s {{{}}} elements): conversion of an attribute value to a string is done by dynamic properties in {{{dynamic_property->get_string()}}} (that is, the value is actually never converted by the writing function). On the other hand, {{{read_graphml}}} tries to use type info from {{{}}} elements and converts a string to the specified type and then passes it to dynamic property map as a {{{boost::any}}} instance. If a property map is passed to dynamic_properties that has non-standard value_type (not in {{{boost::mutate_graph_impl::value_types}}} list), but still ""supported"", like {{{unsigned int}}}, the {{{read_graphml}}} first checks if value types match and then, because they are not, unconditionally {{{any_cast}}}'s to {{{std::string}}}, which fails with {{{bad_any_cast}}} being thrown. This is unfortunate - a user has a promise that some attribute types are supported during writing, but then she can't read it back to the same property map. On the contrary, {{{read_graphvis}}} doesn't try to convert an attribute value before passing it to {{{dynamic_property_map}}}, due to the fact that graphvis files contain no type information :). In its turn, a {{{dynamic_property_map}}} converts passed {{{std::string}}} to its value type successfully. Maybe a better strategy is: 1) in {{{write_graphml}}}, write attribute types as currently done. 2) in {{{read_graphml}}}, disregard attribute type information and convert string representations to values in a {{{dynamic_property_map}}}. A more sophisticated and maybe type-safe alternative is to use a more complicated logic and check {{{dynamic_property_map->value()}}} for every possible matching value type in {{{write_graphml::value_types}}} for a given type name from {{{write_graphml::type_names}}}. ",Bugs,new,To Be Determined,graph,Boost 1.55.0,Problem,,,