From: Robert Ramey (ramey_at_[hidden])
Date: 2006-06-24 13:24:04
I'm curious as to the to boost policy in a situation similar to the
following:
Given the serialization library in its current state.
Someone creates a special kind of archive - called edit_[io]archive which
works something like this:
// create/obtain a tree control suitable for hierarchical data editing
?::archive_tree_control tc(..);
// create an edit archive
boost::archive::edit_oarchive eo(tc);
// initialize the tree control with the data as described by serialization
eo << my_data;
... user edits tree control - when he's done and hit OK
// reload data from tree control
// create an input archive from the tree control
boost::archive::edit_iarchive ei(tc);
ei >> my_data;
This is concievably useful application. Now when it comes the
implementation:
// common interface for all GUI platforms/libraries
namespace ? {
class archive_tree_control{
...
};
} // ?
// MFC implementation
#include <stdafx.h> // MFC headers which included windows.h and a lot more
namespace ? {
class archive_mfc_tree_control : // refinement of MFC standard control
public archive_tree_control,
public CTreeControl
{ ...
};
}//?
Assuming that something like this could be made to work - where would it fit
into
boost - if at all.
It depends upon proprietary code - MFC - Hmmm but then all our code depends
upon compilers - many of which are proprietary code.
It depends upon a proprietary libary interface - MFC - Maybe that would be
the
issue - but the code itself would be subject to a boost license.
I don't see a way to test it in a way that is compatible with boost
practices.
Its inherently non-portable. That might be the deal breaker.
I guess the question would be: What is the status of code which follows the
boost
license but depends upon code which doesn't follow the boost license?
Robert Ramey