STL.NET serialization

[Herby]

This is a follow on from my previous thread about clr/safe and STL.NET

http://groups.google.com/group/micro...70a89dbc67c332

A more specific problem now is migrating the current MFC serialization
onto STL serialization?

How best to serilize using STL?

STL does not seem to directly support the concept of serialization in
the basic STL library?

Given i have managed to serialise using STL, is this then going to be
compatible with STL.NET?

More precisly if i have managed to 'save' a set of vectors, maps etc of
int, long string etc
using STL.

Is this stream going to 'load' into STL.NET equivalent classes?

Also is streaming and the concept of serialization going to be
verifiable?

Any good links relative to this subject would be greatly appreciated?
Thanks in advance.

[Carl Daniel [VC++ MVP]]

Herby wrote:

This is a follow on from my previous thread about clr/safe and STL.NET

http://groups.google.com/group/micro...70a89dbc67c332

A more specific problem now is migrating the current MFC serialization
onto STL serialization?

How best to serilize using STL?
The C++ standard library does not include any support for serialization at
all. You might be able to use boost::serialization from www.boost.org.
STL does not seem to directly support the concept of serialization in
the basic STL library?
Correct.
Given i have managed to serialise using STL, is this then going to be
compatible with STL.NET?
Unlikely, but it depends on how you did it.
More precisly if i have managed to 'save' a set of vectors, maps etc
of
int, long string etc
using STL.

Is this stream going to 'load' into STL.NET equivalent classes?
Only you can say.
Also is streaming and the concept of serialization going to be
verifiable?
Only you can say, since you implemented the serialization.
Any good links relative to this subject would be greatly appreciated?

I haven't seen any. Post 'em if you get 'em.

-cd

[Herby]

Cheers Carl.

More specific question.

If i use the IOStream classes present in the standard C++ library are
these going to be available in STL.NET?

If i use Boost to do my serialisation, which would be the natural
choice( dont want to re-invent the wheel ) is this going to be
compatible with STL.NET ?

[Carl Daniel [VC++ MVP]]

Herby wrote:

Cheers Carl.

More specific question.

If i use the IOStream classes present in the standard C++ library are
these going to be available in STL.NET?
I don't know.

If i use Boost to do my serialisation, which would be the natural
choice( dont want to re-invent the wheel ) is this going to be
compatible with STL.NET ?

Very unlikely.

-cd

[Herby]

I want to stay in the realms of C++\CLI and STL.NET as possible.
How can i do file input/output or more specifically serialization
within this boundary?

Am i now forced to use the .NET framework classes to achieve this?

Thanks.

[Tom Widmer [VC++ MVP]]

Herby wrote:

I want to stay in the realms of C++\CLI and STL.NET as possible.
How can i do file input/output or more specifically serialization
within this boundary?

Am i now forced to use the .NET framework classes to achieve this?

I think with the .NET framework you can automatically serialize
containers, STL.NET or otherwise (I assume the mechanism uses
reflection, like Java serialization). If your code doesn't need to be
portable to ordinary C++, this would appear to be your best option,
assuming testing shows it to be fast enough for your needs.

Tom

[Herby]

Tom.

I need to serialize from a current un-managed application
I then want to de-serialize this into a new managed application.

This serialized file is then the bridge between the old un-managed
application and the new managed application.

We want the new managed application to be backward portable to C++\STL(
as much as possible) consequently this is why we are writing the new
application in C++\CLI and STL\CLR.

The new application must be 100% verifiable.

We will only use .NET specifics ( framework classes ) where these is no
viable compatible C++\STL solution.
Performance is also critical in terms of loading these files and the
space they take up on disk.

So it seems to me now i will write a custom serialize mechanism in the
source un-managed application.
So i cannot use the inbuilt .NET serialization mechanism because it
will not understand my serialized file format.

And then write a custom de-serialize mechanism in the new application.

The IOStream classes are not going to be ported to STL\CLR.

So here it would seem i am forced to use .NET to de-serialize my
file????
What class should i use?

Thanks.

[Tom Widmer [VC++ MVP]]

Herby wrote:

Tom.

I need to serialize from a current un-managed application
I assume this code hasn't been written yet?
I then want to de-serialize this into a new managed application.

This serialized file is then the bridge between the old un-managed
application and the new managed application.
You might be able to bridge them by creating a mixed-mode application,
but it's not clear without knowing the details of what and why you are
switching from Win32 to CLR.
We want the new managed application to be backward portable to C++\STL(
as much as possible) consequently this is why we are writing the new
application in C++\CLI and STL\CLR.

The new application must be 100% verifiable.

We will only use .NET specifics ( framework classes ) where these is no
viable compatible C++\STL solution.
Performance is also critical in terms of loading these files and the
space they take up on disk.

So it seems to me now i will write a custom serialize mechanism in the
source un-managed application.
So i cannot use the inbuilt .NET serialization mechanism because it
will not understand my serialized file format.
Any reason for this? Can't you make the un-managed application mixed
mode, with the serialization code using .NET? Also, note that
System.Runtime.Serialization seems quite configurable, so you might be
able to get it to read in your format, if you define the format with
this in mind.
And then write a custom de-serialize mechanism in the new application.

The IOStream classes are not going to be ported to STL\CLR.

So here it would seem i am forced to use .NET to de-serialize my
file????
What class should i use?

BinaryReader, if your binary format uses little endian byte order and
you don't end up using .NET serialization.

Tom

[Herby]

Thanks Tom.

Its possible the source un-managed application could use mixed mode.
Ultimately the source application will move to .NET too, initially via
mixed mode.
I would only want the serialization code to be managed and not attempt
to compile everything else to managed via "IJW"?

[Tom Widmer [VC++ MVP]]

Herby wrote:

Thanks Tom.

Its possible the source un-managed application could use mixed mode.
Ultimately the source application will move to .NET too, initially via
mixed mode.
I would only want the serialization code to be managed and not attempt
to compile everything else to managed via "IJW"?

Over to Carl or someone else, since I've never written anything in
C++/CLI or managed C++ I'm afraid.

Tom

[JAL]

Herby... Having written in C++/cli for one week, I can confidently say :)

You could write a bridge class that implements a custom interface say IData.
Provide a method that converts your unmanaged data to managed data and wraps
them in a concrete class MyData of type IData, marked [Serializable]. Write a
IVersion and IData interface and compile this into a pure MSIL
MyInterface.dll. In your mixed C++/cli application reference the dll as using
"MyInterface.dll". In your mixed mode class provide a method ToManagedData
that takes an unmanaged data object and returns an instance of your managed
MyData class. Create a concrete class MyVersion of type IVersion. Use
binaryformatter to serialize MyVersion and then MyData to a file. Then in a
C# class open the file, deserialize the MyVersion object, check for the
correct version and then deserialize the MyData object.

Of course, it would be a lot easier if STL.NET emits classes that are marked
[Serializable], but then since I cannot download it yet, I cannot say.

"Herby" wrote:

Tom.

I need to serialize from a current un-managed application
I then want to de-serialize this into a new managed application.

This serialized file is then the bridge between the old un-managed
application and the new managed application.

We want the new managed application to be backward portable to C++\STL(
as much as possible) consequently this is why we are writing the new
application in C++\CLI and STL\CLR.

The new application must be 100% verifiable.

We will only use .NET specifics ( framework classes ) where these is no
viable compatible C++\STL solution.
Performance is also critical in terms of loading these files and the
space they take up on disk.

So it seems to me now i will write a custom serialize mechanism in the
source un-managed application.
So i cannot use the inbuilt .NET serialization mechanism because it
will not understand my serialized file format.

And then write a custom de-serialize mechanism in the new application.

The IOStream classes are not going to be ported to STL\CLR.

So here it would seem i am forced to use .NET to de-serialize my
file????
What class should i use?

Thanks.

[Herby]

Ok, im changing my thinking from pesimistic to optimistic and this has
illuminated a solution.

My new runtime application will mostly use C++\CLI and STL\CLR and use
..NET specifics for things like serialization etc.
I will assume under .NET peformance will not suffer too much and it
will be accepted, thus removing the need to compile this to un-managed
for some clients( pessimistic view ). If the pessimistic view turns out
to be right then some parts of the system will have to have an
un-managed replacement, such as writing my own DIY serialisation using
SCL streams and .NET BinaryReader classes.

My design-time applicaton will then use mixed mode compilation and
import the new managed DLL and call serialize on it.

Heres some pseudo code....
RuntimeMap* pMap = CreateRuntime(); // MFC objects hierarchy

// pMap->Serialize( ar ) // MFC serialization now replaced

// Having imported the new runtime .NET DLL....
RuntimeMap2^ pMap2 = gcnew RuntimeMap2();

pMap->Convert2DotNet( pMap2 ); // basically converts from MFC to
STL\CLR etc, setting properties on target objects

// created .NET binary formatter etc ....
formatter->Serialize( pMap2 );
Thanks for all your help so far guys, do you think the above makes
sense? please feel free to critique...

[Tom Widmer [VC++ MVP]]

Herby wrote:

Ok, im changing my thinking from pesimistic to optimistic and this has
illuminated a solution.

My new runtime application will mostly use C++\CLI and STL\CLR and use
.NET specifics for things like serialization etc.
I will assume under .NET peformance will not suffer too much and it
will be accepted, thus removing the need to compile this to un-managed
for some clients( pessimistic view ). If the pessimistic view turns out
to be right then some parts of the system will have to have an
un-managed replacement, such as writing my own DIY serialisation using
SCL streams and .NET BinaryReader classes.

My design-time applicaton will then use mixed mode compilation and
import the new managed DLL and call serialize on it.

Heres some pseudo code....
RuntimeMap* pMap = CreateRuntime(); // MFC objects hierarchy

// pMap->Serialize( ar ) // MFC serialization now replaced

// Having imported the new runtime .NET DLL....
RuntimeMap2^ pMap2 = gcnew RuntimeMap2();

pMap->Convert2DotNet( pMap2 ); // basically converts from MFC to
STL\CLR etc, setting properties on target objects

// created .NET binary formatter etc ....
formatter->Serialize( pMap2 );
Thanks for all your help so far guys, do you think the above makes
sense? please feel free to critique...

It looks like the approach that will be the least work, so go for it.
The only hitch is the slight performance degradation from the
"unnecessary" call to Convert2DotNet, but that can't be that bad.
Anyway, almost certainly better than writing your own code, but make
sure that nothing is CLR version dependent (I don't know much about .NET
serialization, but Java's variant sometimes broke compatibility on some
classes between versions IIRC).

Tom

[Herby]

Cheers Tom, that makes me feel better.

The intermediate step Convert2DotNet is a necessary evil it would seem.
But kind of clean.

From a users perspective it should not be noticable.

Thanks.

[Herby]

Visibility problem:

I have something defined like the following

[Serializable]
public ref class FunctionArray : public vector<FunctionBase^>
Because of the need for the Convert2DotNet function, most of my classes
are going to need to be accessible from outside the assembly so that
their properties can be set.

Because of inheriting from vector which is not marked public, i get the
following error....

c:\dev.2005.net\runtime\runtime\FunctionArray.h(12 ) : error C3213: base
class 'cliext::vector<_Value_t>' is less accessible than
'FunctionArray'

Am i forced now to make vector a member of FunctionArray?
I cannot subclass from STL given that class is to be made public
outside its assembly?

[Herby]

Having moved the vector to become a private data member of
FunctionArray, i then get the following error when i attempt to
serialize this class

Failed to serialize. Reason: Type 'cliext.vector<FunctionBase ^>' in
Assembly 'Runtime2, Version=1.0.2161.21524, Culture=neutral,
PublicKeyToken=null' is not marked as serializable.

Are the STL\CLR containers to be made serializable, or must i implement
ISerializable for FunctionArray and do it myself for the objects it
contains?

Thanks in advance.