Binary serialization

G

Guest

Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a stream/file
WITHOUT saving the object's state, eg. if I have a ref class with two int32's
as its data members, the binary file of that class must have a size of 8
bytes (i.e. only contains class data members, not methods etc.).

Is serialization the answer to the above problem? If I understand correctly,
the reason that pointer arithmetic and operations like sizeof(MyRefClass)
don't work is that the managed class is handled by the CLR, which, in turn,
requires objects to be serialized before porting.

In short, is there a serialization method which enables me to store ref
class data members ONLY in the same way as in native C++ (memcpy,etc.) does?

Thanks!
Jacques
 
K

Kevin Spencer

Bonjour Jacques,

It sounds like what you need is a class that implements the ISerializable
interface, and custom Serialization. The following articles and references
should help:

The System.Runtime.Serialization Namespace:
http://msdn2.microsoft.com/en-us/library/system.runtime.serialization.aspx

Custom Serialization:
http://msdn2.microsoft.com/en-us/library/ty01x675.aspx

ISerializable.GetObjectData:
http://msdn2.microsoft.com/en-us/li...erialization.iserializable.getobjectdata.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
 
F

Frans Bouma [C# MVP]

Jacques said:
Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a
stream/file WITHOUT saving the object's state, eg. if I have a ref
class with two int32's as its data members, the binary file of that
class must have a size of 8 bytes (i.e. only contains class data
members, not methods etc.).

Is serialization the answer to the above problem?

No.

Binary serialization is a mechanism which writes _that_ data to the
output stream which is necessary to re-create the object when reading
that precise data. I.o.w.: you get the contents + extra fluff. If you
want to save 8 bytes, you should grab the 8 bytes and write them
yourself. Though I fail to see the necessity for files of 8 bytes. This
thus leads to the assumption that you want to save the data of a lot of
objects into one file. If you do that yourself, you can end up with a
compact file, but also with a lot of code, or better: more code than
you would end up with when you would just go for the binary formatter
approach.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
G

Guest

Hi

You are correct in assuming that I don't want do save files of 8 bytes! I am
writing a realtime data capture app and need to minimise disk space.
Previously I would use a file write routine that worked similarly to memcpy,
ie "File.Write(&MyClass,sizeof(MyClass))".

My question is this: Is the only way in which I can extract ONLY the DATA
members from the class in question the method of writing each individual data
member to astream/file.. MYSELF? The problem I have with this is twofold:
1. every custom object needs its own custom streamwriter routine
2. point nr (1) is quite error prone for a clumsy programmer like myself!

Kind regards
Jacques

Frans Bouma [C# MVP]" wrote:> Jacques said:
Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a
stream/file WITHOUT saving the object's state, eg. if I have a ref
class with two int32's as its data members, the binary file of that
class must have a size of 8 bytes (i.e. only contains class data
members, not methods etc.).

Is serialization the answer to the above problem?

No.

Binary serialization is a mechanism which writes _that_ data to the
output stream which is necessary to re-create the object when reading
that precise data. I.o.w.: you get the contents + extra fluff. If you
want to save 8 bytes, you should grab the 8 bytes and write them
yourself. Though I fail to see the necessity for files of 8 bytes. This
thus leads to the assumption that you want to save the data of a lot of
objects into one file. If you do that yourself, you can end up with a
compact file, but also with a lot of code, or better: more code than
you would end up with when you would just go for the binary formatter
approach.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
 
F

Frans Bouma [C# MVP]

Jacques said:
Hi

You are correct in assuming that I don't want do save files of 8
bytes! I am writing a realtime data capture app and need to minimise
disk space. Previously I would use a file write routine that worked
similarly to memcpy, ie "File.Write(&MyClass,sizeof(MyClass))".

My question is this: Is the only way in which I can extract ONLY the
DATA members from the class in question the method of writing each
individual data member to astream/file.. MYSELF? The problem I have
with this is twofold: 1. every custom object needs its own custom
streamwriter routine 2. point nr (1) is quite error prone for a
clumsy programmer like myself!

You can somewhat solve it quite elegantly with the strategy pattern
through some base class/subclass construction: in the base class you
create the stream writer code, in the subclass you override a method of
the base class where you collect the data in to a byte array which is
then written to the stream by the base class. I dont see how that can
go wrong :)

FB
Kind regards
Jacques

Frans Bouma [C# MVP]" wrote:> Jacques said:
Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a
stream/file WITHOUT saving the object's state, eg. if I have a ref
class with two int32's as its data members, the binary file of
that class must have a size of 8 bytes (i.e. only contains class
data members, not methods etc.).

Is serialization the answer to the above problem?

No.

Binary serialization is a mechanism which writes that data to the
output stream which is necessary to re-create the object when
reading that precise data. I.o.w.: you get the contents + extra
fluff. If you want to save 8 bytes, you should grab the 8 bytes and
write them yourself. Though I fail to see the necessity for files
of 8 bytes. This thus leads to the assumption that you want to save
the data of a lot of objects into one file. If you do that
yourself, you can end up with a compact file, but also with a lot
of code, or better: more code than you would end up with when you
would just go for the binary formatter approach.


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
C

Cor Ligthert [MVP]

Jacques,

You need to save space on disk. You are aware that making programs complex
makes them need more space on disk.

In past I have seen this done many times by programmers with memory. They
wanted to use a minimum size for data areas in memory. The routines they
used where mostly spending more memory as the area would have been as they
had used the standard methods.

Just my thought on that reading your message.

Cor


Jacques said:
Hi

You are correct in assuming that I don't want do save files of 8 bytes! I
am
writing a realtime data capture app and need to minimise disk space.
Previously I would use a file write routine that worked similarly to
memcpy,
ie "File.Write(&MyClass,sizeof(MyClass))".

My question is this: Is the only way in which I can extract ONLY the DATA
members from the class in question the method of writing each individual
data
member to astream/file.. MYSELF? The problem I have with this is twofold:
1. every custom object needs its own custom streamwriter routine
2. point nr (1) is quite error prone for a clumsy programmer like myself!

Kind regards
Jacques

Frans Bouma [C# MVP]" wrote:> Jacques said:
Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a
stream/file WITHOUT saving the object's state, eg. if I have a ref
class with two int32's as its data members, the binary file of that
class must have a size of 8 bytes (i.e. only contains class data
members, not methods etc.).

Is serialization the answer to the above problem?

No.

Binary serialization is a mechanism which writes _that_ data to the
output stream which is necessary to re-create the object when reading
that precise data. I.o.w.: you get the contents + extra fluff. If you
want to save 8 bytes, you should grab the 8 bytes and write them
yourself. Though I fail to see the necessity for files of 8 bytes. This
thus leads to the assumption that you want to save the data of a lot of
objects into one file. If you do that yourself, you can end up with a
compact file, but also with a lot of code, or better: more code than
you would end up with when you would just go for the binary formatter
approach.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
 
G

Guest

Thanks for the prompt response.

From what I can deduce from your answer below, the answer to my question is
yes? I.e. every unique managed object I create needs its own streamwriter
(and thus streamreader) routine if the desired result is to store its DATA
MEMBERS ONLY! Sorry for my pessimism about the error prone-ness of the above,
but this new (for me) approach involves significantly more work for me!

Thanks for clearing things up though!
Jacques

Frans Bouma said:
Jacques said:
Hi

You are correct in assuming that I don't want do save files of 8
bytes! I am writing a realtime data capture app and need to minimise
disk space. Previously I would use a file write routine that worked
similarly to memcpy, ie "File.Write(&MyClass,sizeof(MyClass))".

My question is this: Is the only way in which I can extract ONLY the
DATA members from the class in question the method of writing each
individual data member to astream/file.. MYSELF? The problem I have
with this is twofold: 1. every custom object needs its own custom
streamwriter routine 2. point nr (1) is quite error prone for a
clumsy programmer like myself!

You can somewhat solve it quite elegantly with the strategy pattern
through some base class/subclass construction: in the base class you
create the stream writer code, in the subclass you override a method of
the base class where you collect the data in to a byte array which is
then written to the stream by the base class. I dont see how that can
go wrong :)

FB
Kind regards
Jacques

Frans Bouma [C# MVP]" wrote:> Jacques said:
Hi
I am an dotNet newby, so pardon my ignorance.

I am looking for a method of saving/copying a managed class to a
stream/file WITHOUT saving the object's state, eg. if I have a ref
class with two int32's as its data members, the binary file of
that class must have a size of 8 bytes (i.e. only contains class
data members, not methods etc.).

Is serialization the answer to the above problem?

No.

Binary serialization is a mechanism which writes that data to the
output stream which is necessary to re-create the object when
reading that precise data. I.o.w.: you get the contents + extra
fluff. If you want to save 8 bytes, you should grab the 8 bytes and
write them yourself. Though I fail to see the necessity for files
of 8 bytes. This thus leads to the assumption that you want to save
the data of a lot of objects into one file. If you do that
yourself, you can end up with a compact file, but also with a lot
of code, or better: more code than you would end up with when you
would just go for the binary formatter approach.


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
 
K

Kevin Spencer

I told you yesterday that you could do this with custom binary
serialization.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
 
F

Frans Bouma [C# MVP]

Jacques said:
Thanks for the prompt response.

From what I can deduce from your answer below, the answer to my
question is yes? I.e. every unique managed object I create needs its
own streamwriter (and thus streamreader) routine if the desired
result is to store its DATA MEMBERS ONLY! Sorry for my pessimism
about the error prone-ness of the above, but this new (for me)
approach involves significantly more work for me!

Yes then you need your own streamwriter/reader combo. It will be
significantly faster than the binary formatter, so I think it's worth
the try.

FB
Thanks for clearing things up though!
Jacques

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
G

Guest

Yes, thanx, I just find it difficult to understand why it necessary for me
implement a custom serialisation method for every object I create if the the
objects's DATA members are the only part of the object I want to store.

Nevertheless, thanx again, I was just looking for a simpler solution. :)

Jacques
 
K

Kevin Spencer

The problem here is that you're working with managed objects. So, you can't
just memcopy as you would with C++. One of the advantages of using Binary
Serialization in managed code is that the object can be de-serialized from
the same data you serialized it to. There are others as well. It's really
not hard to do.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
 
F

Frans Bouma [C# MVP]

Kevin said:
The problem here is that you're working with managed objects. So, you
can't just memcopy as you would with C++. One of the advantages of
using Binary Serialization in managed code is that the object can be
de-serialized from the same data you serialized it to. There are
others as well. It's really not hard to do.

It was my understanding he wanted to have ONLY the 8 bytes of data
contained in the object into the file, not a bit more or less. You then
can't use binary serialization as that adds more bytes to the file, per
object.

Another thing that makes binary serialization in this case useless is
that the more objects you have to deserialize, the slower it gets. If
you have hundreds of thousands of objects with 8 bytes, deserializing
them will bring the app to its knees for minutes, while reading the
file from front to back and creating a new object for every 8 bytes you
read is much faster.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
C

Cor Ligthert [MVP]

Hi guys,

I don't understand why making all that trouble if you just want some items
from an object in a file from 8 bytes. (Although I doubt that any file
system will not expand that on disk to the minimum default).

In my idea are there than more classic very simple methods we did already
use with the punchcard.

:)

Cor
 
K

Kevin Spencer

Hi Frans,

Perhaps I misunderstood. He was talking about serializing a class, but from
what I gather it sounds like he just wants to serialize the data. If you
only serialize the data, you can't deserialize it back to a class. But there
are certainly times when it's useful to do what you're describing. So, since
you seem to have a better picture of what he wants to do, I'll just leave it
to you. :)

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
 
F

Frans Bouma [C# MVP]

Kevin said:
Hi Frans,

Perhaps I misunderstood. He was talking about serializing a class,
but from what I gather it sounds like he just wants to serialize the
data. If you only serialize the data, you can't deserialize it back
to a class. But there are certainly times when it's useful to do what
you're describing. So, since you seem to have a better picture of
what he wants to do, I'll just leave it to you. :)

heh :) I think his main confusion comes from the fact that in MFC you
also could implement serialization but that was solely about the data
and resulted in implementing datareader/writers so no class info ended
up in the output stream if you didn't want to. (if my rusty MFC memory
still functions correctly ;))

in .NET you either have to do manual writing/reading the data (which
is actually pretty straight forward in this case IMHO) or accept class
info in the output.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
G

Guest

Thanx very much for all the replies - these clarify things for me
signficantly, i.e. I will implement binary serialization method for every
object I create to store only the data members of that object, without any
class info.

Kind regards
Jacques van Wyk
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top