- Boost - lists.boost.org

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

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

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman > Sent: Friday, July 15, 2005 11:41 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > Jost, Andrew wrote: > > > >>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. > > lambda works on Microsoft VC7.1 and above. Did I miss the > context of your statement? > Sorry, you are right. I am using VC 6.0 :-( > Cheers, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[Boost-bugs] [ boost-Bugs-1239052 ] timeconv.inl line 116 copy/paste error
by SourceForge.net 15 Jul '05

15 Jul '05

Bugs item #1239052, was opened at 2005-07-15 10:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1239052&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: timeconv.inl line 116 copy/paste error Initial Comment: has: if (boost::xtime_get(&cur, boost::TIME_UTC) <= 0) should be: if (boost::xtime_cmp(xt, cur) <= 0) my email is gyaralov(a)ixiacom.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1239052&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

15 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-15T15:24:22Z 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… 199 failures in 8 libraries: io (1) parameter (6) program_options (5) python (53) random (2) serialization (118) test (7) wave (7) |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: gcc-3.2.3-linux intel-win32-8_1 macros: gcc-3.2.3-linux intel-win32-8_1 sfinae: gcc-3.2.3-linux intel-win32-8_1 |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-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux 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-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux 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-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux 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-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_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_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |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 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

Re: [boost] Macros at namespace scope: trailing semicolon?
by Brian Allison 15 Jul '05

15 Jul '05

David Abrahams wrote: I don't know about the priorities of the rest of Boost, but I guess purity is a lower priority for me than some other things. FWIW, this tells me that I made the better choice to observe Boost, but not incorporate it yet if at all. At least, until I know what the highest priority are WRT Boost design. What are the most important issues for the designers of Boost? Please - I'm not trying to offend, but when I'm able to observe Boost's algebra of design issues then it'll mean either that I *can* incorporate Boost or that I need not spend time reading the mailing list anymore. Either way, it'll mean more of the only irreplaceable commodity (time). :) thanks, Brian

2 1

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

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, July 12, 2005 1:11 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > Now we're getting somewhere. Your post has led me in a new direction so, rather than answer the previous message point by point, I'll just use a few comments as anchors for my explanation. If I leave any question unanswered, please feel free to point it out. > > Hi Andrew, > > > [SNIP] > > > > *GUARANTEED OBJECT DELIVERY* > > First and foremost, dual_state is guaranteed to always > deliver a valid > > object (or reference), even if this object (or reference) must be > > conjured from nowhere. This is in direct contrast to > Boost.optional, > > which maintains that > > > Well, it never ocurred to me to let optional<> provide default values. > I just can't think right now of any situation were I would use it. > Can you post some *real life* examples? > (the example you posted is not good enough because as it is > one would argue wthat the optional/dual_state wrapper is not > needed to begin with) Here is a real example. Imagine a researcher with many instruments collecting data. To make it concrete, let's say we have a geologist with dozens of instruments spread across some mountain summit. When he pushes enter on his laptop, all the instruments take a measurement and transmit it to the laptop. Or not. Because sometimes instruments fail, or just fail to respond. Which is why he's using Boost.Optional to store the measurements. So that solves the problem and we can all go home, right? But wait! Once we get off the mountain there is more work to do. Our geologist friend still must retrieve and analyze his data. He will load it into containers and call functions. One of those functions is a member named of the class trend named trend::loadPoint. This member accepts data points into the class then, after all the points are loaded, a call to trend::calculate returns some useful number. To do its work, trend must account for missed measurements, so loadPoint accepts a signal -- namely, any negative value -- to indicate no measurement. For the sake of argument, we'll assume that "trend" is located in a library the geologist cannot change. His code might resemble the following example program: // -- begin #include <boost/optional/optional.hpp> #include <boost/none.hpp> #include <iostream> #include <vector> typedef long double data_point; typedef boost::optional<data_point> opt_dp; typedef std::vector< opt_dp > data_set; // the real "trend" is in a library -- this definition is for illustration only class trend { public: void loadPoint( data_point x ) { if( x<0 ) { cout << "no measurement" << endl; } else { cout << "point: " << x << endl; } } }; int main() { data_set d; trend tr; // make up some data d.push_back(5); d.push_back(boost::none); d.push_back(10); // call loadPoint for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( *p ? p->get() : -1 ); } return 0; } // -- end 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. Say I'm working on a project that persists some configuration data. Momentarily forgetting that Boost.Program_options exists, I decide to use a simple model in which I map string parameter names to string values. Values are allowed to be non-existent, so the map structure might be declared as follows: // -- begin typedef boost::optional<string> param_map_value; typedef std::map<string, param_map_value> param_map; param_map pMap; // -- end After our program runs for a while, and after the user has set a few persistable parameters, it is time to quit, so the program opens a configuration file and begins writing the contents of pMap to that file, which should look like this: // -- begin # CONFIG FILE PARAM_A VALUE_A PARAM_B VALUE_B PARAM_C <undef> ... // -- end In the particular case above, the user has apparently set values for the "A" and "B" parameters, but not for "C". We might write such a file with the following code: // -- begin // assume cf_out is an open ofstream for( param_map::iterator p = pMap.begin(); p != pMap.end(); ++p ) { cf_out << p->first << " " << ( p->second ? p->second.get() : "<undef>" ) << endl; } // -- end This illustrates the same problem as before, namely that it requires us to translate an empty Boost.Optional into something else. This 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? > > As David Abraham said, however, IF it turned out to be useful > (I can't see it right now) it seems that such an "optional > with default" could be a specialized form of optional<>. > > Off the top of my head, a default value could be supported in > at least 3 ways: > > (1) Storing an actual default value in each optional instance. > > (2) Parameterizing optional<> with a static factory that can > be called to provide such defauts. > > (3) Using T's default constructor (if any) to create such a value. > > Notice that optional<> does not require T to be DefaultConstructible. > Several people were quick to point out a key conceptual flaw in the original dual_state concept. By delivering only default-constructed objects, dual_state is an arbitrarily circumscribed implementation of a more general, and powerful, model. Suggestions (1) and (2), proposed in the above clip, are a bit better because they let us specify the default value, but a deeper problem remains. It is that by combining the default value with the optional-like storage object, we commit the mortal sin of joining metadata with the real data it describes. It's the same reason we use iterators to serially access containers, rather than absurdly assigning some "current_element" state to the container itself. Returning to the trend::loadPoint example, that function expects the signal value to be a negative number. The next function might expect 0. A third function, yet another signal. The default value is not a property of our data, rather it is a property of the functions that USE our data. In light of this, a better implementation of guaranteed delivery would make use of template function objects that I'll call "adapters". The role of an adapter would be to evaluate a given optional object (I'll refer to anything resembling Boost.Optional as an "optional" object) into either the valid object it contains, or a default value, which is probably defined in the adapter's template specification or constructor. Adapters separate our optional objects from the defaults we might want to use in place of uninitialized T objects. Note that they are incompatible with noncopyable T objects. 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 The second example would look like this: // -- begin // assume cf_out is an open ofstream param_map_value::adapter f("<undef>"); for( param_map::iterator p = pMap.begin(); p != pMap.end(); ++p ) { cf_out << p->first << " " << f(p->second) << endl; } // -- end With a little creativity, programmers could make further use of the STL to craft strikingly elegant solutions. It seems to me adapters would make a useful and appropriate addition to our toolbox, improving the flexibility with which we can access copyable T objects contained in an optional container. 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. As it currently is, Boost.Optional, which we can think of as a stack with fixed capacity 1 and variable size, is incompatible with adapters, but we could certainly define a class derived from Boost.Optional that meets the above requirements. Perhaps, for contrast it could be called "Required"? User's might choose to use Required, sacrificing compatibility with noncopyable objects, in cases where they think adapters will come in handy. This message is already too long, so I'll reserve my additional thoughts until others have a chance to respond. -Andy

4 3

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

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, July 12, 2005 1:27 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > > "Jost, Andrew" <Andrew_Jost(a)mentor.com> escribió en el > mensaje > news:8F7931C35114FA4F9D25E1A9299408E20276DFA7@SVR-ORW-EXC-06.m > gc.mentorg.com... > >> Boost.Optional has some interaction with (including initialization > >> from) boost::none, which seems to correspond to your "undef". > > > > Good point, but I would also like to see overloaded == and != > > operators using boost::none. > > > That is already supported. I think this is another documentation problem. http://www.boost.org/libs/optional/doc/optional.html shows a constructor and operator= using boost::none, but no operators == or !=. But you are right that the functionality is supported in the library. > > Fernando Cacciola > SciSoft > > > >

2 1

[iostreams] please vote on template names
by Jonathan Turkanis 15 Jul '05

15 Jul '05

Hi, I'm trying to pick good names for the fundamental iostreams components streambuf_facade and stream_facade: template<typename Device ... > class streambuf_facade : public basic_streambuf< > { // Peform i/o using an instance of Device }; template<typename Device ... > class stream_facade : public basic_[i][o]stream< > { // Peform i/o using an instance of Device }; Here are the candidates: 1. streambuf_facade / stream_facade 2. generic_streambuf / generic_stream 3. streambuf / stream 4. xstreambuf / xstream 5. device_streambuf / device_stream 6. devbuf / devstream Please let me know what you think. Jonathan

10 33

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

15 Jul '05

>From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen >Jost, Andrew wrote: >> I am curious if there is support for what I'm calling a "dual_state" >> template class. > From your description it sounds a lot like Boost.Optional. What are the main differences? >Eelis I'll admit I did not even pause at Boost.optional when I scanned the library listing for previous work, a failure in my ability to connect the description, "Discriminated-union wrapper for optional values," with the concept I had in mind. I'm not sure if the problem is in my unfamiliarity with the subject, the description itself, or the concept's general ineffability. In any case, I'll contrast Boost.optional with dual_state to see where the differences lie. But first, let's find a common starting point. The Boost.optional documentation succinctly states the purpose of that library: "optional<T> intends to formalize the notion of initialization/no-initialization allowing a program to test whether an object has been initialized" That document also discusses various solutions to the general problem of handling "signal" values, including cases where the cumbersome pair<T, bool> construct is necessary because no sensible signal can be defined. I would say that dual_state is intended to tackle the same set of problems. However, I see three important differences. *GUARANTEED OBJECT DELIVERY* First and foremost, dual_state is guaranteed to always deliver a valid object (or reference), even if this object (or reference) must be conjured from nowhere. This is in direct contrast to Boost.optional, which maintains that "access to the value of an uninitialized object is **undefined behaviour**" The above quote is also from the Boost.optional documentation (emphasis mine). Boost.optional and dual_state appear to address the same problems, but with two fundamentally distinct philosophies. Consider a dual_state<string>. In the following code, the char* in the final expression is guaranteed to be valid, so the programmer needn't even bother to check it before calling strlen: // -- begin typedef dual_state<std::string> state_string; state_string str; int len; ... len = strlen( str->c_str() ); // always a valid char* // -- end Note that operator-> is used to access a base class' member. The analogous code using Boost.optional is as follows: // -- begin typedef boost::optional<std::string> opt_string; opt_string str; int len; len = strlen( str.get().c_str() ); // UNDEFINED! // the correct way if( !str ) { // do something else <== HERE } else { len = strlen( str.get().c_str() ); // okay now } // -- end A programmer may view dual_state's "guaranteed delivery" behavior as either advantage or liability, but his opinion, if tenable, must focus on the relative benefits afforded by guaranteed objects versus the risks posed by -- one might say -- "junk" default values. I would say it depends on the application. More to the point, if the answer to what goes "<== HERE" is always "set len = 0" for a particular application, then dual_state could offer greater clarity with less work. *FULL OPERATOR SUPPORT* A second difference is that dual_state directly supports the full complement of operators (for built-in types), this due to the fact that most operators are delegated through the implicit conversion-to-base-type operator. Exceptions to implicit delegation are those operators that modify the dual_state object itself. The example below demonstrates two operators, + and +=. Addition operates via the conversion to T (not T&) operator and therefore returns a regular T object, at the cost of one extra copy (a copy, incidentally, that can be avoided by using the value() member). The concerted += operator, which is defined by dual_state, avoids copies and evaluates to a dual_state reference: // -- begin typedef dual_state<int> state_int; state_int x; x + 5; // evaluates to (int); x still undefined x += 5; // evaluates to (state_int&); x is defined, equal to 5 x.value() + 5; // also evaluates to (int) typedef boost::optional<int> opt_int; opt_int y; y + 5; // won't compile y += 5; // nor will this y.get() + 5; // evaluates to (int) // -- end Again, the question of which behavior is most desirable hinges on the programmer's needs. While Boost.optional and dual_state both give the programmer a way manage defined and undefined objects; a way to manage initialized and uninitialized data; a way to sidestep "signal" values: EOF, -1, n_pos -- the semantics of one approach or the other may be better suited for a given application. *THE UNDEFINED_OBJECT* A third difference between Boost.optional and dual_state involves the very personal issue of syntax. It is nonsense to tell people to prefer one syntax over another, but I will note that dual_state's use of the undefined_object lends a unique feel to code that uses it. The programmer's intent is unmistakably clear when "undef" is used to initialize members: // -- begin using dual_state_namespace::constants::undef; class bar { ... }; class foo { public: dual_state<int> x, y, z; dual_state<bar> a; foo() : a(undef), x(undef), y(undef), z(undef) {} }; // -- end The concept of using self-evident constructs to obviate documentation is a valuable one. It is detailed in the Boost.noncopyable notes. *SUMMARY* My intent has been to clearly and accurately articulate the conceptual differences I see between Boost.optional, a reviewed and tested library having several years usage history, and dual_state, a concept. In that I have succeeded or failed, others may comment, judge. -- Andrew M. Jost

15 43

[intrusive_ptr] Constructor not explicit.
by Russell Hind 15 Jul '05

15 Jul '05

Just wondered why intrusive_ptr(T * p, bool add_ref = true); isn't explicit? The second arg defaults so (using bcc32-5.6.4), an intrusive_ptr can be explicitly constructed from a raw ptr. Is this intended when shared_ptr is designed to prevent this? Cheers Russell

2 2