[Boost-bugs] [Boost C++ Libraries] #10105: graphml attribute type mapping for types not in specification

Subject: [Boost-bugs] [Boost C++ Libraries] #10105: graphml attribute type mapping for types not in specification
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-06-07 16:53:56

#10105: graphml attribute type mapping for types not in specification
--------------------------------------------+----------------------
 Reporter:  Sergey Mitsyn <svm at jinr.ru>  |      Owner:  jewillco
     Type:  Bugs                            |     Status:  new
Milestone:  To Be Determined                |  Component:  graph
  Version:  Boost 1.55.0                    |   Severity:  Problem
 Keywords:                                  |
--------------------------------------------+----------------------
 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 ({{{<graphml>}}}'s
 {{{<key>}}} 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
 {{{<key>}}} 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}}}.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10105>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.