Re: [Adonthell-devel] New Windows test (PORTED TO VISUALC)

[Alexandre Courbot]

> 1. Use of "using namespace std;" - this totally screws up, so you better
>    use std::string, std::endl instead.

Yes, we were aware of this flaw. We were doing this because of SWIG -
but as you noticed using std::string and so on is much wiser, and works
perfectly with SWIG.

> 2. callback.h:
> 
>    enum {MEM_FUNC_SIZE = sizeof(PMemFunc)};
>    union{
>      PFunc func;
>      char memFunc[MEM_FUNC_SIZE];
>    };
>  
>    what exactly are you doing here? It chokes ALOT on the MEM_FUNC_SIZE
>    stuff.

Uh, yeah. That's weird. I'll ask Joel, as he did it :)

> 3. In some sourcefiles (not headerfiles), you keep the default values
>    in the parameters. You shouldnt do this, and only keep them in the header 
>    files.
>    
>    Example:
>    void image::zoom (const surface& src, u_int16 l, u_int16 h, u_int16 x = 0, 
> u_int16 y = 0)

Good idea, as the result would be the same - is it the C++ standard that
requires this?

>    In class joystick_event:
>     static const int max_nbr_joysticks = 5;
> 
>    You can't set static variables directly in header files.

Ah. I thought I could. :p GCC 2.95 didn't complain about this - but
that's not exactly the one you'd want to use to write portable code ;)

>    Secondly, in class control_event:
> 
>        static button_type Joystick_map[joystick_event::NBR_BUTTONS * 
>                                         joystick_event::max_nbr_joysticks];
>                                         
>    refering to the max_nbr_joystick here also chokes. You might consider
>    using a #define instead or something.

I'd prefer using consts there, but it wouldn't hurt. Maybe I could
define them another way. Also I should decide whether to use capitals or
not with const names :)

> 5. Probably some more issues I forgot.

Hehe :) Well, compiling with VC++ at least revealed a few tips to write
portable code!

Actually, we are supposed to cleanup this, as well as separating the
whole stuff into several namespaces (à la Clanlib).

> Now, to the result:
> 
> igzstream created
> Size of an u_int8: 1
> Size of a bool: 1
> Size of an u_int16: 2

Everything is fine so far.

> Size of the file: 2

Ark - should be 21958. The file has successfully been opened though - at
least I *think*. Could you try moving test.img away and running it
again? It should say the file can't be found.

> Now reading the file
> Position: -1

Should be 1. Something has been wrong right there.

> Mask value: 0 - Alpha value: 255

These ones are fine. Actually that's the only thing that's fine :)

> Image dimensions: 52428 x 52428

Should be 224 x 49. It totally screwed up.

> 4294967295 255 4294967295
> Stopped reading at position -1

The big numbers are -1 printed as unsigned ints. Of course it couldn't
go far in these conditions.

> gzeof reports 0
> error code set to -1

Clearly, an error occured.

> Values way off! Might be because I broke something during the compile fixes,
> esp. regarding the MEM_FUNC_SIZE (I just set it to 4 - would that be somewhat
> correct?).

I don't think you broke anything - all the changes you made were off the
scope of this test program, which only (slightly) use fileops.cc and
fileops.h. All the rest is done by accessing zlib API.

What surprises me is that VC++ seems to produce worst results than
mingw32 (which was able to read the 5138 first bytes of the file). But
this definitely prooves our problem isn't related to the compiler.

I must have screwed something up, but where? Let's wait until someone
(that is, probably Kai ;)) tests it with the native mingw32.

Btw, I'll fix the code according to your suggestions - that way you
should be able to compile it without problems.

> Btw, Im on irc if you want to talk.

I'd love to come, unfortunately I'm using a RTC here, and the phone
compagny sucks my money every minute I connect! :( And unfortunately,
no, I can't change, as there is a monopoly on local calls here :/

Alex.
-- 
http://www.gnurou.org