1

Topic: Friendly text format.

There is some data structure, with vectors, map, and optional variables (boost:: optional). It is required to make a user-friendly format of filling of this structure. It should be easily transparent for the user a text format. It is desirable, JSON-like, but approaches and xml (if not too overloaded). Tried Boost. Serialize in xml : boost:: optional <std:: string> comment; in xml turns in <comment class_id = "0" tracking_level = "0" version = "0"> <initialized> 1 </initialized> <item_version> 0 </item_version> <value> comment text </value> </comment> that is absolutely unacceptable. It was possible after all to be restricted to one attribute missing if the field is not set! Whether there are ready implementations of archives, a similar case? Or usage boost.serialize, basically the bad idea other approach also is necessary?

2

Re: Friendly text format.

Hello, Chorkov, you wrote: whether the C> Is ready implementations of archives, a similar case? So and actually, than JSON or Lua do not arrange?

3

Re: Friendly text format.

Hello, andrey.desman, you wrote: AD> Hello, Chorkov, you wrote: whether the C>> Is ready implementations of archives, a similar case? AD> so and actually, than JSON or Lua do not arrange? In boost.serialize is ready JSON archive?

4

Re: Friendly text format.

Hello, Chorkov, you wrote: AD>> So and actually, than JSON or Lua do not arrange? The C> In boost.serialize is ready JSON archive? It is possible to take RapidJSON and on top json_dto, it turns out almost as in Boost.

5

Re: Friendly text format.

Hello, Chorkov, you wrote: the C> In boost.serialize is ready JSON archive? And, did not understand that a question about boost:: serialize.

6

Re: Friendly text format.

The C> Or usage boost.serialize, basically the bad idea also is necessary other approach? Yes, it is better to build in the interpreter approaching  language. : attempts of usage XML or other similar format for record of the difficult data in a text format often lead as a result "" to ineffective implementation of some ugly programming language; better at once  this step. See at Eric Rejmonda more in detail.

7

Re: Friendly text format.

Hello, Chorkov, you wrote: the C> Or usage boost.serialize, basically the bad idea also is necessary other approach? Not absolutely understood the task, property_tree does not go?

8

Re: Friendly text format.

If not laziness to adapt structure under boost.fusion sequence, to write out Backus-Naur form (which becomes qi grammar) approaches boost.spirit. There all can be adjusted. Hello, Chorkov, you wrote: the C> Is some data structure, with vectors, map, and optional variables (boost:: optional). The C> Is required to make a user-friendly format of filling of this structure. The C> It should be easily transparent for the user a text format. A C> It is desirable, JSON-like, but approaches and xml (if not too overloaded).

9

Re: Friendly text format.

Hello, Chorkov, you wrote: the C> Is required to make a user-friendly format of filling of this structure. JSON? YAML? INI, TOML (it is hardly more difficult) Most simple and friendly it conf.

10

Re: Friendly text format.

Hello, Chorkov, you wrote: the C> In boost.serialize is ready JSON archive? Hammer on boost.serialize, from it other niche take any json a parcer. Json is much more comfortable for a read and write people, in particular, because of the built in support of arrays

11

Re: Friendly text format.

Hello, uzhas, you wrote: U> Hello, Chorkov, you wrote: the C>> In boost.serialize is ready JSON archive? U> hammer on boost.serialize, from it other niche U> take any json a parcer. Json is much more comfortable for a read and write people, in particular, because of the built in support of arrays Only it is desirable to be got by the editor supporting the circuit for JSON if it is necessary to write manually.

12

Re: Friendly text format.

Hello, Kswapd, you wrote: K> Yes, it is better to build in the interpreter approaching  language. : attempts of usage XML or other similar format for record of the difficult data in a text format often lead as a result "" to ineffective implementation of some ugly programming language; better at once  this step. See at Eric Rejmonda more in detail. And which book/article means? "Art of programming for Unix"?

13

Re: Friendly text format.

MD> And which book/article means? "Art of programming for Unix"? Yes. There many examples of good design of programs are collected.