Discussion:
STL (was RE: [CsMain] Re: Licensing problem with RAPID)
(too old to reply)
Ogles, Dan
2000-03-13 21:11:05 UTC
Permalink
I'm interested in this as well. I'm writing a library that loads and saves
CS worlds as XML, providing a heirarchal worldfile format that will help to
allow plug-in objects to serialize themselves as part of the world data.

I also have written a program that compares two XML files and writes the
difference as an XML file. I plan to use this for save-games, where the
save-game is the difference between the original world file and the current
state of the world (to save space). I'd also like to use it for things like
the SCF registry, configuration files, etc. Having a standard format for all
of these things would be useful, IMHO.

The XML parser I wrote uses STL pretty heavily though. I decided to use STL
because I like type safety and it's standard so people won't have to learn
yet another list class, map class, string class, etc. Since XML is a more
powerful format than the current worldfile syntax, I'd personally like to
see it eventually become the standard (so we don't have to support two
formats).

Is the NeXT platform still supported by CS? Is anyone using it? In my humble
opinion, it'd be more important to have good type-safety and standard
classes than to support legacy platforms. I know this argument has been made
before, so I won't pursue it. I just want to have a full understanding of
the reasoning behind the decision not to use the STL.

--dan
-----Original Message-----
Sent: Sunday, March 12, 2000 4:04 PM
Subject: Re: [CsMain] Re: Licensing problem with RAPID
It is gcc. But an older version. Nobody seems interested in
updating it
to more recent versions apparantly.
Is it possible for users to upgrade it themselves?
Michael
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
dyad
2000-03-13 22:29:01 UTC
Permalink
Post by Ogles, Dan
I'm interested in this as well. I'm writing a library that loads and saves
CS worlds as XML, providing a heirarchal worldfile format that will help to
allow plug-in objects to serialize themselves as part of the world data.
I also have written a program that compares two XML files and writes the
difference as an XML file. I plan to use this for save-games, where the
save-game is the difference between the original world file and the current
state of the world (to save space). I'd also like to use it for things like
the SCF registry, configuration files, etc. Having a standard format for all
of these things would be useful, IMHO.
The XML parser I wrote uses STL pretty heavily though. I decided to use STL
because I like type safety and it's standard so people won't have to learn
yet another list class, map class, string class, etc. Since XML is a more
powerful format than the current worldfile syntax, I'd personally like to
see it eventually become the standard (so we don't have to support two
formats).
WOW!!!!! Oh goody! Wait, oh NO! CS doesn't want STL!!
Post by Ogles, Dan
Is the NeXT platform still supported by CS?
Yes!
Post by Ogles, Dan
Is anyone using it?
Yes!
Post by Ogles, Dan
I just want to have a full understanding of
the reasoning behind the decision not to use the STL.
I'm sure someone else can better explain it... :)
Ogles, Dan
2000-03-13 22:42:35 UTC
Permalink
<snip>
Post by Ogles, Dan
Post by Ogles, Dan
The XML parser I wrote uses STL pretty heavily though. I
decided to use STL
Post by Ogles, Dan
because I like type safety and it's standard so people
won't have to learn
Post by Ogles, Dan
yet another list class, map class, string class, etc. Since
XML is a more
Post by Ogles, Dan
powerful format than the current worldfile syntax, I'd
personally like to
Post by Ogles, Dan
see it eventually become the standard (so we don't have to
support two
Post by Ogles, Dan
formats).
WOW!!!!! Oh goody! Wait, oh NO! CS doesn't want STL!!
Umm.. do I detect sarcasm? (It's hard to sometimes over email).

--dan
dyad
2000-03-13 22:57:38 UTC
Permalink
Post by Ogles, Dan
Post by dyad
WOW!!!!! Oh goody! Wait, oh NO! CS doesn't want STL!!
Umm.. do I detect sarcasm? (It's hard to sometimes over email).
Hehe, so true! I didn't intend any sarcasm; I'm really interested! :)


Justin
Malakai
2000-03-14 02:44:47 UTC
Permalink
funny, I've spent the last couple of days at work building a large XSD for a
project that uses xml (as per http://www.w3.org/TR/xmlschema-0/ and
http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/).

Are you planning on make a xsd for the world format? or if you didn't want
to deal with "working drafts" a dtd would work.

I think it's a shame the documentation didn't go the XML route, but lets try
and get all our configuration and data files "XML'ized". The more we use it,
the more people will learn it, and it's like understanding the wheel. Once
you know it, it's useful practically *everywhere*.

-frank


Original Message -----
From: Ogles, Dan <***@peachtree.com>
To: <crystal-***@lists.sourceforge.net>
Sent: Monday, March 13, 2000 4:11 PM
Subject: STL (was RE: [CsMain] Re: Licensing problem with RAPID)
Post by Ogles, Dan
I'm interested in this as well. I'm writing a library that loads and saves
CS worlds as XML, providing a heirarchal worldfile format that will help to
allow plug-in objects to serialize themselves as part of the world data.
I also have written a program that compares two XML files and writes the
difference as an XML file. I plan to use this for save-games, where the
save-game is the difference between the original world file and the current
state of the world (to save space). I'd also like to use it for things like
the SCF registry, configuration files, etc. Having a standard format for all
of these things would be useful, IMHO.
The XML parser I wrote uses STL pretty heavily though. I decided to use STL
because I like type safety and it's standard so people won't have to learn
yet another list class, map class, string class, etc. Since XML is a more
powerful format than the current worldfile syntax, I'd personally like to
see it eventually become the standard (so we don't have to support two
formats).
Is the NeXT platform still supported by CS? Is anyone using it? In my humble
opinion, it'd be more important to have good type-safety and standard
classes than to support legacy platforms. I know this argument has been made
before, so I won't pursue it. I just want to have a full understanding of
the reasoning behind the decision not to use the STL.
--dan
-----Original Message-----
Sent: Sunday, March 12, 2000 4:04 PM
Subject: Re: [CsMain] Re: Licensing problem with RAPID
It is gcc. But an older version. Nobody seems interested in
updating it
to more recent versions apparantly.
Is it possible for users to upgrade it themselves?
Michael
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Jorrit Tyberghein
2000-03-14 07:07:36 UTC
Permalink
Post by Ogles, Dan
The XML parser I wrote uses STL pretty heavily though. I decided to use STL
because I like type safety and it's standard so people won't have to learn
yet another list class, map class, string class, etc. Since XML is a more
powerful format than the current worldfile syntax, I'd personally like to
see it eventually become the standard (so we don't have to support two
formats).
Is the NeXT platform still supported by CS? Is anyone using it?
The NeXT platform is still supported. And Eric Sunshine still uses it.

NeXT is Eric's main platform. And since Eric is in the top three
contributing developers I consider that alone good enough reason to avoid
STL. Actually the top three of contributing developers which are:

- Jorrit Tyberghein
- Andrew Zabolotny
- Eric Sunshine

all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew has problems with
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.

Use STL in important parts of CS and you make work harder/impossible
for those three people.

Greetings,

--
==============================================================================
***@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

Voodoo is a very interesting religion for the whole family, even those
members of it who are dead.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
==============================================================================
Michael Day
2000-03-14 07:47:13 UTC
Permalink
Post by Jorrit Tyberghein
all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew has problems with
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.
Doesn't gcc support all of these platforms? (Solaris, OS/2 and NeXTStep)
Can people upgrade their compilers?

Michael
Jorrit Tyberghein
2000-03-14 09:12:12 UTC
Permalink
Post by Michael Day
Post by Jorrit Tyberghein
all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew has problems with
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.
Doesn't gcc support all of these platforms? (Solaris, OS/2 and NeXTStep)
Can people upgrade their compilers?
Ok. Here are the problems:

For me: I don't have root access here and don't have enough space
to install a new gcc. I can't convince my sysadmin to install a new
gcc which is otherwise not used except by me.

For Eric and Andrew. Porting a new version of gcc is not a trivial task.
You cannot just take a new gcc and compile it. The OS'es are too
different for that. gcc 2.5.2 is the latest one supported on NeXTStep
and the people who did that port don't maintain it anymore.

Greetings,


--
==============================================================================
***@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

Voodoo is a very interesting religion for the whole family, even those
members of it who are dead.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
==============================================================================
Michael Day
2000-03-14 08:27:30 UTC
Permalink
Post by Jorrit Tyberghein
For me: I don't have root access here and don't have enough space
to install a new gcc. I can't convince my sysadmin to install a new
gcc which is otherwise not used except by me.
Aside from finding a crucial bug in important code that only a new version
of gcc could possibly fix, I guess there's not much that can be done about
that :)
Post by Jorrit Tyberghein
For Eric and Andrew. Porting a new version of gcc is not a trivial task.
You cannot just take a new gcc and compile it. The OS'es are too
different for that. gcc 2.5.2 is the latest one supported on NeXTStep
and the people who did that port don't maintain it anymore.
I see. And the native compilers on both platforms are not sufficiently
capable to handle the full standard library? That is quite unfortunate.

Michael
Jorrit Tyberghein
2000-03-14 09:33:44 UTC
Permalink
Post by Michael Day
Post by Jorrit Tyberghein
For Eric and Andrew. Porting a new version of gcc is not a trivial task.
You cannot just take a new gcc and compile it. The OS'es are too
different for that. gcc 2.5.2 is the latest one supported on NeXTStep
and the people who did that port don't maintain it anymore.
I see. And the native compilers on both platforms are not sufficiently
capable to handle the full standard library? That is quite unfortunate.
The problem with NeXTStep is that it is by nature an Objective C platform.
So gcc is actually the ONLY C++ compiler (as far as I know). If we would
rewrite CS in Objective C... :-)

Greetings,


--
==============================================================================
***@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

Voodoo is a very interesting religion for the whole family, even those
members of it who are dead.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
==============================================================================
Aaron Drew
2000-03-14 11:18:06 UTC
Permalink
Would someone care to elaborate on the acronym STL for me?? I'm a little
lost here...

As for the compiler issue, I havn't had the need to do this but it is
possible to set up GCC to do a cross compile. This basically involves having
GCC compile itself on a platform like linux but the resulting compiler
executable would create code for another system (NeXT or OS/2). You can use
this to compile GCC executables for these systems. As I said, I havn't done
it but theres been plenty of linux ports to ARM, PowerPC, PalmOS and others
that there should be sufficient info out there if anyone felt the need to.
As I don't know what STL stands for I can't really judge. :)

-----Original Message-----
From: crystal-main-***@lists.sourceforge.net
[mailto:crystal-main-***@lists.sourceforge.net]On Behalf Of Jorrit
Tyberghein
Sent: Tuesday, March 14, 2000 8:34 PM
To: crystal-***@lists.sourceforge.net
Subject: Re: STL (was RE: [CsMain] Re: Licensing problem with RAPID)
Post by Michael Day
Post by Jorrit Tyberghein
For Eric and Andrew. Porting a new version of gcc is not a trivial
task.
Post by Michael Day
Post by Jorrit Tyberghein
You cannot just take a new gcc and compile it. The OS'es are too
different for that. gcc 2.5.2 is the latest one supported on NeXTStep
and the people who did that port don't maintain it anymore.
I see. And the native compilers on both platforms are not sufficiently
capable to handle the full standard library? That is quite unfortunate.
The problem with NeXTStep is that it is by nature an Objective C platform.
So gcc is actually the ONLY C++ compiler (as far as I know). If we would
rewrite CS in Objective C... :-)

Greetings,


--
============================================================================
==
***@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

Voodoo is a very interesting religion for the whole family, even those
members of it who are dead.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
============================================================================
==
Andrew Zabolotny
2000-03-14 12:21:33 UTC
Permalink
Post by Jorrit Tyberghein
all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew has problems with
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.
The real reasons why I wouldn't like using STL in CS (and anywhere else) are the
following:

-*- STL uses exceptions. gcc above 2.8.0 has exceptions but I don't like how
they are implemented. They are implemented by using frame-unwind-info that is a
quite big size overhead on x86 (typically if you use unwind info the executable
size increases by about 50%). Try to remove -fno-exceptions switch from the
makefile for your system and you will understand what I mean. MSVC and alike use
an alternative method (gcc also implements a similar method, it can be selected
by specifying "-fsjlj-exceptions" switch). The executable size does not increase
that much (although increases anyway) but the other drawback is that code
executes slower. Each try{}/catch is a considerable amount of code, and that's
certainly not good for such a project like CS where speed is the most important
criterium.

-*- STL increases a lot code size per se because STL itself is quite big (gcc
libstdc++ is about 400K). The STL classes are heavily using each other, thus
if you use just the streams, you will end up with half of STL being linked
into your program.

-*- STL uses templates extensively. Templates also tend to increase code size.

In overall, if we use STL I estimate the overall execution speed will decrease
by about 5-10% and the overall executable size will increase about twice. I
don't think the benefits of using STL (I personally don't see any except it is
standard) balance the minuses of using it.

Greetings,
_\***@teamOS/2
Peter Ashford
2000-03-14 20:23:21 UTC
Permalink
In addition, the STL introduces a completely different style of programming
that IMHO does not mesh well with OOP.

Peter.
Post by Andrew Zabolotny
Post by Jorrit Tyberghein
all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew has problems with
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.
The real reasons why I wouldn't like using STL in CS (and anywhere else) are the
-*- STL uses exceptions. gcc above 2.8.0 has exceptions but I don't like how
they are implemented. They are implemented by using frame-unwind-info that is a
quite big size overhead on x86 (typically if you use unwind info the executable
size increases by about 50%). Try to remove -fno-exceptions switch from the
makefile for your system and you will understand what I mean. MSVC and alike use
an alternative method (gcc also implements a similar method, it can be selected
by specifying "-fsjlj-exceptions" switch). The executable size does not increase
that much (although increases anyway) but the other drawback is that code
executes slower. Each try{}/catch is a considerable amount of code, and that's
certainly not good for such a project like CS where speed is the most important
criterium.
-*- STL increases a lot code size per se because STL itself is quite big (gcc
libstdc++ is about 400K). The STL classes are heavily using each other, thus
if you use just the streams, you will end up with half of STL being linked
into your program.
-*- STL uses templates extensively. Templates also tend to increase code size.
In overall, if we use STL I estimate the overall execution speed will decrease
by about 5-10% and the overall executable size will increase about twice. I
don't think the benefits of using STL (I personally don't see any except it is
standard) balance the minuses of using it.
Greetings,
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
--
"The struggle for freedom is the struggle
of memory against forgetting"

-- Milan Kundera
Brandon Ehle
2000-03-14 17:05:31 UTC
Permalink
Post by Michael Day
I see. And the native compilers on both platforms are not sufficiently
capable to handle the full standard library? That is quite unfortunate.
For me, the lack of STL and templates was an issue at first. But then I decided to forget about
it and start work on implementing some scripting languages that would work exactly the same across
every platform. Also we get byte code that need not be recompiled for each platform. The biggest
advantage of this is that languages like Java & Python are much more powerful than C++ and less
error prone ones like Eiffel. So at the very min, expect support for Java & Python and hooks
available for Eiffel, Tcl, Perl.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Jason Platt
2000-03-14 19:50:26 UTC
Permalink
Standard Template Library: Which is a bunch of routines (classes,
etc..) which implement commonly used algorithms in a data-inspecific
way. (what?) It gives you things like stacks, linked-lists,
doubly-linked-lists, bags, collections, etc. With iterators and such so
that you can use the 'Template' to substitute in whichever type of data
you want (ie: integers, floats, unions, structs, classes, etc..). It is
very powerful and makes implementing things (such as linked-lists)
easier because you don not have to write it from scratch. STL
implementations tend to use quite a bit of the OOP part of C++ (like
exceptions, inheritance, friends, etc..). The problem is that STL
hasn't been implemented across platforms in the same way (in some
instances), and that because compilers don't all follow the same rules
STL will sometimes behave in different ways.

I have a lovely book on STL at home, nicely titled 'STL: The Standard
Template Libarary."
Post by Aaron Drew
Would someone care to elaborate on the acronym STL for me?? I'm a
little
lost here...
As for the compiler issue, I havn't had the need to do this but it is
possible to set up GCC to do a cross compile. This basically involves
having
GCC compile itself on a platform like linux but the resulting
compiler
executable would create code for another system (NeXT or OS/2). You
can use
this to compile GCC executables for these systems. As I said, I
havn't done
it but theres been plenty of linux ports to ARM, PowerPC, PalmOS and
others
that there should be sufficient info out there if anyone felt the
need to.
As I don't know what STL stands for I can't really judge. :)
-----Original Message-----
Tyberghein
Sent: Tuesday, March 14, 2000 8:34 PM
Subject: Re: STL (was RE: [CsMain] Re: Licensing problem with RAPID)
Post by Michael Day
Post by Jorrit Tyberghein
For Eric and Andrew. Porting a new version of gcc is not a
trivial
task.
Post by Michael Day
Post by Jorrit Tyberghein
You cannot just take a new gcc and compile it. The OS'es are
too
Post by Michael Day
Post by Jorrit Tyberghein
different for that. gcc 2.5.2 is the latest one supported on
NeXTStep
Post by Michael Day
Post by Jorrit Tyberghein
and the people who did that port don't maintain it anymore.
I see. And the native compilers on both platforms are not
sufficiently
Post by Michael Day
capable to handle the full standard library? That is quite
unfortunate.
The problem with NeXTStep is that it is by nature an Objective C
platform.
So gcc is actually the ONLY C++ compiler (as far as I know). If we
would
rewrite CS in Objective C... :-)
Greetings,
--
============================================================================
Post by Aaron Drew
==
BELGIUM
Voodoo is a very interesting religion for the whole family, even
those
members of it who are dead.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
============================================================================
Post by Aaron Drew
==
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
=====
Jason Platt.

"In theory: theory and practice are the same.
In practice: they arn't."

ICQ# 1546328
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Andrew Zabolotny
2000-03-16 11:11:05 UTC
Permalink
-/- Completely removed MIPMAP_MODE=nice/verynice. This made the code a bit
cleaner and a bit faster (this was checked even during rendering of each
polygon). Also removed BLEND_MIPMAP0 which was simply ugly.
-/- Fixed the bug with lighmaps and AMBIENT_WHITE=50 (Eric).
-/- Fixed the bug with vertical strips of garbage being displayed in specific
places of maze.zip (Eric again).
-/- Added csMatrix2 class to math2d.h. I need it for MazeD (texture mapping).
-/- Fixed a bug in graph2d.cpp that caused horizontal lines to be displayed
much slower than they could be.
-/- Further improvement on texture mapping in MazeD. Now correctly reads
texture mapping parameters from world file.
-/- Added "show console" menu item to MazeD.
-/- Added per-texture MIPMAP(yes|no) and DITHER(yes|no) option. I.e. you can
write in world file:
TEXTURE 'red ball' (FILE (/lib/tex/redball.gif) MIPMAP(no) DITHER(yes))
Dithering is not by default off in soft3d.cfg.

P.S. for Seth: you should enable dithering in sqk1.zip just for the sky...
everything other converts to 256 colors without dithering quite well.

Greetings,
_\***@teamOS/2
Ogles, Dan
2000-03-16 15:48:23 UTC
Permalink
Hi,

First of all, I'm NOT an advocate of using STL everywhere. Where speed
counts, use your own code. In the core engine, it makes no sense (for the
reasons described by Andrew below). However, I don't think there should be
any problems with external (optional) modules not tied to the rendering loop
using whatever libraries they want. If csxml becomes popular or desired as
part of the core distribution for CS, I'll convert it from STL to something
else. The only problem right now is that it uses exceptions for error
handling, so it would take a little bit of work to change that. In the
meantime, I wrote it using STL so that I wouldn't have to waste time writing
or learning a new string class, list class, map class, and so on. It's
really a shame that we can't use the more robust features of C++ (such as
templates and exceptions) where appropriate, but I guess that is the price
one pays for portability.

I'm working on the world2xml converter now, then I'll write the xml world
loader. If people like it as a replacement for the current world format,
then I'll convert it to something else. Note: none of the XML code exposes
STL classes, it's only used internally and it isn't required for the modules
using it. So if I do convert it, the client apps won't have to be changed.

--dan
-----Original Message-----
Sent: Tuesday, March 14, 2000 7:22 AM
Subject: [CsMain] Reasons NOT to use STL
Post by Jorrit Tyberghein
all have problems with STL in some degree. I have problems with it
because on Solaris here at work we simply don't have the standard C++
library installed (and no option of installing it). Andrew
has problems with
Post by Jorrit Tyberghein
it because on OS/2 the implementation of STL is severely lacking and
OS/2 is the main platform for Andrew. And Eric has problems with it
because his platform (NeXT) doesn't even have the option of using
STL right now.
The real reasons why I wouldn't like using STL in CS (and
anywhere else) are the
-*- STL uses exceptions. gcc above 2.8.0 has exceptions but I
don't like how
they are implemented. They are implemented by using
frame-unwind-info that is a
quite big size overhead on x86 (typically if you use unwind
info the executable
size increases by about 50%). Try to remove -fno-exceptions
switch from the
makefile for your system and you will understand what I mean.
MSVC and alike use
an alternative method (gcc also implements a similar method,
it can be selected
by specifying "-fsjlj-exceptions" switch). The executable
size does not increase
that much (although increases anyway) but the other drawback
is that code
executes slower. Each try{}/catch is a considerable amount of
code, and that's
certainly not good for such a project like CS where speed is
the most important
criterium.
-*- STL increases a lot code size per se because STL itself
is quite big (gcc
libstdc++ is about 400K). The STL classes are heavily
using each other, thus
if you use just the streams, you will end up with half of
STL being linked
into your program.
-*- STL uses templates extensively. Templates also tend to
increase code size.
In overall, if we use STL I estimate the overall execution
speed will decrease
by about 5-10% and the overall executable size will increase
about twice. I
don't think the benefits of using STL (I personally don't see
any except it is
standard) balance the minuses of using it.
Greetings,
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Ogles, Dan
2000-03-16 16:06:07 UTC
Permalink
I'm currently in the process of learning XSD, so maybe (or maybe not). Note
that the XML parser I wrote does not do XSD or DTDs, and I don't think it's
necessary to do so.

I'll post updates as things progress. Right now, the XML stuff is fully
written and I'm reviewing the CS code to determine the best plan of attack.
First I'll write the XML saver/converter, and then I'll write the loader.

--dan
-----Original Message-----
Sent: Monday, March 13, 2000 9:45 PM
Subject: [CsMain] XML world file... xsd anyone?
funny, I've spent the last couple of days at work building a
large XSD for a
project that uses xml (as per http://www.w3.org/TR/xmlschema-0/ and
http://www.w3.org/TR/xmlschema-1/ and
http://www.w3.org/TR/xmlschema-2/).
Are you planning on make a xsd for the world format? or if
you didn't want
to deal with "working drafts" a dtd would work.
I think it's a shame the documentation didn't go the XML
route, but lets try
and get all our configuration and data files "XML'ized". The
more we use it,
the more people will learn it, and it's like understanding
the wheel. Once
you know it, it's useful practically *everywhere*.
-frank
Original Message -----
Sent: Monday, March 13, 2000 4:11 PM
Subject: STL (was RE: [CsMain] Re: Licensing problem with RAPID)
Post by Ogles, Dan
I'm interested in this as well. I'm writing a library that
loads and saves
Post by Ogles, Dan
CS worlds as XML, providing a heirarchal worldfile format
that will help
to
Post by Ogles, Dan
allow plug-in objects to serialize themselves as part of
the world data.
Post by Ogles, Dan
I also have written a program that compares two XML files
and writes the
Post by Ogles, Dan
difference as an XML file. I plan to use this for
save-games, where the
Post by Ogles, Dan
save-game is the difference between the original world file and the
current
Post by Ogles, Dan
state of the world (to save space). I'd also like to use it
for things
like
Post by Ogles, Dan
the SCF registry, configuration files, etc. Having a
standard format for
all
Post by Ogles, Dan
of these things would be useful, IMHO.
The XML parser I wrote uses STL pretty heavily though. I
decided to use
STL
Post by Ogles, Dan
because I like type safety and it's standard so people
won't have to learn
Post by Ogles, Dan
yet another list class, map class, string class, etc. Since
XML is a more
Post by Ogles, Dan
powerful format than the current worldfile syntax, I'd
personally like to
Post by Ogles, Dan
see it eventually become the standard (so we don't have to
support two
Post by Ogles, Dan
formats).
Is the NeXT platform still supported by CS? Is anyone using
it? In my
humble
Post by Ogles, Dan
opinion, it'd be more important to have good type-safety
and standard
Post by Ogles, Dan
classes than to support legacy platforms. I know this
argument has been
made
Post by Ogles, Dan
before, so I won't pursue it. I just want to have a full
understanding of
Post by Ogles, Dan
the reasoning behind the decision not to use the STL.
--dan
-----Original Message-----
Sent: Sunday, March 12, 2000 4:04 PM
Subject: Re: [CsMain] Re: Licensing problem with RAPID
It is gcc. But an older version. Nobody seems interested in
updating it
to more recent versions apparantly.
Is it possible for users to upgrade it themselves?
Michael
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Thomas Hieber
2000-03-16 18:44:47 UTC
Permalink
Post by Ogles, Dan
I'm currently in the process of learning XSD, so maybe (or maybe not). Note
that the XML parser I wrote does not do XSD or DTDs, and I don't think it's
necessary to do so.
I'll post updates as things progress. Right now, the XML stuff is fully
written and I'm reviewing the CS code to determine the best plan of attack.
First I'll write the XML saver/converter, and then I'll write the loader.
Please note, that there is already some simple XML export in map2cs, that
has been added by Petr Kocmid mailto:***@atlas.cz
To test it, just call map2cs and use xml=outputfilename.xml instead of just
giving a regular output filename.
The current output is very limited, but the structures have all been layed
to allow all features of the regular CS world format to become a part of the
xml output format too.
If I were you, I would take a look at map2cs before doing an world to xml
convertor.

Thomas
Ogles, Dan
2000-03-16 19:05:11 UTC
Permalink
Thanks for the tip... I'll look at it before I continue. At the very least,
it should serve as a template for my work. However, I do not plan to convert
from the world file to the xml file directly... I actually plan to load it
using the existing CS code, then take the resulting csWorld object and save
that. That way I won't have to delve into the structure of world files... I
have to write this part anyway for save-games.

--dan
-----Original Message-----
Sent: Thursday, March 16, 2000 1:45 PM
Subject: Re: [CsMain] XML world file... xsd anyone?
Post by Ogles, Dan
I'm currently in the process of learning XSD, so maybe (or
maybe not).
Note
Post by Ogles, Dan
that the XML parser I wrote does not do XSD or DTDs, and I
don't think
it's
Post by Ogles, Dan
necessary to do so.
I'll post updates as things progress. Right now, the XML
stuff is fully
Post by Ogles, Dan
written and I'm reviewing the CS code to determine the best plan of
attack.
Post by Ogles, Dan
First I'll write the XML saver/converter, and then I'll
write the loader.
Please note, that there is already some simple XML export in
map2cs, that
To test it, just call map2cs and use xml=outputfilename.xml
instead of just
giving a regular output filename.
The current output is very limited, but the structures have
all been layed
to allow all features of the regular CS world format to
become a part of the
xml output format too.
If I were you, I would take a look at map2cs before doing an
world to xml
convertor.
Thomas
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Thomas Hieber
2000-03-16 20:33:35 UTC
Permalink
Post by Ogles, Dan
Thanks for the tip... I'll look at it before I continue. At the very least,
it should serve as a template for my work. However, I do not plan to convert
Post by Ogles, Dan
from the world file to the xml file directly... I actually plan to load it
using the existing CS code, then take the resulting csWorld object and save
that.
I would call this a challenging task, but well... here you go.
Post by Ogles, Dan
That way I won't have to delve into the structure of world files... I
have to write this part anyway for save-games.
I would not use engine data for savegames. Normally you would have a game
layer on top of the engine, so it would probably be much easier to store
information like "ammunition at (125,34,87)", "dead corpse at (1,32,54)" and
then have the game objects control the according engine objects. For a game
you need to store game information anyway, and so most of the engine data is
redundant.

Thomas
Ogles, Dan
2000-03-17 15:13:32 UTC
Permalink
<snip>
Post by Thomas Hieber
Post by Ogles, Dan
That way I won't have to delve into the structure of world files... I
have to write this part anyway for save-games.
I would not use engine data for savegames. Normally you would
have a game
layer on top of the engine, so it would probably be much
easier to store
information like "ammunition at (125,34,87)", "dead corpse at
(1,32,54)" and
then have the game objects control the according engine
objects. For a game
you need to store game information anyway, and so most of the
engine data is
redundant.
*Most* of the engine data is redundant, but often times not all. For
instance: say that you have a building in your world, made up of sectors.
You want the player to be able to destroy the building. If the player
destroys the building and saves his game, you'd like the building to not be
there when he loads again. So you need to record the fact that the building
is destroyed. You could have the game store a flag in the file that
determines whether the building is destroyed or not, but that's extra
complexity that's not really needed.

For savegames, I first serialize the current world into an in-memory XML
document. I then compare it with the original XML document, and only write
out the differences between the two as the savegame. That way, the redundant
engine data is not recorded anywhere except in the original worldfile. Only
the information required (e.g., that certain sectors were deleted from the
world when destroying the building) is put in the savegame. When the
savegame is loaded, the savegame is then merged with the original worldfile
to produce the current state of the world. The framework I'm devising does
this all behind the scenes, so the engine and game-layer don't have to worry
about it.

Also, since XML is a heirarchal storage format, I'll provide the means to
store custom objects (other than the engine objects), so that the game-layer
can take advantage of this functionality as well.

There are a few more interesting details, but I'm going to wait until it's a
little closer to completion before I tell all my secrets. ;-)
--dan
Peter Donald
2000-03-17 23:36:39 UTC
Permalink
Subject: [CsMain] Reasons NOT to use STL
The real reasons why I wouldn't like using STL in CS (and anywhere else)
are the
-*- STL uses exceptions. gcc above 2.8.0 has exceptions but I don't like how
they are implemented. They are implemented by using frame-unwind-info that
is ...
I am not sure which MSVC version you talk about but VC6 has a no-cost if no
use policy. Although it still results in a 8 byte increase in stack frames
it is not a huge increase and it offers a lot of flexibility.
-*- STL increases a lot code size per se because STL itself is quite big (gcc
libstdc++ is about 400K). The STL classes are heavily using each
other, thus
if you use just the streams, you will end up with half of STL being
linked
into your program.
STL is virtually all templated code (STL == Standard Template Library) so
you only poay for what you use. In some cases (ie streams) the cost is
higher but it is generally not that big and the 400K for libstdc++ will
generally not happen. (Unless you want to use streams ....).
-*- STL uses templates extensively. Templates also tend to increase code
size.

yep ... they have a tendancy to increase code size, decrease execution
speed in debug but ...
In overall, if we use STL I estimate the overall execution speed will
decrease
by about 5-10% and the overall executable size will increase about twice.
Either
a> you dont know how to use STL
b> Never used STL
c> Your trying to spread information so that you get your own way

STL does not increase execution time .... in most cases it will decrease
execution time (because in releas builds a vast proportion of code is
inlined -- which is partially the reason that executable size increases).

In our case it will probably double compilation time, increase execution
speed, increase executable size (not sure by how much ... never been a
concern with me). I am not advocating using it (because of
non-compatabilities on certain platforms) but I dislike the spread of
mis-information.

STL offers a lot of things and parts where it excells cs has replacements
anyway (like csVector). The replacements may not be as fast or efficient
but they are cross-platform and changing the paradigm of how cs works would
be a massive task.


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Andrew Zabolotny
2000-03-20 09:11:29 UTC
Permalink
Post by Peter Donald
Post by Andrew Zabolotny
-*- STL uses exceptions. gcc above 2.8.0 has exceptions but I don't like how
they are implemented. They are implemented by using frame-unwind-info that
is ...
I am not sure which MSVC version you talk about but VC6 has a no-cost if no
use policy. Although it still results in a 8 byte increase in stack frames
it is not a huge increase and it offers a lot of flexibility.
I'm very glad MSVC does this. However there's a lot of people that don't use
MSVC, maybe you heard that, I'm not sure. Latest gcc (2.8.0 and above) adds
frame-unwind-info even if you don't do a single throw() because it doesn't know
in advance whenever some exceptions can *pass* through that code (it needs to
know for each routine how to unwind stack to the state before previous routine
called it). This is a typical code-size-in-favour-of-speed dilemma. With MSVC
you get almost zero size overhead if you don't use exceptions, but the cost of a
catch()/throw() is umm... let's say so, greater than zero. With gcc scheme the
cost of exceptions is zero (unless exceptions are emmited) at the cost of code
size.
Post by Peter Donald
Post by Andrew Zabolotny
-*- STL increases a lot code size per se because STL itself is quite big (gcc
libstdc++ is about 400K). The STL classes are heavily using each
other, thus
Post by Andrew Zabolotny
if you use just the streams, you will end up with half of STL being
linked
Post by Andrew Zabolotny
into your program.
STL is virtually all templated code (STL == Standard Template Library) so
you only poay for what you use. In some cases (ie streams) the cost is
higher but it is generally not that big and the 400K for libstdc++ will
generally not happen. (Unless you want to use streams ....).
With some compiler/linker combinations templates have the habbit to duplicate
through the each object file where they are used. This does not happen with
Linux/ELF platform, but there are definitely a lot of platforms (including OS/2)
where the code of template will duplicate in each source file where they are
used (unless you use a very tricky scheme with #pragma interface, #pragma
implementation and so on which I would like to avoid).
Post by Peter Donald
Post by Andrew Zabolotny
In overall, if we use STL I estimate the overall execution speed will
decrease
Post by Andrew Zabolotny
by about 5-10% and the overall executable size will increase about twice.
Either
a> you dont know how to use STL
b> Never used STL
c> Your trying to spread information so that you get your own way
Neither. I've tried to use STL but abandoned it quickly because of the above
problems I didn't like.
Post by Peter Donald
STL does not increase execution time .... in most cases it will decrease
execution time (because in releas builds a vast proportion of code is
inlined -- which is partially the reason that executable size increases).
STL per se will not increase execution time, but exceptions will definitely do.
Also keep in mind the gold rule: larger code == less speed. Intel CPUs have a
quite big performance hit when the working set for code/data goes out of cache
bounds... typically it starts to crawl like a i386SX/16.

Greetings,
_\***@teamOS/2

Loading...