 |
 |
 |
 |
| | i need this topic more elaboratedly |
|
 |
| |
 |
| A text file isn't a good choice; if it is ftp'd between systems there's a risk of corruption due to CR/LF onversion which would completely trash the file.
Casting object instead of &object to a char* doesn't work because object is not a pointer but &object is. Remember: C++ Is Not Java!! Java has no pointers (actually, everything is a pointer), but C++ distinguishes between pointer and non-pointer variables.
The cast doesn't throw a compiler error because C++ assumes you know what you are doing and it is perfectly possible to cast an int with value 123 to a char pointer, but don't forget when you attempt to dereference that pointer (by calling out.write() for example) it will be now pointing at 0x0000007b which will almost certainly not work.
|
|
 |
| | Anonymous(1): what more do you want to know about object serialisation? This seems to cover it and the program should work regardless of what data is in class Test. |
|
 |
| This does NOT handle the problem of Endian - It will only work on systems with the same endian byte order.
In most cases, it is fine, but not all. |
|
 |
| |
 |
| | As mentioned by others, this is not going to handle well on all systems. Furthermore, you cannot use this methods with more complex types (if you had a string within your class, for example) because they often contain pointers. The best route for class serialization is writing your own serializers for each datatype and then writing a(n) (un)serialize method for your class specifically. |
|
 |
| | This is a pretty poor solution unless you are using the same compiler (and relevant compiler options) and processor at either end of the 'link' and are only serialising simple objects. As mentioned above, it is generally better to write your own serialize() methods. |
|
 |
| | It doesn't work when some members of the class are pointers. |
|
 |
| The way to go is to overload the global operators >> and << for your object with the first argument being a C++ stream and the second your object type and then serialize all relevant data members.
Your method is NOT guaranteed to work with different compilers, different versions of the same compiler, the same version of the compiler with different memory alignment settings, or different processor architectures. As others have mentioned, pointers (and references) are a huge problem.
There is also a HUGE security problem since depending on your compiler, you may also read the object's vtable from the stream, which is extremely dangerous since a manipulated file/network stream can be used to call arbitrary code on your system.
And if you add a data member to an object in a new version of your software, all your existing files/streams will become unreadable.
Your're also serializing any cached state information of the object, which may become invalid in the new context. For example, if you store something like the number of processors on the system in a member variable, this is what happens: When the object is read in on a different system, the object also reads in the number of processors and thus uses the no longer appropriate info that was in the file, and you get undefined behavior once the object accesses that variable.
Static data members may become an issue as well. |
|
 |
| |
 |
| | This is not going to handle well on all systems. Furthermore, you cannot use this methods with more complex types because they often contain pointers. The best route for class serialization is writing your own serializers for each datatype and then writing a(n) (un)serialize method for your class specifically. online games |
|
 |
| |
 |
| | This code is so wrong on so many levels. As an example, think of a class with virtual functions and try deserializing it using the above technique. The classes with virtual functions define an extra pointer at the beginning on the class definition which points to a virtual table translating the calls to a virtual function to its concrete implementation. The above serialization will keep the pointer to vtbl in a stream. Object graphs, i.e. complex relationships between objects, will not be serialized properly as well. So the only scenario that is going to work is when the class does not have virtual functions and has no pointers to other instances. If you really want to serialize class hierarchies, consider using Db4o API. |
|
 |
| | This will only store the address of the object in the file... as soon as your program terminates that address will stop pointing at the object and will only give you garbage if you try to initialize a new object from what is in there... the only reason it works is because while the program is still running the address points to the same object... you are not even creating a new object. If you were to change the 1st object the 2nd object would be modified as well because the memory that they are pointing at is the same. |
|
 |
| You may encode the stream into something that doesn't contain control chars. Hexadecimal, base64 (more compact) etc. encoding will do it, but bear in mind that you can't ignore structure padding, endianness, alignment and width/precision. I think too, that you must write a serialization specialization (meta class) for each type, since C/C++ is not Java.
If you don't handle those issues, you'll cause a mess when a remote end uses another compilation and/or platform.
So, be careful with your RTTI, you shouldn't declare long and int etc. because these types can vary in size on another platform. Therefore, be as specific as possible and embed types like uint32_t. I'd go as far as doing the same with float types, like float32, float64, float80 etc...
If you do all that, you can also handle member size and alignment problems. But even then, be aware of the whole struct alignment, it can be higher as several stuct members require, for example when aligned 128bit and wider loads occur (SSE etc.).
This means, you must create proper instances and copy the extracted/converted member fields in them regarding the local meta class; you MUSTN'T simply cast any pointer coming along in a buffer or sth.
You see, there is much to take care of, eventually more than i've prosed so far :-)
=> the preprocessor, sizeof, offsetof and alignof will be dear friends :-)
=> boost or C++0x tuple templates can be a real benefit because of iteration capabilities (what structs/classes lack of) |
|
 |
| |
 |
| | Thanks guy! I thought Serialization mechanism is a solely feature of some advanced programming framework. Nice! |
|
 |
| |
 |
 |
 |
 |
Anonymously add a comment: (or register