Hello John, You guys are both going off in you own directions and arguing something that's really an unimportant implementation detail. Serialization's a wonderful thing, if you need it. It's nothing more than a protocol for storing, saving, transmitting something in a format that can be re-constituted on the the other side by a reader. It's useful, if you need it and solves problems some implementations have.
As for using base64 or hex encodings, why bother? SQLite is perfectly happy with binary insertions using the newer parameterized SQL compiling. I insert naked JPG files all day long with no encoding. Inserting binary though doesn't solve the basic problem with alignment and struct packing (which is only an issue in some cases), serialization does solve this problem but, it may be a non-issue depending on your implementation/CPU. When your only tool is a hammer, all of your problems look like nails. To me, a more fundamental question is why someone would want to save structs to a database instead of to a flat disk file. I use a database when I need to find something, not just to store things. For storage, I just use the much faster naked disk I/O. C Sunday, December 11, 2005, 1:14:03 PM, you wrote: JS> I was describing a free union used to transform big endian to little JS> endian and vice versa. There is no encoding involved. JS> My alternatives, BASE64 and ASCII HEX are encodings of the binary integers. JS> You let the buzzwords drown out the fundamentals. JS> pps wrote: >> John Stanton wrote: >> >>>> >>>> http://www.google.ca/search?q=boost+serialization >>> >>> >>> >>> I was describing no such thing. An example of what I was describing is >> >> >> what's serialization? >> http://www.google.ca/search?q=serialization >> >>> >>> union stored_word >>> struct >>> #ifdef BIG_END >> >> ... >> >>> } a; >>> #endif >>> int b; >>> } >>> >>> struct stored_doublet { >>> union stored_word x; >>> union stored_word y; >>> } >>> >> >> do you understand that you describe here serialization, and probably one >> of the simplest way of doing it, that is not guarantied to work... (as >> you say yourself). >> I really don't care about this case; making ints byte-endianess >> independent doesn't answer question "how do I stode xxx in blobs?" >> >>> >>> From an Sqlite perspective the data would be stored as a BLOB since >>> it is still binary format. It could also be stored as a 64 bit >>> integer. If it were to be stored as TEXT the transformation could be >>> more involved and more expensive by using BASE64 or ASCII hex format. >>> The added cost would be insignificant compared to the prospect of >>> doing a radix transformation into ASCII decimal and embedding that in >>> XML then havong to parse it out on every access. >> >> >> all this is irrelevant, you are talking about encoding. That's obvious, >> that xml encoded data is less efficient than ascii or binary encoding. >> I just posted xml encoded data as an example. >> the same struct ({1,2}) could be serialized by boost::serialization as >> text: "1 2" or as binary: (8 bytes: 0x00000001,0x00000002) >> most likely, what you are describing will get you the same results as >> binary serialization with boost::serialization. >> Other than that this library provides you with many things that you were >> not even thinkg about at the momnet of writing that code stored_word >> etc. (such as serializing data pointed by pointers & restoring pointers, >> for example, suppose stored_doublet had an extra member stored_doublet * >> next; how well your way handles this case, just think about it... the >> best you can do, is to write in big letters that you must be carefull >> using this code, etc, etc and then wait for people telling you about >> segfaults). What about the case when stored_doublet will be changed? All >> the data that was prevoiusly stored in blobs will not be valid anymore? >> this case is also handled by boost::serialization >> >>> >>> In practical terms it would be best to choose the byte format used by >>> Intel processors since that would most likely minimize re-ordering. >>> >> >> and, yes, you may save binary data in byte-endianess independent format >> or in processor native format also - you may have this choice with >> boost::serialization >> -- Best regards, Teg mailto:[EMAIL PROTECTED]
