From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-05-25 15:09:55
(Note: Apologies if there have been multiple copies of this mail. From my
posts to this list have not been getting through. This last attempt is after
re-subscribing to the list)
Is there a place in Boost for a library that tackles everything in the
subject line? I
believe the realistic
answer is no but I would be happy to be proven wrong.
Work in the different areas mentioned in the subject line recently collapsed
into a single
underlying technique. Given the example UDT below;
persistence is achieved using;
codec_object<person> configuration( "profile" )
configuration << new_member; // Save in a disk file name
configuration >> new_member; // Load from the same disk file
transmitting the same object between threads looks like;
send( new_member, other_thread );
while receiving that transmission occurs in code that looks like;
my_thread::received( person &new_member )
Transmission of messages across networks looks like;
send( new_member, socket_proxy );
Yes, its the same as for inter-thread communications. The "socket_proxy"
happens to be a variation on "my_thread" that forwards materials it receives
onto a socket connection.
Logging looks like;
WINSOCK( socket, AF_INET << SOCK_STREAM << 0 );
COMMENTARY( "connection to " << address_entered << " failed (" <<
failure << ")" );
Logging messages can be routed anywhere based on the type and unique
the originating party.
The fragments of code provided above hide a lot. While that's technically
I can appreciate that it might not flesh out my question at all (i.e.
...room in Boost). But
actually this is precisely the most compelling thing about the library - it
that traditionally can be quite difficult into fragments such as those
shown. The actual
implementation of the "send" primitive appears below;
// from a header
void send( type_hash, network_variant &, point_id );
send( const S &s, point_id a )
if( !a )
send( type_of<S>::hash(), network_variant() << s, a );
// from the related cpp
active_point::send( type_hash h, network_variant &nv, point_id a )
network_memory::iterator i = network_output<3>()( s );
*i++ << h;
i++->swap( nv );
*i++ << self;
point_register().send( s, a );
This is only provided to give a tiny bit more substance to my code
The catalyst for my question is that this work is about to be shelved. If
part of this work could be a contribution to Boost then that is much better
(from my POV) than nothing. Of course there has to be a place for it and
it has to pass the wonderfully rigorous Boost review process.
Some of the technical selling points;
* basic async model is taken from SDL (system description language).
* the technique is non-intrusive; e.g. it is possible to "send" instances of
types from third-party libraries
* externalized data (i.e. in disk files and on network connections) is
subject to formalized encoding/decoding
* the technique appears to be reasonably efficient - certainly no worse than
code it replaced.
* the technique copes with the storage and transmission of arbitrarily
complex C++ objects, easing design constraints
* the technique removes the need for data translation (i.e. the code that
appears around SQL servers, Windows registry and DCOM).
I appreciate that Boost already has components that solve different parts of
the same puzzle. Those components are major contributions to C++ that I
am not trying to compete with. If there is anything of value in what I have,
suspect it's in achieving the trilogy; persistence, thread communications
network messaging with a single unifying technique.
Any questions welcome,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk