On Sun, 25 Apr 2004 11:07:38 -0700, Robert Ramey wrote

Jeff Garland wrote:

...

...

a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used.

Are you saying there is actually extra runtime overhead with the way I've implemented serialization? If so, that needs to be in the docs b/c I was under the impression that external versus internal implementations would be the same...

I didn't mean to imply your method had any runtime overhead - I was just restating all the features. However, the other points are real advantages of just putting it in with the class definition. BTW the non - intrusive version could also be put in the normal class header. However if its too complicated it might end up requiring more file inclusion so it would have to be considered on a case by case basis.

Well ok. Here's how I see those points: -- a) and c) are a tradeoff. More code to parse in when not using serialization versus an extra header file. That trades off against me keeping a maintainable and flexible codebase. I like the idea of being able to add the serialization code indepedendently. This also allows users to shortcut a #include of boost/serialization altogether if they want. I can also take date_time out of boost without serialization if I need to more easily. -- b) No difference as you say. -- d) To support the no thinking part I will include the serialization stuff in the main date_time include files. See http://lists.boost.org/MailArchives/boost/msg63885.php for more.

I personally don't have a strong position on this. As far as serialization is concerned the alternatives are all equivalent. The decision where to but the serialization templates can be decided on other factors.

Well, I'm not 100% sure they are equivalent. In fact this discussion is making me wonder if the adaptations for the standard library should be made distinct from the serialization core to make the architecture clear. Something like: serialization/std_containers/vector.hpp ... Jeff