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

Big Playah wrote:
> Hi,
>=20
> Reid & Matt, thx for your fast answers!
> I don't want to go into databases, I really don't need any
> features it would offer me, but on the other hand, I'd be a
> bit limited since later I might be using/saving arbitary data
> based on my options and memory state (ie. different registers
> for different MPUs, and I know how this could be solved with
> DBs, but want plain structure rather than related things).
I still suggest that you take a look at sqlite, it's very easy to
implement and you can use sqlite very easily in place of an ascii or
binary file ( many applications do,, most of which do so without the end
user even being aware of it).
> Reid, overloading the << operator will work I think. I think
> I'll stuck with a struct anyway, and use it inside a class.
> possibly I'll have duplicate entries and use them for
> runtime, but convert to/from simple data formats at I/O time.
> I don't need, and in fact don't want to enable users to edit
> these options, since changing some of them might need
since it's pretty easy to hide that you're using sqlite, the users would
would not be prone to altering your stored data.  if you're still
concerned about it, encrypt the stored data.
> converting of all other data, even restructuring of it (and
> this is what this editor is designed to do, anyway :). these
> are not the editor options which I'm using wxConfig for.
> you're right I'm keeping an eye on portability, but at first,
> I want to stay on x86 platform (but later a linux port would
sqlite is available for for just about every platform you'd want ( x86
has no bearing on sqlite -- linux and windows and many other OS's run on
x86 ).  sqlite runs on windows, unix, linux, + other OS's
> be fine, bot no other systems do I plan for), and, I might be
> loosing portability anyway when dumping my memory area (which
> I really want to handle as-is). just to make things clear,
> I'm writing an enchanced hex editor, with abilities suitable
> for various MPUs. sorry if I bored the list. :))
>=20
> tom



reid

Big Playah wrote:
> Hi,
>=20
> Reid, what would be the benefit of using an SQL database for
> quite simple data storage? I don't need any features an SQL
> engine could give me, at least not one I know of - related
> data storage, easy searching, good hierarchy. but, I'd add
> quite an overhead, drop in quite some kB of exec data, and
> mix in another language. SQL is no problem for me, I've been
> using SQL DBs succesfully for web pages earlier, and it was
> really fine for storing related data and performing searches
> and sub-selects. this is not the job right now. I'm dumping a
> variable sized memory image and some info about it, that's my
> project file, and I have really just a few variables that
> will be saved as variables - under 20 at first count. user
> works on just 1 project at a time, that's no prob again. I
> don't want to encrypt these save files, but do not want to
> encourage users of hand-editing them. so again, this is not
> an issue. still, I prefer plain one-file saving. one thing,
> I've mentioned I have some selects. namely, I have currently
> 2 of them, each having ~ 6 options, so this does not require
> an SQL engine... so, I'm not wanting to disargue in that SQL
> is good for some jobs, just asking if it would bring me any
> _useful_ benefits which I don't see ?
>=20
> tom

go back to what you originally wrote that you liked/disliked about your
current implementations; throw in this comment "..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.." sqlite was
just a suggestion, it's already implemented, is easy to add as a
component of another application, is fast, saves you from
designing/implementing/debugging a 'from scratch' solution, etc

again, just a suggestion in response to 'what do you suggest, how should
I solve this?'

reid

Hi,

Reid, what would be the benefit of using an SQL database for quite
simple data storage? I don't need any features an SQL engine could
give me, at least not one I know of - related data storage, easy
searching, good hierarchy. but, I'd add quite an overhead, drop in
quite some kB of exec data, and mix in another language. SQL is no
problem for me, I've been using SQL DBs succesfully for web pages
earlier, and it was really fine for storing related data and
performing searches and sub-selects. this is not the job right now.
I'm dumping a variable sized memory image and some info about it,
that's my project file, and I have really just a few variables that
will be saved as variables - under 20 at first count. user works on
just 1 project at a time, that's no prob again.
I don't want to encrypt these save files, but do not want to encourage
users of hand-editing them. so again, this is not an issue. still, I
prefer plain one-file saving.
one thing, I've mentioned I have some selects. namely, I have
currently 2 of them, each having ~ 6 options, so this does not require
an SQL engine...
so, I'm not wanting to disargue in that SQL is good for some jobs,
just asking if it would bring me any _useful_ benefits which I don't
see ?

tom

-- 
Coupe Quattro '89
Typ81 custom '84

Hi. If you want to store some binary information you can store it in
hex or base64 or uue. Then you'll be able to work with it as with usual
ascii strings, store it in files, etc.
Simple example:

class A
{
   char* binary_stuff;
   int len;
   ...
public:
   friend ostream& operator<<(ostream& os, A& a);
   friend istream& operator>>(istream& is, A& a);
   ...
};

ostream& operator<<(ostream& os, A& a)
{
   for(int i=0;i<len;++i)
   {
       char* c[3]; _itoa(a.binary_stuff[i],c,16);
       os<<"0x"<<c<<" ";
   }
   os<<'\n';
   return os;
}
istream& operator>>(istream& is, A& a)
{
   string temp; is=getline(temp); int i=0;
   while(pos=temp.find(" ")!=-1){
     a.binary_stuff[i++]=(temp.substr(0,pos)[3]-31)*16+
                         (temp.substr(0,pos)[4]-31);
     temp=temp.substr(pos+2);
   return is;
}

int main()
{
    ifstream f1("if.txt");
    ofstream f2("of.txt");
    A a; f1>>a;
    ...
    f2<<a;
    return 0;
}
-- 
Best regards,
 Denis                          

If anyone wants to store binary information, there is no need to encode it
in hex or similar. Disk drives are 8-bit clean :)

/Per W

On Fri, 1 Apr 2005, Denis Korzunov wrote:

> Hi. If you want to store some binary information you can store it in
> hex or base64 or uue. Then you'll be able to work with it as with usual
> ascii strings, store it in files, etc.
> Simple example:
>
> class A
> {
>    char* binary_stuff;
>    int len;
>    ...
> public:
>    friend ostream& operator<<(ostream& os, A& a);
>    friend istream& operator>>(istream& is, A& a);
>    ...
> };
>
> ostream& operator<<(ostream& os, A& a)
> {
>    for(int i=0;i<len;++i)
>    {
>        char* c[3]; _itoa(a.binary_stuff[i],c,16);
>        os<<"0x"<<c<<" ";
>    }
>    os<<'\n';
>    return os;
> }
> istream& operator>>(istream& is, A& a)
> {
>    string temp; is=getline(temp); int i=0;
>    while(pos=temp.find(" ")!=-1){
>      a.binary_stuff[i++]=(temp.substr(0,pos)[3]-31)*16+
>                          (temp.substr(0,pos)[4]-31);
>      temp=temp.substr(pos+2);
>    return is;
> }
>
> int main()
> {
>     ifstream f1("if.txt");
>     ofstream f2("of.txt");
>     A a; f1>>a;
>     ...
>     f2<<a;
>     return 0;
> }
> --
> Best regards,
>  Denis