RE: [Dev-C++] need advice on data storage

[<Mat...@Ve...>]

If you are using WX to do this, I am assuming you value portability.

One thing to remember about structures is that they are not portable between
processor types. Therefore, it would break the compatibility of your WX
application settings with some of the valid WX distributions.

Another thing. People like to be able to edit options files, so ASCII is
nice for the users. Users don't like having to hex-edit things and often
would not even know how.

Also, watch out for char* because it could overload if something happens to
make your options get arbitarily very long some time in the future.

Another thing, if you change what's in the struct, old options files might
quit working later.

A thought as to how you might work with an options storage class:
Just overload the operator<< function, and you can use that operator later
on in your storage class to output the options without having to worry about
putting the options functions in some weird file where you do not want them
to go.

Please respond on list if any of this raises more questions or gets you
thinking about some different possibilities, or if I misunderstood what you
are trying to do, and I will be happy to help you more.

HTH!
Matt

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of Big
Playah
Sent: Tuesday, March 29, 2005 5:09 PM
To: dev...@li...
Subject: [Dev-C++] need advice on data storage


Hi,

I'm hesitating which way to go of the two I've found out.
case is that I have to store some options data about the data which my
program tackles with. I also must include the ability to edit these
options, and to write/load them at save/load.
In an alpha version I've written in simple C, I've simply used a
struct to accomodate my functions, then some char *[] to store the
options, and #define s for them so I could easily handle the options
when needed. this is the first way to go, and has the greeeeaaaat
advantage of that I can simply dump/load this struct into my project
file (which I need to do), with simple binary file handling. it was
easy since I could have fixed len char* for strings, so I could
read/write at once with a sizeof() arg. furthermore, this way I could
make a copy of this struct, and use it for dialogs - easy go back with
cancels and invalid data.
other way I've found out is to make a class for the options, and
accomodate the option defs in its constructor. this way I can still
have multiple copies of it. however, I cannot simply dump the data
area of it (or can I?) so I'd have to write a saving function for it.
furthermore, I'm using a file I/O class so I can easily and separately
do data import/export, load/save. then I'd have to put my options
saving function in the I/O class, which would ruin the benefits of
having these options in a separate module (.h/.cpp pair)...
furthermore, this way I should use wxString s (I'm using wxwidgets) to
store my strings, which again would ruin my simpe I/O of options. I'm
afraid this brings more headache than any advantages, if any, but I
might not be seeing them...
going with wxOptions is just not fine for me, so had dropped that way
at the beginning...

what do you suggest, how should I solve this? (I'm quite new to C++
and OOP, previously had only experience with function programming...)
tia,
tom

-- 
Coupe Quattro '89
Typ81 custom '84


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.