s11n FAQ

Answers to Frequently Asked Questions

Here you will find answers to the questions which people ask fairly often about s11n.

How can i explicitely use a certain proxy, bypassing API marshaling?

(Added 15 June 2004)

This feature was removed in 0.8.3 and re-added again in 0.9.0. It will removed (again) in 1.1 (because the answer below is better than the API for doing this).

See the 3-argument version of s11n::deserialize<NodeT,SerializableT,ProxyT>(). Be aware of the different template parameters, compared to s11nlite functions!

Another approach: since you obviously know which proxy you want to use, you can bypass the call to de/serialize() altogether and simply call:

MyProxyType()( node, myserializable );

This also gives you the option of using non-temporary proxy, in the case that you need to initialize it with some data before using it.

There is a catch, however: if the de/serialization is recursive then any recursively-initiated serialization will revert back to using the SAM layer, which means it will bypass your explicit proxy. Work is underway to find a satisfying solution to this problem, but it is considered fairly low-priority at this point. If you'd like the priority upped, simply let us know that this is a problem for you and we can re-adjust priorities (that is - the problems which bother the most people typically get the most development attention).

Why do client-side compile times suck so badly?

(Added 22 June 2004)

So far, client users of s11n (including myself) have had only one consistent complaint: compile-times absolutely suck. This is an unfortunate side-effect of s11n's heavy reliance on class templates, in particular of features like partial template specialization. For example, for each Serializable type s11n internally creates a large number of tiny classes which take on tasks such as classloader registration, type naming and API marshaling. This type-creation is done at compile time and requires a lot of work at the compiler and linker levels. This is also why client object files and binaries are so large.

Short-term, there is no simple way around this - it is an unfortunate cost of employing the library in client code. Longer-term, there is always experimentation underway to reduce the compile times to some more acceptable level.

25 Sept 2004: recent releases of the lib have cut client-side compile times considerably. In the case of the s11nbrowser app, build time was cut in half.

Compile errors when (de)serializing certain POD types.

(Updated 25 Sept 2004)

As of version 0.9.14, s11n does not register PODs as full-rights Serializables by default. This is done primarily to cut compile times (see above), but also because Serializable PODs aren't used in most client-side files which need to include s11n headers. Clients wishing to "promote" PODs to Serializables should either #include pods_streamable.hpp or implement code similar to that header in their own project.

Another potential case where you'll see these errors:

You're using a POD type which s11n doesn't install a default proxy for. An example is unsigned long long. s11n doesn't assign proxies for all variants of all POD types - only the most commonly used (because each added proxy can add several seconds to client-side compile times). It is easy to install a proxy for a given POD. Simply paste the following code into the source file containing your serialization code, somewhere before the POD is actually (de)serialized:

#define S11N_TYPE MyType
#define S11N_TYPE_NAME "MyType"
#define S11N_SERIALIZE_FUNCTOR s11n::streamable_type_serialization_proxy
#include <s11n.net/s11n/reg_serializable_traits.hpp>

And edit the type name to suit. Note that the type must be i/ostreamable for this proxy to work! Note also that class templates cannot be registered this way - they require some hand-written code, as covered in this example. Remember, too, that i/ostreamable types can normally be de/serialized using node_traits::get/set(), and they do not need to be promoted to Serializables for that to work.

Compile errors involving const types

(Thanks to Paul Balomiri, added 15 Feb 2005)

Paul writes:

Right Now I am trying to serialize a rather complex structure which is :
typedef
std::map<
    long,
    std::pair<
          const std::map<
                         std::string,
                         std::vector<RType>
                         > *,
          std::map <
                    KTypeKey,
                    const std::map<
                                   std::string,
                                   std::vector<LType>
                                  > *
                   >
         > 
> RoadLaneAttrPtr;

This will almost work. There is one catch: we cannot deserialize const container members because we cannot write to them without violating their constness. The default std::map s11n algos jump through some hoops to work around that because a map's pair has a const first element, which means we cannot simply copy-assign them. There is no universal generic algorithm for doing that, though (AFAIK, anyway), which means that algos for dealing with any sort of const type have to be implemented on a type-by-type basis.

To solve the above problem, removing the const qualifiers from the two (map *) should do the trick. If you NEED to point to const data, then serialize only the parts which aren't const, and rebuild the pointers to const data immediately after (or as part of) deserialization. Remember that if you are using trees of std container, you can de/serialize specific sub-trees as you wish, by simply passing the appropriate nodes to s11n::de/serialize() (or your desired algorithm).

Also keep in mind that the default algorithms do not do "shallow" serialization of pointers: they de/serialize them as if they are object references. See the library manual for notes on this. Shallow de/serialization can be implemented in the s11n architecture, but is necessarily a client-side choice, as explained in the library manual.

Main menu:

Download from:

Libs/apps/utils:

SourceForge:

More Resources:

Related sites:

s11n FAQ

How can i explicitely use a certain proxy, bypassing API marshaling?

Why do client-side compile times suck so badly?

Compile errors when (de)serializing certain POD types.

Compile errors involving const types