I haven’t said that reading JSON is any better than XML, just that
JSON is cleaner and better planned.
Until now, the only XML lib that I used was TinyXML, and it does too
much alloc/dealloc when parsing that are slow and causes
fragmentation. And I don’t remember if it has any support to custom
allocators.
It is a lot easier to use a binary format for assets, it will be
faster and better in the final product.On Wed, Apr 15, 2009 at 5:38 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
On Wed, Apr 15, 2009 at 2:09 PM, fungos <@fungos> wrote:
And for other platforms using plain xml is not good, it can cause too
much trouble with memory fragmentation. I always prefer to use XML as
intermediate format where I will create a compiler tool for a memory
optimized binary structure.
As other alternatives, I think that the best text format for
specifying things is JSON. But there are other options like libconfig
and boost::program_options.
You’re confused. XML is not inherently a source of memory
fragmentation (you can use your own fine allocator in your XML
processing code if that’s really what you want.) What makes you think
that deserializing from JSON is less fragmenty than deserializing from
XML?
I haven’t said that reading JSON is any better than XML, just that
JSON is cleaner and better planned.
Until now, the only XML lib that I used was TinyXML, and it does too
much alloc/dealloc when parsing that are slow and causes
fragmentation. And I don’t remember if it has any support to custom
allocators.
That’s your fault, not XML’s fault.
It is a lot easier to use a binary format for assets, it will be
faster and better in the final product.
You obviously haven’t been reading this thread very diligently.On Wed, Apr 15, 2009 at 5:11 PM, fungos wrote:
It’s obviously that you never made nothing for embedded platforms.On Wed, Apr 15, 2009 at 6:16 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
On Wed, Apr 15, 2009 at 5:11 PM, fungos <@fungos> wrote:
I haven’t said that reading JSON is any better than XML, just that
JSON is cleaner and better planned.
Until now, the only XML lib that I used was TinyXML, and it does too
much alloc/dealloc when parsing that are slow and causes
fragmentation. And I don’t remember if it has any support to custom
allocators.
Didn’t you guys exaust this topic already? In the end everyone has his
own prefs/religion on the issue, and it’s already getting off topic. A
few more posts and we’ll be talking about something ridiculous like
parsing xml in assembly for ARM processors.On Wed, Apr 15, 2009 at 4:46 PM, fungos wrote:
On Wed, Apr 15, 2009 at 6:16 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
On Wed, Apr 15, 2009 at 5:11 PM, fungos wrote:
I haven’t said that reading JSON is any better than XML, just that
JSON is cleaner and better planned.
Until now, the only XML lib that I used was TinyXML, and it does too
much alloc/dealloc when parsing that are slow and causes
fragmentation. And I don’t remember if it has any support to custom
allocators.
That’s your fault, not XML’s fault.
It’s obviously that you never made nothing for embedded platforms.
That, for sure would be very useful and interesting btw.
-the end-On Wed, Apr 15, 2009 at 8:50 PM, Pavel Dudrenov wrote:
Didn’t you guys exaust this topic already? In the end everyone has his
own prefs/religion on the issue, and it’s already getting off topic. A
few more posts and we’ll be talking about something ridiculous like
parsing xml in assembly for ARM processors.
On Wed, Apr 15, 2009 at 4:46 PM, fungos <@fungos> wrote:
On Wed, Apr 15, 2009 at 6:16 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
On Wed, Apr 15, 2009 at 5:11 PM, fungos <@fungos> wrote:
I haven’t said that reading JSON is any better than XML, just that
JSON is cleaner and better planned.
Until now, the only XML lib that I used was TinyXML, and it does too
much alloc/dealloc when parsing that are slow and causes
fragmentation. And I don’t remember if it has any support to custom
allocators.
That’s your fault, not XML’s fault.
It’s obviously that you never made nothing for embedded platforms.
That, for sure would be very useful and interesting btw.
iPhone and iPod touch parse a fair bit of XML (when starting apps,
saving state, setting preferences, etc) on an ARM with one of those
bloated and slow parsers, and the world hasn’t come to an end.On Wed, Apr 15, 2009 at 7:53 PM, fungos wrote:
Ohh no! What have I done.On Wed, Apr 15, 2009 at 4:59 PM, Pierre Phaneuf wrote:
On Wed, Apr 15, 2009 at 7:53 PM, fungos wrote:
That, for sure would be very useful and interesting btw.
iPhone and iPod touch parse a fair bit of XML (when starting apps,
saving state, setting preferences, etc) on an ARM with one of those
bloated and slow parsers, and the world hasn’t come to an end.
Anyway, it is not the topic, let’s STOP here.
If you people get irritated with other people opinions, you need
treatment - or ignore it. Mainly people that won’t give their opinion
but just criticize others.On Wed, Apr 15, 2009 at 8:59 PM, Pierre Phaneuf wrote:
On Wed, Apr 15, 2009 at 7:53 PM, fungos <@fungos> wrote:
That, for sure would be very useful and interesting btw.
iPhone and iPod touch parse a fair bit of XML (when starting apps,
saving state, setting preferences, etc) on an ARM with one of those
bloated and slow parsers, and the world hasn’t come to an end.
For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?
Why write the same (XML) parser over and over, when you can just use a
ready made one? I’m all for using flex/bison for a new language, but
it’s daft to reinvent the wheel for something that is already extremely
well specified, deployed and understood.
The beauty of flex and bison is that they write the parser for you.
Ignoring this point completely there are also other benefits to using a
specific XML parsing library such as the footprint being smaller and
having much more targetted features. You’d struggle to get bison to
validate XML documents against a specific schema without a fair chunk of
work, for example.
Scripts exist to automate the generation of flex and bison input files.
These tools, however are not very mature.
– Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090416/31e6e477/attachment.pgpOn Wed, Apr 15, 2009 at 01:41:17PM +0100, Tim Angus wrote:
For give me for sounding naive, but why do we need XML ‘parsers’ anyway?
What ever happened to using lex/flex and yacc/bison to parse content?
Why write the same (XML) parser over and over, when you can just use a
ready made one? I’m all for using flex/bison for a new language, but
it’s daft to reinvent the wheel for something that is already extremely
well specified, deployed and understood.
The beauty of flex and bison is that they write the parser for you.
Your response, Peter, belies the obvious fact that in casual parlance,
you still write a parser using these tools. Yes, these tools help you
do the task, but consider it in context: cannot something called an
"XML parser" ostensibly be a tool to help parse XML as lex is a tool
to help parse a wider domain of inputs?
Ignoring this point completely there are also other benefits to using a
specific XML parsing library such as the footprint being smaller and
having much more targetted features. You’d struggle to get bison to
validate XML documents against a specific schema without a fair chunk of
work, for example.
Scripts exist to automate the generation of flex and bison input files.
These tools, however are not very mature.
Could you elaborate more on this?On Thu, Apr 16, 2009 at 7:42 AM, Peter Ross wrote:
On Wed, Apr 15, 2009 at 01:41:17PM +0100, Tim Angus wrote: