Re: [Dev-C++] Copy Constructors and Overloaded Assignment Operators

[Abhijit S. <mu...@gm...>]

> But, is it safe to say that everything should be okay if this methodolgy
> is used for
> in-memory state maintenance?

I guess so. But I'm still more comfortable having the class take over the
reins. This way you can take care of polymorphism and other such big words.

> >64-bit compiled program. A more portable way to persist is methods such
as
> >saveToDisk() and loadFromDisk(), which read and write each member. This
way
> >you can also change the read/write method to suit the platform... on
> >Windows, it can use the registry, on Linux the home dir, on DOS a config
> >file, etc. You could also interface to classes like FooWriter and
FooReader,
> >to which you can pass the struct/class as an argument.
> >
> >
> Use conditional compilation?  (#ifdef, etc.)

You could do that, or you could have different makefiles for different
platforms using the appropriate files.

> How worried are people about bit problems (i.e. endian-ness cross
> platform, like Intel to PowerPC).
>
> I'd never really stopped to think about it until it came up ... I forget
> where now, but it was an interesting point.

I don't think this is much of an issue unless you're doing some
bit-twiddling. In which case it would be safest to store the bit-stuff in a
class which can handle the endian-ness itself. I'm not aware of any #defines
for endian-ness of the current platform. I think you can do a run-time check
like this:

if((unsigned)0x01 >> 1)
    // LSB
else
    // MSB