[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.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:16 UTC