Create "modules" for types not in the standard library

[AzothAmmo]

We already have support for boost::variant mostly due to needing it for a project when cereal was created, but there are many other common things cereal could have support for.

Instead of cluttering the cereal types directory with these, it would be better to have organized modules of support for things, e.g. boost, opencv, or eigen. I'd prefer if these weren't pulled by default with cereal, so they either need to be in another repository or potentially just in some directory that would be outside of the normal cereal install (the cereal include folder).

This relates to the pull requests #53 and #122.

[stevehickman]

Modules makes sense to me. For something as large as Boost, would it make sense to have submodules as well?

[stevehickman]

In terms of subcategories for Boost, it may make sense to use Boost categories or(http://www.boost.org/doc/libs/1_56_0/?view=categorized) or individual library names as the organizing principle to help users know which submodules they might need. In some cases (e.g., Containers and Data Structures), the individual libraries within the category may contain enough data structures to make creating a separate module for each worthwhile. In other cases (e.g. Algorithms), where the primary focus in not on data structures, there will still be data structures used by the libraries in the category, but there may not be enough in each individual library to make creating an entire submodule worthwhile.

The competing forces, as I see it right now, are 1) the more that is in a single module/ submodule, the more effort required to keep the module/submodule updated; 2) the more modules/submodules proliferate, the higher the effort required of each user to keep track of which ones are needed.

Net result: Probably makes sense to just start with a single Boost module, with the thought that breaking it into multiple submodules down the road as it grows may be needed. As each module, submodule grows "too large", it gets factored into smaller pieces based on some easily understood criteria (like Boost category or library name. Knowing that we'd need to leave room to refactor / break apart modules should be sufficient initially.

[stevehickman]

I did a quick review of Boost and created the list below of the libraries it makes sense to serialize. This list excludes libraries that are already in C++11 or those that don't have data structures that it would make sense to serialize. Note that this was a quick review - it may turn out that some of these don't need to be serialized. I have not (yet) attempted to identify which of these are used the most.

Any
BiMap (maps and iterators after maps)
Circular Buffer
Compressed Pair
Config (Standard Integer Types) -
Container - maybe? mostly C++11 conformant
Context - for thread switching - would this ever be serialized (debug logs?)
Date_Time - could, but std already has Chrono - lower priority
Dynamic Bitset
Exception - maybe - dig deeper
Filesystem - in TR2? Check
Flyweight
Fusion
Geometry
GIL (Generic Image Library) - might be big enough for a submodule
Graph - might be big enough for a submodule
Heap
ICL
Interprocess
Interval
Intrusive
IO State Savers - duh
Iterators - must work in conjunction with iterated collection?
Locale
Lockfree
Math - 128 bit floating point structure. Others?
Math Octonions
Math Quaternion
Meta State Machine
Multi-Array
Multi-Index
Multiprecision
Optional - done
Parameter
Pointer Container (along with the things it points to)
Polygon
Property Map
Property Tree
Range - but only if the referenced collection is serialized
Rational
Regex
SmartPtr (if any aren’t in C++11)
Spirit
Statechart
Tribool
Tuple
TypeIndex
uBLAS
Units - store value and units (might need own submodule)
Uuid
Variant - already done

[AzothAmmo]

My intention here will be for the majority of these modules to be community contributed once we have the infrastructure in place, and we likely won't implement anything ourselves unless we have an immediate need for it.

[patlecat]

Excellent idea, that will help immensely working with Cereal! But I wouldn't make the use of them modules too remote and complicated. A simple include or config entry in a header file should do to add what the developer needs.

[patlecat]

Besides I think especially Flyweight could profit a lot from this, since it added Boost::Serialization in 1.57 and has key-value types. With this and a fast serialization lib Cereal could rival with the use of pure key-value store databases like Redis! 💃

[pwm1234]

I just implemented cereal load/save functions for boost::posix_time::ptime. Is there someplace I can put this? In a comment above @AzothAmmo said "once we have the infrastructure in place". Since that comment was made two years ago and this is still an open issue, I suspect the intended infrastructure will not be in place. Can we adjust our intentions to get these kind of community contributions in place? (I am not being critical--I just found cereal and really like the work that you have done on it! I want it to continue to improve and grow.)

My preference would be a subdirectory in the cereal repo, perhaps include/cereal/contrib? I feel this would be better than a separate repo. I am, however, a newcomer to cereal; I would certainly defer to others.