Comments you submit will be routed for moderation. If you have an account, please log in first.

Ticket #4061 (new task)

Opened 10 years ago

Last modified 8 years ago

OptionParser XML processing && stream operators

Reported by: wehart Owned by: jdsiiro
Priority: major Milestone: 4.x
Component: Source Code Version: 3.3
Keywords: Cc:


The OptionParser? class supports initialization of Parameter data from strings. This relies on the I/O serialization for the core data type that is managed in the Parameter's Any object.

This stream serialization does not leverage the XML parser mechanism that John S. developed in COLIN. That _seems_ to centralize the XML parsing in an undesirable way, so I did not rework the Parameter mechanism. However, that mechanism does have the advantage of providing a more flexible parse of complex objects (e.g. arrays and matrices).


Change History

comment:1 Changed 10 years ago by jdsiiro

I think that you are referring to parse_xml_data() in  source:colin/trunk/src/TinyXML_data_parser.cpp. That centralization was needed to support cases where we were parsing incoming data into an Any, and the caller may not know the exact data type that is represented within the data file (so it cannot pre-populate the Any).

I did not leverage the operator>>(ostream&, T) methods from Utilib because I am still uneasy with the use of ostream-based operator<<() and operator>>() as serialization operators. In general, I see operator<<() as providing human-readable output (and not necessarily full state information). This can even be a problem for "normal" dataypes like double: by default operator<<(ostream&, double) only prints 4-5 significant digits!

comment:2 Changed 10 years ago by wehart

  • Summary changed from Validate OptionParser XML processing to OptionParser XML processing && stream operators
  • Milestone changed from 4.0 to 4.1

I've moved this to UTILIB 4.1. In addition to validating this XML mechanism, we should consider whether it makes sense to standardize on the use of a string serialization strategy that is less 'lossy'. For example, storing large-precision doubles.

I think that this makes sense. However, I don't want to make it difficult for users to pass in options on a command line...

comment:3 Changed 9 years ago by wehart

  • Milestone 4.1 deleted

comment:4 Changed 8 years ago by jdsiiro

  • Milestone set to 4.x

Add a comment

Modify Ticket

Change Properties
<Author field>
as new

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.