Allegro game programming library

On Thu, 2002-10-10 at 00:13, Robert Ohannessian wrote:
> Grzegorz Adam Hankiewicz wrote:
> 
> >The non-css version looks ok, but since the new css version depends on
> >css being available, it doesn't degrade gracefully, a rule I set myself
> >for accesible websites. For this reason I will probably generate the
> >allegro web page with @ignore_css.
> >
> 
> ... This defeats the purpose of my patch. Can't we just put the .txt 
> online for people with 12 year old browsers?
> Otherwise, I can always add <em> tags and define the CS script for them 
> to not do anything.

Why can't you put <li> tags before the <div> tags? It displays right
(you can even hide the bullets with css) both with and without css that
way.

--
Elias Pschernig

Elias Pschernig wrote:

>Why can't you put <li> tags before the <div> tags? It displays right
>(you can even hide the bullets with css) both with and without css that
>way.
>

You can hide the bullets with CSS? I'll have a look. This probably the 
best solution.

Eric Botcazou wrote:

>> No, put the .css file as a constant string inside makehtml.c and output
>> it as necessary into the html (embedded file) or as an independant file
>> (link reference) depending on the ._tx source.
>
>Does this issue prevent a new WIP release from being made ?
>

Not really (unless you are planning to make one before this week-end :)

> Not really (unless you are planning to make one before this week-end :)

I was actually planning to make the 4.1.4 WIP this week-end, but there is no
hurry.

--
Eric Botcazou

onsdagen den 9 oktober 2002 23.35 you wrote:
> Advantages:
>  - dat2c will work nicely :-)
Can be done in other ways as well. Won't it be necessary to call an 
init-function if you introduce this?
>  - more generally, it is possible to statically-initialise structures
>    with zero-sized arrays (you might want to do this for sub bitmaps
>    etc. to make sure that their creation never fails, thus simplifying
>    your code)
Is this used by Allegro internally somewhere? 
>  - makes the code a little simpler in certain places (ie. the ZERO_SIZE
>    macro in header files, etc)
Minor
>  - AIUI zero-sized arrays are not ANSI C [1] (as always, please correct
>    me if I'm wrong)
This is an important item. Think of people who wants to port Allegro or parts 
of it to completly other platforms (maybe some hand-held object). Following 
ANSI is good.

> Disadvantages:
>  - requires somebody to do the work (I volunteer) and some work checking
>    and applying
Seems to be fixed:-)
>  - increases instance size by sizeof(void*) + alignment
... and the alignment cost will often be 0 (on all platforms where 
alignment==sizeof(void*))
>  - functions creating such structures require an extra line of code
Minor

To me it seems there are more advantages than disadvantages. To carry out the 
ANSI- item only, changing 'char data[0]' to 'char data[1]' would be 
sufficient.
/C

> As the title says, I propose that we remove zero-sized arrays from the
> library.

Allegro doesn't strictly use zero-sized arrays: it uses arrays with
un-determined length in terminal position inside non-empty structures. All
the compilers targeted by Allegro (Watcom, Borland, MSVC) have supported
this extension for a long time, except the GNU C compiler. For the latter,
we rely on a custom extension, zero-sized arrays.

>  - more generally, it is possible to statically-initialise structures
>    with zero-sized arrays (you might want to do this for sub bitmaps
>    etc. to make sure that their creation never fails, thus simplifying
>    your code)

Don't you want to remove zero-sized arrays ?

>  - makes the code a little simpler in certain places (ie. the ZERO_SIZE
>    macro in header files, etc)

Huh... this extension makes things simpler: you don't have to bother with an
offset all over the place. And what's the problem with the ZERO_SIZE_ARRAY
macro ? Only the one who implements it has to know how it works internally.

>  - AIUI zero-sized arrays are not ANSI C [1] (as always, please correct
>    me if I'm wrong)

Right, but "arrays with un-determined length in terminal position inside
non-empty structures" are ISO C99: they are called flexible array members.
That's all what we need.

--
Eric Botcazou

Laurence Withers wrote:
> As the title says, I propose that we remove zero-sized arrays from the 
> library.

I support you fully, given that it is practical to implement: see later...

> Advantages:
[snip]

Also much more flexible: any add-on (or other user code) that needs it 
can plug his own char** array into the BITMAP structure without having 
to malloc and initialize a new copy of the line[][] array.

I see no technical advantage of the zero-size arrays.

> Disadvantages:
[snip]
>  - increases instance size by sizeof(void*) + alignment
>  - functions creating such structures require an extra line of code

These are nothing to worry about, IMHO.

> What stays the same:

Probably tons of asm code needs to be rewritten. With zero-sized arrays 
it is:

    line_ptr = bmp_ptr + static_offset

Without zero-sized arrays it will be

    line_ptr = *(bmp_ptr + static_offset)

Sven

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 October 2002 10:13, Sven Sandberg wrote:
[snip]
> Probably tons of asm code needs to be rewritten. With zero-sized
> arrays it is:
>
>     line_ptr = bmp_ptr + static_offset
>
> Without zero-sized arrays it will be
>
>     line_ptr = *(bmp_ptr + static_offset)

Yes, you are right. I'm not sure about 'tons', though :-)

On Thursday 10 October 2002 08:55, Eric Botcazou wrote:
> >  - more generally, it is possible to statically-initialise
> > structures with zero-sized arrays (you might want to do this for
> > sub bitmaps etc. to make sure that their creation never fails, thus
> > simplifying your code)
>
> Don't you want to remove zero-sized arrays ?

A wording mistake. "More generally, it is possible to 
statically-initialise structures that currently use zero-sized arrays 
[if we make the change]". This is because it is not always possible to 
statically initialise a zero-sized array (as we discovered with dat2c). 
NB: by zero-sized arrays, I mean whatever you want to call unsized 
arrays in terminal positions.

On Thursday 10 October 2002 08:42, Christer Sandberg wrote:
> >  - dat2c will work nicely :-)
>
> Can be done in other ways as well. Won't it be necessary to call an
> init-function if you introduce this?

Nope, because you can write the line[] array or whatever as a static 
array, and then use the array name as a pointer to the first element 
(which, as discussed earlier, is a compile-time constant).

Bye for now,
- -- 
Laurence Withers,  lwithers@...
(GnuPG 04A646EA) http://www.lwithers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9pVQdUdhclgSmRuoRAvA+AJ9kUcW95PpRIa9XM2alC+QKGw2jeQCeJn+P
zAnrdCfIQrJla2owSSj6nGI=
=TG3d
-----END PGP SIGNATURE-----

> A wording mistake. "More generally, it is possible to
> statically-initialise structures that currently use zero-sized arrays
> [if we make the change]". This is because it is not always possible to
> statically initialise a zero-sized array (as we discovered with dat2c).

Ah! ok.

> NB: by zero-sized arrays, I mean whatever you want to call unsized
> arrays in terminal positions.

Let's call them ISO C99 flexible array members then.

So your proposal is to remove ISO C99 flexible array members from the
library, whose use is directly supported by all the compilers (except GCC
2.x for which there is the zero-sized array extension) but whose static
initialization is undefined by the Standard.

Here is IMHO a more correct list of advantages/disadvantages:

Advantages:
 - dat2c will work nicely :-)
 - more generally, it is possible to statically-initialise structures

Disadvantages:
 - makes the code a little more complicated
 - introduces an unnecessary indirection
 - breaks data locality

--
Eric Botcazou

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 October 2002 12:51, Eric Botcazou wrote:
> Let's call them ISO C99 flexible array members then.

If that's the case, then does ISO C99 provide for static initialisation 
of such structures? If it does, then fine - dat2c code output will be 
C99 only (not a big deal since our main compiler on DOS, Windows and of 
course Unix is gcc). If it does not, then we have to ask does the 
ability to statically intialise such structures outweigh the required 
code changes.

Are there any good references for the C99 standard? Can I browse it 
online anywhere, or is it payment-only?

Bye for now,
- -- 
Laurence Withers,  lwithers@...
(GnuPG 04A646EA) http://www.lwithers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9pd0FUdhclgSmRuoRAnthAJ90RDhczvD5/XGihmiZgdungQjDIgCfYyrR
KqIOql01YKNxD5royUZsyO4=
=MaPw
-----END PGP SIGNATURE-----

dat2c now generates working code. I still hav to check dat2s.
I'll post the patch tomorrow, probably.

> No, I mean mimic-ing the layout of the BITMAP structure (see my
> previous
> message). The data would be malloc-ed.

That is what I meant.
Do you have an argument other than you don't like it ? ;)
However, I do now prefer your solution, as it would get rid of
warnings in the generated C code (due to excess iniitalizers).
I'll probably post that bit in a week's time.

-- 
Vincent Penquerc'h