Open GoogleCodeExporter opened 9 years ago
Oh, it's also worth noting that Attributes can be chained:
Element tbr("TotalBytesReceived")
("displayName", "Total Bytes Received")
("attrib2", "attrib2 value")
("attrib3", "attrib3 value");
Original comment by matt.tre...@gmail.com
on 7 Apr 2009 at 4:36
I thought that I would write here (since there is no forum) and mention that my
experience with TinyXML++ was very poor. I was looking for a quick and easy
solution
for reading/writing C++ object configuration files. As such I came across
TinyXML++
and CodeSynthesis XSD. The latter being a XML Data binder for C++. I read on
both
and decided upon TinyXML++ simply because I thought CodeSynthesis required more
configuration, making my project as a whole less portable and more hassle to
work
with at future dates if there are interruptions...i.e. I hate working with
something
and then coming back to it months later and having to figure out again how to
run a
separate compiler. I strive for simplicity in configuration, and use. So I
tried
TinyXML++ and now have decided to abandon it. Here is my brief assesment of
TinyXML++:
Documentation is very poor. Premake instructions are not up to date, and
examples in
the tutorial are incomplete.
Source commenting is almost non existent.
Was able to build lib file with MSVS but then got exception, in my program, when
trying to load a test XML file.
Tried to build TinyXML as part of my program but ran into numerous errors.
To sum up, way too much difficulty involved to mess further with, especially for
something that is supposed to be minimalistic. As a programmer I forgive a
lack of
good documentation etc. only if they just work and have zero defects.
Original comment by bhar...@gmail.com
on 23 Apr 2009 at 10:11
bhartsb,
I just don't understand why you would take the time to post if you "abandon
it". I
feel the doxygen is adequate, not perfect, but documented. Did you generate the
documentation? Or use the website? And yes the library throws exceptions, so
expect
that. It is stated in the documentation! If we have documentation on all the
methods
why do you care if the code within the functions is documented.
This message feels like a flame and I just don't accept it. Sorry, but you
could be
much more constructive.
Original comment by rpusz...@gmail.com
on 24 Apr 2009 at 1:05
Continuing on the original issue...it's also possible to use this alternative
syntax:
root += node("measurements") +=
(node("TotalBytesReceived") ("displayName", "Total Bytes Received") .Set(12),
node("TotalBytesProcessed")("displayName", "Total Bytes Processed").Set(14),
node("TotalErroredBytes") ("displayName", "Total Errored Bytes") .Set(42));
Which, although hard to read in this issue tracker, is even more compact. It's
also
harder to get wrong because parentheses are not required as much as with the
first
attempt. Here's a more complex example:
pis += node("name")("id",1) .Set("Fred"),
node("url") .Set("http://trentini.wordpress.com"),
node("status") .Set(500),
node("triggers") .Set("geoTrigger"),
node("stops") .Set("stopsDoc"),
node("function") +=
( node("name") .Set("step next"),
node("url") .Set("sn"),
node("parameter") +=
( node("name") .Set("stepnext"),
node("value") .Set(10),
node("caption") .Set("Count"),
node("description").Set("Repeat value")
)
);
Achieving this syntax is a little complex but the above is compiling code and
produces the expected XML. I find it very readable and easy to understand. The
implementation code is not particularly neat yet but if anyone wants a patch
let me
know.
Most of it (with the exception of 'Set') is defined outside of ticpp so it
could even
be used with little modification to ticpp itself. A client could just #include
"alternative_ticpp_syntax.h" and use it...
Original comment by matt.tre...@gmail.com
on 29 Apr 2009 at 12:32
Do you want to be a developer? If so, you can just branch to add this.
I think I would prefer to have have this be an include, this way it is optional
and
doen't put more into the already large ticpp class.
Original comment by rpusz...@gmail.com
on 29 Apr 2009 at 3:37
Sure, that'd be great.
I agree that it'd probably be best to have a separate header for the
'alternative'
syntax. However there needs to be at least two additions to ticpp.h:
operator()()
(for attribute chaining) and Set(). Both have to be member functions.
Original comment by matt.tre...@gmail.com
on 30 Apr 2009 at 10:32
You are now a developer.
It is fine with me to add the needed additions in ticpp.h. So create a branch
and
have fun. Thanks.
Original comment by rpusz...@gmail.com
on 30 Apr 2009 at 1:48
I've begun experimenting with changes on my branch:
https://ticpp.googlecode.com/svn/branches/matt.trentini/alternative_syntax
Any feedback would be welcome!
Original comment by matt.tre...@gmail.com
on 20 Jun 2009 at 1:16
The branch is good,but I compile your sugar's example code on VS2008,then I see
the
warning.Could you help me to clear these warnings? thanks....
warning C4239: nonstandard extension used : 'argument' : conversion from
'ticpp::sugar::NodeCombiner' to 'ticpp::sugar::NodeCombiner &'
A non-const reference may only be bound to an lvalue
warning C4239: nonstandard extension used : 'argument' : conversion from
'ticpp::Comment' to 'ticpp::Node &'
A non-const reference may only be bound to an lvalue
Original comment by rswa...@gmail.com
on 8 Sep 2009 at 2:40
On the off chance this thread is still alive...
Matt - I'd be interested in the further patches - I've tried your branch but it
only contains some of the changes you mentioned. Otherwise I'll try
implementing something myself and will post it up if anyone's interested.
Thanks!
Alex
Original comment by Alexande...@gmail.com
on 31 Aug 2011 at 3:39
Original issue reported on code.google.com by
matt.tre...@gmail.com
on 7 Apr 2009 at 2:26Attachments: