Sv: First Win32 Compile!

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>>Wehee! PenguinPlay can now compile on a Win32 compiler!
>>
>Cool.
>
Funny, when I began looking at porting it, I really thougth it would be much
harder to get the functionality right than to get it to compile. Seems I was
wrong (so far, atleast).

>>I'm still getting one warning: "possible loss of data". This is because we
>>are storing the time data in pak files in 64-bit fields, but we are only
>>using a 32-bit memory structure to hold it (ppTimeT). I think this is a
>>little counter-productive: we should either store time data in 32-bit
fields
>>in the pak files, or use a 64-bit memory structure to hold it.
>
>Time values are stored in 64Bit in the Pak because that will be the
>"normal" size for them in the near future (and AFAIK it already is on most
>64Bit machines).
>
Its my understanding that 64-bit maschines are rather rare.

> When reading those I check whether the value read fits
>into the local architecture's native time format, represented by ppTimeT.
>If not, that means we cannot process this time data -> error. If yes, fine.
>
>That is I do explicitly check for data loss.
>
>It should be possible to do the check in a way that doesn't offend
>compilers though.
>

It is possible: (using a bit of meta-code and homemade functions and
symbols)

#ifdef _PP_USING_32BIT_TIME_T
ppTimeT time = Read32BitVal()
ppTimeT highTime = Read32BitVal()

if (highTime != 0)
    we have a problem
#else
ppTimeT time = Read64BitVal()
#endif

However, if a compiler supports 64-bit integers, why is ppTimeT only 32
bits?

>BTW: the same situation exists for size and offset values.
>
I am only getting 1 warning of this nature, though...

>>Also, I've had to change the Name() method of a number of classes to get
the
>>const/unconst puzzle right. I have feeling that the Name() method really
>>should be returning const char*'s rather than char*'s, and that it is the
>>code that uses the return value as an unconst value that should be altered
>>rather than the return type of Name().
>>
>I guess you're right.
>
I think the problem is that you don't always follow the principle that
classes should maintain themselves. A piece of coding utilising a specific
class should not say "gimme' your data-members and I'll take it from there",
no, it should rather say: "I need you to take on this specific state in
order for me to fullfill my task". Any code that does not do things like
this is a hack. Hacks are sometimes needed in order to get things working in
an effecient manner, however, they should be avoided whenever possible.

If you want to change the frequency of your radio, you don't rip it open and
do it "manually", no, you, as well behaved user of the radio, turn the dial
or (if its a little more advanced) press the button that corresponds with
the channel you desire to listen to. Once you've learned how a radio with a
dial works, you don't need to learn that again when you see another radio
with a dial, as it has a compatible interface. If you insist on ripping open
all radios whose current frequency you need to alter, you will not only make
life alot harder for yourself, you will also have to learn the intricate
details of each and every radio you come across.

If I have a string object and want to change its allocated memory size to
something, say, twice as big, I shouldn't say "gimme' a pointer or reference
to your pointer to your storage and I'll take it from there", I should
rather say "I'd like you to change the size of your storage to twice its
current size". Note I should not expect the string class to have a method
DoubleStorageSize(), but I should be able to rely on it having GetCapacity()
and SetCapacity() methods that would allow me to first query the object in
question for its size, multiply that by 2 and tell it to resize its storage
to something the size of the value I've calculated. The point is that at no
time do I expect *anything* about the way the string class is implemented,
except that it fullfills the abstraction of being a string class with the
capabilities outlined in its interface (read: class) declaration, which is
all I really need to know.

Atleast, that's the design philosophy I utilize when designing C++ objects:
All code should be informed only on a need to know basis, and all code
should assume as little as possible about the environment in which it is
being used while still being as effecient as possible.

You probably already know this, actually, I'm positive you do. I just need
to know that my conseption of how a C++ class should be designed is somewhat
compatible with your conseption of how a C++ class should be designed.