Parsing cfg files?

[uzurpator]

I am currently writing a project for school that involves parsing text file to turn it into more sensible form. Since TE will probably use a plethora of configuration files - would a good parser be needed?

I use tools named Lex and Yacc - they are quite efficient. Getting through 60 megabytes of data takes approx 5-10 seconds.

[Patchman]

Make XML based configuration files, then this whole issue solves itself.

[Saskia]

*uah* why do you want to take those complicated XML files?
Example for plain text:

Code: Select all

canals on

Example for XML:

Code: Select all

<!definition blabla>
<version>438.34980beta</version>
<xml blabla>
    <settings>
        <canals value="on" />
    </settings>
</xml>

There's just no need for XML in a config file for a simple game (simpler than many of today's games) ... so don't use it

[TBOT]

*uah* why do you want to take those complicated XML files?
Example for plain text:

Code: Select all

canals on

Example for XML:

Code: Select all

<!definition blabla>
<version>438.34980beta</version>
<xml blabla>
    <settings>
        <canals value="on" />
    </settings>
</xml>

There's just no need for XML in a config file for a simple game (simpler than many of today's games) ... so don't use it

Exactly TTU's point. XML was primarly designed for cross-platform and mainly cross-application dataformats. Configfiles only tend to be used by the game itself (and at most by a gui-based configuration app).
XML is overkill, and not as readable as custom design.

[ChrisCF]

Example for XML:

Code: Select all

<!definition blabla>
<version>438.34980beta</version>
<xml blabla>
    <settings>
        <canals value="on" />
    </settings>
</xml>

Would be great if only it were valid XML

Code: Select all

<?xml charset="utf-8" ?>
    <setting name="canals" value="1" />

Did I miss something?

Using plain text, you have to change the parsing code every time you want to change an option. One of the reasons for using XML is that you have a schema definition file independent of the application code itself. The parsing code can just read this blindly, since it doesn't need to know what it does (that's for other parts of the code). This is similar to what grfcodec does - it doesn't know what the format of action 0B might be, and doesn't need to either.

Using a simple textfile with unformatted attribute-value pairs is a solution which provides for less code now, but more maintenance further down the line. XML might be more work to begin with, but it will require much less maintenance, both of our own code and in third-party tools. We are taking on board both correct computing theory and sound engineering. IMO, a long-term solution constitutes better engineering practice than a short-term one.

[uzurpator]

Code: Select all

%%
canals  return tk_canals;
on|off  return tk_switch;
%%

%%
parse : tk_canals tk_switch {importantobject.adddata($2)};
%%

good parser will only accept valid data, so it will secure you from badly written cfg files. Also - it will be helluva faster then XML parsing (saving on game load times) and will save on cfg files size.

[ChrisCF]

Is a validating XML parser not a good parser then?

[uzurpator]

it is - just if:

"The parsing code can just read this blindly, since it doesn't need to know what it does (that's for other parts of the code)"

then the validation is just on the level of XML grammar. It does not validate data it parses. Good parser can do that. And i can make a parser that does just "read ... blindly" in about 20 lines of code. And for txt files that is...

[ChrisCF]

Do you have examples of where the idea of parsing-by-schema falls down?

[uzurpator]

Im not sure what you mean but...

<?xml charset="utf-8" ?>
<setting name="cnaals" value="15463" />

valid scheme? yes
valid data? not really

lex/yacc is parsing by semantics/syntax and is always accurate.

BTW I am toying with an idea txt -> nfo translation using those two tools.

[ChrisCF]

<?xml charset="utf-8" ?>
<setting name="cnaals" value="15463" />

When the schema dictates that "canals" should be a boolean value, this would either be rejected by the parser, or treated as whatever non-zero values are interpreted as. Admittedly, this would require that it were instead <canals value="off"> or something instead of <setting>.

Code: Select all

	<xs:element name="canals">
		<xs:complexType>
			<xs:sequence></xs:sequence>
			<xs:attribute name="value" type="xs:boolean" />
		</xs:complexType>
	</xs:element>

This way, when changes are made, the XML schema definition can be updated without having to update the parsing code => easier to maintain.

All of this said, I think this decision has already been made, making most of ths discussion moot.

[uzurpator]

I don't see any "canals" in that example.

Also if you already do validating then on the "scheme" ("canals", "bridges" or whatever) and it means that you have to update your parser (XML) code every time a new switch is introduced or old one changed. With Lex/Yacc you do the same but with much smaller txt files and with much greater speed.

Code: Select all

   <xs:element name="canals"> 
      <xs:complexType> 
         <xs:sequence></xs:sequence> 
         <xs:attribute name="value" type="xs:boolean" /> 
      </xs:complexType> 
   </xs:element>

in lex

Code: Select all

canals  return tk_canals; 
on|off  return tk_switch; 

in yacc

Code: Select all

canals : tk_canals tk_switch {importantobject.adddata($2)}; 

which is simpler and faster?

BTW - for your information - both lex and yacc generate C code so you don't update the parser but just generation rules.

BTW2 - canals can be used by:

canals off
canals on
canals 1
canals 0
canals = off
canals = on
canals = 1
canals = 0

it is trival to make a parser that will use all version of this.

[Saskia]

The funny thing is that you need a XSLT definition file (the <xs:...>-thingy posted by Chris) and then you can parse XML files after this scheme.

But Chris, you forgot somthing: XML ist for files that look like this:

Code: Select all

text text image
table text image anythingyoudontexpecthere text
image text ...

and not for

Code: Select all

canals = on
freighttrains = 5

You understand me? Config files contain just a few values, not a document, like a HTML file does, f. e.

Using XML is like programming in Java: in two years nobody is interested in this anymore

[uzurpator]

But Chris, you forgot somthing: XML ist for files that look like this:

Code: Select all

text text image
table text image anythingyoudontexpecthere text
image text ...

and not for

Code: Select all

canals = on
freighttrains = 5

Does not matter ^^. I can make a parser that will go through anything - probably including binaries ^^

[Arathorn]

Isn't this off-topic?