- Boost - lists.boost.org

weak_ptr triple states
by Jaap Suter 17 Jul '05

17 Jul '05

Hi, a weak_ptr can be said to have three states. 1. Never been assigned to (default constructed) 2. Assigned to, lock will return a shared_ptr to a valid object. 3. Assigned to, but the object pointed to is dead and lock will return null. As far as I know it is currently impossible to distinguish between case 1 and 3. Am I overlooking something? If not, can somebody explain the reason why it is not possible to distinguish the two cases? Admittedly, I cannot come up with any elegant design in which such a distinction is useful, so the question is merely theoretical. Thanks, Jaap Suter

4 5

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers
by David Abrahams 16 Jul '05

16 Jul '05

"Carl Daniel" <cpdaniel(a)mvps.org> writes: > Aleksey Gurtovoy wrote: >> Carl Daniel writes: >>> I now have access to weekly builds of VC8 (currently testing the >>> 7/11/2005 build!). At the moment, it's not feasible to do boost >>> regression testing on those builds (it's a machine at MSFT), but I >>> could look into getting it set up. >> >> I think you are in a unique position w.r.t. weekly VC 8.0 builds, and >> IMO it would be a great service to both us and the VC8 team to test >> against those in addition to CTP/Beta 2. > > It looks like this might be possible - stay tuned. It'll be mid next week > at best before I can do the first run (assuming things get set up). I won't > be able to do them very often - perhaps only once/week because it won't be > possible to fully automate the process (the machine cannot make outgoing > connections to the internet, so I'll have to push tarballs to it, run the > tests, and then pull the results back. > > Does anyone have a set of instructions for building and running the > regression tests WITHOUT using Python? Right now, that's the sticking > point - Python's not installed, and I'm unable to install it. If I could > put together a ZIP file with all the command line tools pre-built and a > simple BATch file to run them, that'd be a workable solution. Somehow if they're letting us upload, build, and run our code it seems like it should be possible to upload, build, and run Python, no? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > Sent: Thursday, July 14, 2005 9:53 PM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > > > > From: boost-bounces(a)lists.boost.org > > > > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando > > > > > Cacciola > > > > > > > > Here is a real example. Imagine a researcher with many > > > > instruments > > > > > > > > Okay. This works, but what about that ugly call to loadPoint? > > > > The problem is that the library function is expecting a signal > > > value, not > > > > a Boost.Optional! Boost.Optional helped us manage data > > > > collection, but does not help us call trend::loadPoint. Let's > > > > look at > > > > > > The library can just as easily expect a Boost.Optional. > > > > But you're assuming that we have control over the library. That's > > probably the exception rather than the rule in real life. > > If you can change the library to use an adaptor for an > optional, why can't you change the library to use the > optional directly? > But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects. > > > > Using adapters, the call to trend::loadPoint in the > first example > > > > might look like this: > > > > > > > > > > > > // -- begin > > > > // call trend::loadPoint > > > > opt_dp::adapter f(-1); > > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > > > tr.loadPoint( f(*p) ); > > > > } > > > > // -- end > > > > > > Your version, with Boost.Optional was like this: > > > > > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > > > tr.loadPoint( *p ? p->get() : -1 ); > > > > } > > > > > > (I think you could change "p->get()" to "**p" if you like, BTW.) > > > > > > The latter is simpler and seems far more direct and, therefore, > > > readable. I don't see that your adapter has added any value. > > > > I tried to make the examples as syntactically plain as > possile; they > > are optimized for clarity. There is a key advantage in the example > > with adapters because the adapter is a function object. In that > > respect, the door has been flung open to many templated constructs > > that are more difficlt with the ?: operator. For example, a > > boost::transform_iterator could be created with the adapter to > > automatically access the underlying objects in a sequence. > > Hmmm. This reminds me of using the STL algorithms before > having Boost.Lambda, Boost.Bind, etc. Without a library of > predefined function objects that perform useful, reusable > adaptations, or a lambda approach to creating the adapters, > one winds up separating the value extraction logic from the > context in which it is used. > The Boost.Optional::adapter syntax is its own predefined library and, though lambda is a fantastic approach, it won't compile using Microsoft so we can't say it's the new paradigm. > > > I don't really see the value as presented thus far. > There is a tiny > > > amount of syntactic sugar, but is that warranted? > > > > I'm not sure. > > It was your idea, and now you're questioning it? I take from > that the responses you've gotten have caused you to rethink > not just the approach, but the idea? > Not at all. I would distrust anyone who has total faith in the usefulness of a new idea such as this one. The need for another opinion is why forums such as this one even exist. > > > Your requirements are flawed. The adapter should hold an > instance > > > of type T as provided by the constructor. Then, if the > > > Boost.Optional has no value, the adapter can return it's default > > > instance. IOW, the adapter shouldn't impose its needs on the > > > optional type. Boost.Optional would then work fine, > though I still > > > question the value of your adapter. > > > > I would also like to see the adapter avoid "imposing its > needs" on the > > optional object, but conversely, I don't think it would be > right to to > > return whole T objects (instead of references). > > There's no need. As I pointed out, the adapter can hold its > own T instance which represents the default. Then, when > asked for a value (returned by reference), the adapter > queries the optional. > If the optional has a value, the adapter returns the > optional's value. If not, the adapter returns the default > value it holds. > I considered that approach. It could be used to return only const references, which may or may not be enough. -Andy

6 9

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > Sent: Thursday, July 14, 2005 3:34 AM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > > From: boost-bounces(a)lists.boost.org > > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando > > > Cacciola > > > > Here is a real example. Imagine a researcher with many instruments > [snip long example indicating that using Boost.Optional for > data collection works fine, but for using or reporting that > information, Boost.Optional falls short] > > > > Okay. This works, but what about that ugly call to loadPoint? The > > problem is that the library function is expecting a signal > value, not > > a Boost.Optional! Boost.Optional helped us manage data collection, > > but does not help us call trend::loadPoint. Let's look at > another example. > > The library can just as easily expect a Boost.Optional. But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life. <clip> > > translation point is where I see the need for guaranteed object > > delivery, for it seems that Boost.Optional and guaranteed object > > delivery are two ends of the same pipeline: at the head, we > obtain (or > > fail to obtain) a value, and in the process escape the need for a > > signal value; at the tail, we use the values we've > obtained, possibly > > in a context that EXPECTS signal values. Requires them. > So far we've > > used only the trinary operator to perform this translation, but is > > there a better way? > > The fundamental issue seems to be that you want an object or > function that automagically produces a value, even if one > wasn't otherwise available. Yes. <clip> > > Using adapters, the call to trend::loadPoint in the first example > > might look like this: > > > > > > // -- begin > > // call trend::loadPoint > > opt_dp::adapter f(-1); > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > tr.loadPoint( f(*p) ); > > } > > // -- end > > Your version, with Boost.Optional was like this: > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > tr.loadPoint( *p ? p->get() : -1 ); > > } > > (I think you could change "p->get()" to "**p" if you like, BTW.) > > The latter is simpler and seems far more direct and, > therefore, readable. I don't see that your adapter has added > any value. > I tried to make the examples as syntactically plain as possile; they are optimized for clarity. There is a key advantage in the example with adapters because the adapter is a function object. In that respect, the door has been flung open to many templated constructs that are more difficlt with the ?: operator. For example, a boost::transform_iterator could be created with the adapter to automatically access the underlying objects in a sequence. <snip> > > I don't really see the value as presented thus far. There is > a tiny amount of syntactic sugar, but is that warranted? > I'm not sure. > > But, why do I keep saying optional instead of > Boost.Optional? To see, > > we must think about how an adapter interacts with the > optional object > > on which it operates. I won't spell out the fairly obvious > point that > > adapters should return references rather than whole T > objects, but if > > this is so, then an adapter that operates on an empty > optional object > > must ask that optional to, first, construct a new T object, then > > return a reference to that new object. Based on this, we can say a > > few things about an optional object, X, on which an adapter > operates: > > > > (a) X must have valid EMPTY and FULL states. > > (b) There must exist for X a valid EMPTY state, S, in which X > > privately holds an object, x, of type T. > > (c) If X is EMPTY (including state S), then altering or > replacing the > > internal x without setting the state to FULL is a "const this" > > operation. > > Your requirements are flawed. The adapter should hold an > instance of type T as provided by the constructor. Then, if > the Boost.Optional has no value, the adapter can return it's > default instance. IOW, the adapter shouldn't impose its > needs on the optional type. Boost.Optional would then work > fine, though I still question the value of your adapter. I would also like to see the adapter avoid "imposing its needs" on the optional object, but conversely, I don't think it would be right to to return whole T objects (instead of references). > > -- > Rob Stewart stewart(a)sig.com > Software Engineer http://www.sig.com > Susquehanna International Group, LLP using std::disclaimer; > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

5 14

Boost regression notification (2005-07-16)
by Douglas Gregor 16 Jul '05

16 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-16T15:03:26Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 244 failures in 11 libraries: io (1) multi_index (1) parameter (18) program_options (5) python (53) random (2) serialization (144) spirit (1) test (7) thread (2) wave (10) |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_special_set_ops: vc-8_0 |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-7_1 vc-7_1 vc-8_0 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mi_xml_archive_dll: vc-8_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: vc-8_0 test_shared_ptr_132_text_archive_dll: intel-win32-8_1 test_shared_ptr_132_xml_warchive: intel-win32-8_1 intel-win32-8_1 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_mutex: vc-7_1 test_thread_lib: gcc-3.2.3-linux |wave| test_re2c_lexer: vc-8_0 vc-8_0 test_slex_lexer: vc-8_0 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0 vc-8_0

1 0

[1.33.0] Status as of July 14
by Doug Gregor 16 Jul '05

16 Jul '05

We're very close to being able to release. We need to resolve the following issues before releasing: 1) Parameter library: many regressions; docs need to be finished (?) 2) Serialization library: many regressions 3) Inspection report: We don't need a fully-clean report, but we need to fix broken links, too-long file names, and files with tabs. At this time, do not commit any changes to CVS unless it: 1) Resolves a failure listed on the unresolved issues page at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html , 2) resolves a problem listed on the inspection page: http://www.boost.org/regression-logs/inspection_report.html 2) Is a documentation change, or 3) is on a branch. If you believe there is something critical that needs to go into this release that does not meet the above criteria, e-mail me privately. Doug

9 16

New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

This is my first post to the Boost distribution list, so please feel free to speak up if you find any part of this message to be outside the normal decorum. I am curious if there is support for what I'm calling a "dual_state" template class. Anyone familiar with Perl will instantly recognize the parallel. The idea is to attach a "statedness" value to arbitrary objects, allowing us to consider them defined or undefined. Newly constructed dual_state objects are undefined. For example, // -- begin template < class T > class dual_state { ... }; dual_state<int> a; a.defined(); // FALSE defined(a); // same thing // -- end We can "define" a dual_state object by assigning a value to it, either as a base type, T, or as another dual_state object: // -- begin // assign an int to a a = 5; a.defined() // TRUE // assign another dual_state<int> to a dual_state<int> b; b = a; b.defined(); // TRUE // -- end We can undefine a defined dual_state object: // -- begin a.undefine(); undefine(b); // -- end In addition, we can utilize an instance of another class, the "undefined_object", to interrogate or set the defined property of a dual_state object: // -- begin const class undefined_object {} undef; a = undef; a.defined(); // FALSE a == undef; // same thing // -- end The dual_state class provides a conversion to T. This conversion will, for an undefined dual_state object, return default T objects generated using the expression "T()". As an aside, it seems Boost.value_init may provide a more general solution that is worth considering. There is no conversion to T& because some compilers are utterly confused by such conversions. To make dual_state compatible with large or uncopyable objects, two explicit conversions are provided: // --begin template < class T > class dual_state { ... const T& value() const; T& define(); }; // -- end The value() member is straightforward. As for define(), it is necessary to first define the dual_state object before assigning it a value. The operator= member normally takes care of this step, but when dealing with the T reference directly we must explicitly use define(). An example using define() is shown below: // -- begin dual_state<int> x; cin >> x.define(); // -- end In Perl, the defined/undefined concept is tremendously useful, so I would expect similar utility in C++. I have not given any thought to what a dual_state<bool> is or how it is related to Boost.tribool. Thanks to everyone who took the time to read this whole post. I am open to all suggestions, including a better name -- "dual_state" is quite incongruent, but I can't think of anything better. Here are some additional poor suggestions: bistate, managed, switched, stated, definable. -- Andrew M. Jost

6 5

Re: [boost] Macros at namespace scope: trailing semicolon?
by Dave Gomboc 16 Jul '05

16 Jul '05

I'm amazed at how this particular thread has exploded. My $0.02: I've yet to see any arguments that I consider compelling to support the "always require camp". I expect direct textual substitution from a macro -- if it's expanding into a single statement, it ought to be expanding to a series of characters that includes the semicolon signalling the end of that statement. Other possibilities would only cause confusion. I'm firmly in the "never require a user to append a semicolon to a macro themself" camp. Dave

1 0

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers
by Aleksey Gurtovoy 15 Jul '05

15 Jul '05

Carl Daniel writes: > Aleksey Gurtovoy wrote: >> Victor A. Wagner Jr. writes: >>> my system will be going offline until around 2005 August 1 in less >>> than 24 hours as I've reported previously (we're moving) >> >> Thanks for the heads up. >> >> Is somebody else able/willing to pick up regular VC 7.1/8.0 regression >> testing? > > I now have access to weekly builds of VC8 (currently testing the 7/11/2005 > build!). At the moment, it's not feasible to do boost regression testing on > those builds (it's a machine at MSFT), but I could look into getting it set > up. > > I now (once again) have the infrastructure in place locally to do boost > regression testing on VC8 beta 2, and/or VC8 June CTP. Unless someone else > volunteers, I can try to get my regression testing up and running again on > either or both of these builds. I think you are in a unique position w.r.t. weekly VC 8.0 builds, and IMO it would be a great service to both us and the VC8 team to test against those in addition to CTP/Beta 2. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

Library request: pstream / socketstream / serial stream
by Marc Siegel 15 Jul '05

15 Jul '05

Hi, At our labs we share the desire for a C++ iostreams implementation that deals with these problem domains: 1. Inter-process communications, including simple popen-type usage, like a scripting language; also pipes for forking 2. Socket communications, TCP UDP and unix 3. Serial communications, and a wrapper to set the serial parameters For 1. and 2., we are currently using the socket++ library. I am also aware of the PStreams library for 1. for 3. we use hacked together mix of C and C++. Is there any sort of joint strategy planned to tackle this area? If there is, I may be able to contribute. Marc -- Marc Siegel MIT Lincoln Laboratory Wideband Tactical Networking Group mlsiegel(a)ll.mit.edu . (781)981-5434

5 5