- Boost - lists.boost.org

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

Parameters Library Overload Generation Macros
by David Abrahams 15 Jul '05

15 Jul '05

It just occurred to me as I was writing the docs (it's amazing how writing documentation clarifies design issues!) that for the parameters library, "The Forwarding Problem" usually isn't really as bad as it might seem. In a family of overloaded forwarding functions, the only positions in which we need a T&/T const& overload pair are those in which the corresponding parameter is an out (or in/out) parameter. When passed non-positionally, the const/non-const issue is handled by the overloaded operator= on the keyword objects. So I'm thinking the macros for generating the overloads, in the next release at least, should just take care of generating the right overloads. For example, something like BOOST_NAMED_PARAMETER_FUNCTION( void, depth_first_search, (required(in))(in)(in)(out)(in) ) might work. For reference, the docs for depth_first_search are at http://www.boost.org/libs/graph/doc/depth_first_search.html Here I am assuming that the parameter order would be: graph visitor index_map color_map root_vertex [Doug, I am a little concerned about how to translatate the interface for tutorial purposes, since the documented positional interfaces don't include an overload that takes 5 parameters: index_map can only be passed as a named parameter! I don't want to confuse people. Could you take a look at libs/parameter/doc/html/index.html and give your feedback? -- Thanks] Of course, this idea doesn't work out so well for an unnamed parameter interface, which we're also going to support after 1.33. But that's a separate macro ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[preprocessor] How to prevent macro expansion with SEQ?
by Markus Schöpflin 15 Jul '05

15 Jul '05

Hello, I have the following macro code: #define PY_DEFINE_CONSTANT(X) scope().attr(#X) = X #define PY_DEFINE_CONSTANTS_HELPER(R, DATA, X) PY_DEFINE_CONSTANT(X); #define PY_DEFINE_CONSTANTS(SEQ) \ BOOST_PP_SEQ_FOR_EACH(PY_DEFINE_CONSTANTS_HELPER, BOOST_PP_EMPTY, SEQ) This works fine when used with non-macro arguments: PY_DEFINE_CONSTANTS((foo)(bar)) expands to: scope().attr("foo") = foo; scope().attr("bar") = bar; But when foo and bar are macros like this: #define foo 1 #define bar 2 it expands to: scope().attr("1") = 1; scope().attr("2") = 2; Is there a way to get this: scope().attr("foo") = 1; scope().attr("bar") = 2; or this: scope().attr("foo") = foo; scope().attr("bar") = bar; IOW, how can I prevent macro expansion for X when invoked from PY_DEFINE_CONSTANTS()? TIA, Markus

3 5

Re: [boost] VC8 type traits documentation
by Jason Shirk 15 Jul '05

15 Jul '05

> -----Original Message----- > From: narechk [mailto:narechk@gmail.com] > Sent: Wednesday, July 13, 2005 10:29 AM > Subject: Re: VC8 type traits documentation > > > It appears the support for compiler intrinsic type traits in Beta2 is > implemented only partially: > > typedef int T; > __is_pod(T); > __has_trivial_constructor(T); > __has_trivial_copy(T); > __has_trivial_assign(T); > __has_trivial_destructor(T); > __has_nothrow_constructor(T); > __has_nothrow_copy(T); > __has_nothrow_assign(T); > > Ditto for the rest of fundamental types. All of the above return false, > which AFAIK is incorrect! [§3.9, ¶10; §9, ¶4] > The compiler intrinsics are only there to provide the type information that is otherwise unavailable. Put another way, for fundamental types, we decided we don't care what the value is (we default to false) since an implementation of type traits can get the right value. This simplifies the implementation and puts the burden on the library implementation which can change more easily than the compiler. > struct A > { > A() {} > A(const A&) {} > const A& operator=(const A&) {} > }; > > typedef A T; > __is_pod(T); // false > __has_trivial_constructor(T); // false > __has_trivial_copy(T); // false > __has_trivial_assign(T); // false > __has_trivial_destructor(T); // true > __has_nothrow_constructor(T); // false, too conservative > __has_nothrow_copy(T); // false, too conservative > __has_nothrow_assign(T); // false, too conservative > > The compiler is too conservative regarding nothrow, it should be able to > deduce that constructor, copy and assign can never throw. > > struct B > { > B() throw() {} > B(const B&) throw() {} > const B& operator=(const B&) throw() {} > }; > > typedef B T; > __is_pod(T); // false > __has_trivial_constructor(T); // false > __has_trivial_copy(T); // false > __has_trivial_assign(T); // false > __has_trivial_destructor(T); // true > __has_nothrow_constructor(T); // true > __has_nothrow_copy(T); // true > __has_nothrow_assign(T); // true > > It seems the compiler needs an explicit nothrow statement in order for > ctor, copy and assign to be qualified as nothrow. Presumably the result > of nothrow deduction is not fed to the intrinsics correctly in this > version. > > Can someone comment on the above. > You are correct that the compiler _could_ deduce nothrow in your example, but in general the compiler couldn't (for example, if the definition of the function is in the current translation unit), and therefore shouldn't try. -- Jason Shirk VC++ Compiler Team

3 2

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 15 Jul '05

15 Jul '05

Greetings, I wrote in part: > Prompted by some discussion on comp.sdt.c++.moderated, I have a > small template that allows the user to declare an integer literal > in binary. > > Usage looks like: > > #include "binary_int.hpp" > > unsigned int binary = binary_int<1001,0011,1011,0000>::b; Thanks for all the responses. Here are answers to some of the questions I got. ------------------------ Pavel Vozenilek asked: > * How does it deal with bit values like 0111? This is octal value. Right. There are specilizations for decimal and octal values. This means there is some aliasing. A few non-binary decimal and octal values leak through. For example 0111 (octal) is 73 decimal and, for that matter, 0x49 hex. So the template accepts all of these values. It's not perfect, but it's the best I could figure out. > * Does it check that the digits are 0 or 1 during compile time? It doesn't check individual digits. It checks for specific numeric values which would be good at representing a 4-bit binary value. See the binary_nibble specializations in the appended code. > * Would it work with hex values like: > bits<unsigned, 0xF,0x8>::value; No, not as it is currently implemented. ------------------------ Vladimir Prus responded: > Why is that better than > > unsigned x = strtoul("1010010001000010000001", 0, 2); > > ? I believe that 'strtoul' is part of C99. Not a bad approach. The binary_int template does the translation at compile time rather than at run time. It does the check (as best it can) for valid binary values at compile time as well. ----------------------- Paul A Bristow replied: > Can you post reference to discussion... I'm not very clever with URLs but the discussion, according to Google Groups, was titled "Power of 2 Enumerations" in comp.std.c++. The discussion in question started with a post by David Abrahams on November 1st, 2004 where he wrote: > You can even write a simple template that makes these into > compile-time constants: > > const feature_t FEATURE1 = binary<001>::value; > const feature_t FEATURE2 = binary<010>::value; > const feature_t FEATURE3 = binary<100>::value; Paul also asked: > and perhaps append the binary_int.hpp file as it sounds quite > short? Yes, the template is only 150 lines or so including comments. I've appended it, in its current state, to the end of this response. I did some editing of the template in an attempt to make it boost compatible, although I didn't put it in the Boost name space. Even though it says it's a boost file, I'm fully aware that it isn't. Sorry about that. Thanks for everyone's attention. Scott Schurr binary_int.hpp -------------------------------------------------------------- // Boost general library binary_int.hpp header file -------------------------// // Copyright Credence Systems 2005, as submitted by Scott Schurr. Use, // modification, and distribution are subject to the Boost Software License, // Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) #ifndef BOOST_BINARY_INT_HPP #define BOOST_BINARY_INT_HPP // Make a couple of templates to help catch bad binary_nibble parameters template <bool> struct binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111; template <> struct binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111<true> { }; // Write a 4-bit integer value as binary. // // Usage: // unsigned int n = binary_nibble<1011>::b // // The tricky part is remembering to include the '::b' at the end. // For example: // // #include "binary_int.h" // ... // int regValue = binary_nibble<1001>::b; // // Make a general binary_nibble type that causes a failure. Only // the specializations are valid usages. template <unsigned int v> struct binary_nibble { binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111<false> t; enum { b = 0 }; }; // Specialize the binary_nibble template for values we allow. // The following values work for both decimal and octal. template<> struct binary_nibble<0> { enum { b = 0x0 }; }; template<> struct binary_nibble<1> { enum { b = 0x1 }; }; // Decimal values. template<> struct binary_nibble<10> { enum { b = 0x2 }; }; template<> struct binary_nibble<11> { enum { b = 0x3 }; }; template<> struct binary_nibble<100> { enum { b = 0x4 }; }; template<> struct binary_nibble<101> { enum { b = 0x5 }; }; template<> struct binary_nibble<110> { enum { b = 0x6 }; }; template<> struct binary_nibble<111> { enum { b = 0x7 }; }; template<> struct binary_nibble<1000> { enum { b = 0x8 }; }; template<> struct binary_nibble<1001> { enum { b = 0x9 }; }; template<> struct binary_nibble<1010> { enum { b = 0xA }; }; template<> struct binary_nibble<1011> { enum { b = 0xB }; }; template<> struct binary_nibble<1100> { enum { b = 0xC }; }; template<> struct binary_nibble<1101> { enum { b = 0xD }; }; template<> struct binary_nibble<1110> { enum { b = 0xE }; }; template<> struct binary_nibble<1111> { enum { b = 0xF }; }; // Octal values. template<> struct binary_nibble<010> { enum { b = 0x2 }; }; template<> struct binary_nibble<011> { enum { b = 0x3 }; }; template<> struct binary_nibble<0100> { enum { b = 0x4 }; }; template<> struct binary_nibble<0101> { enum { b = 0x5 }; }; template<> struct binary_nibble<0110> { enum { b = 0x6 }; }; template<> struct binary_nibble<0111> { enum { b = 0x7 }; }; // The following helper template determines the behavior of the // binary_int template when default arguments are passed in. // A default argument (0ul-1) will leave the previously calculated // value unchanged. A non-default argument multiplies the previously // calculated value by 16 and adds in the new (non-default) argument. template<unsigned int v> struct binary_int_arg { enum { b = binary_nibble<v>::b, mul = 16, }; }; template<> struct binary_int_arg<0ul-1> { enum { b = 0, mul = 1, }; }; // Declare a binary value in the following form: // // int i = binary_int<1100,1010,0001>::b // // Usage: // // unsigned int = binary_int<up to 16 binary_nibble>::b // // Write an integer as a binary value composed of up to 16 nibbles. // The tricky part is remembering to include the '::b' at the end. // For example: // // #include "binary_int.h" // ... // int regValue = binary_int<1000,1001,0011,0000>::b; // // One to 16 nibble-sized arguments are allowed, which allows for word // lengths up to 64 bits. If it's not working for you make sure that // you are including the closing '::b'. template<unsigned int b15, unsigned int b14 = 0ul-1, unsigned int b13 = 0ul-1, unsigned int b12 = 0ul-1, unsigned int b11 = 0ul-1, unsigned int b10 = 0ul-1, unsigned int b9 = 0ul-1, unsigned int b8 = 0ul-1, unsigned int b7 = 0ul-1, unsigned int b6 = 0ul-1, unsigned int b5 = 0ul-1, unsigned int b4 = 0ul-1, unsigned int b3 = 0ul-1, unsigned int b2 = 0ul-1, unsigned int b1 = 0ul-1, unsigned int b0 = 0ul-1> struct binary_int { private: enum { v15_ = binary_int_arg<b15>::b, v14_ = (v15_ * binary_int_arg<b14>::mul) + binary_int_arg<b14>::b, v13_ = (v14_ * binary_int_arg<b13>::mul) + binary_int_arg<b13>::b, v12_ = (v13_ * binary_int_arg<b12>::mul) + binary_int_arg<b12>::b, v11_ = (v12_ * binary_int_arg<b11>::mul) + binary_int_arg<b11>::b, v10_ = (v11_ * binary_int_arg<b10>::mul) + binary_int_arg<b10>::b, v9_ = (v10_ * binary_int_arg<b9>::mul) + binary_int_arg<b9>::b, v8_ = (v9_ * binary_int_arg<b8>::mul) + binary_int_arg<b8>::b, v7_ = (v8_ * binary_int_arg<b7>::mul) + binary_int_arg<b7>::b, v6_ = (v7_ * binary_int_arg<b6>::mul) + binary_int_arg<b6>::b, v5_ = (v6_ * binary_int_arg<b5>::mul) + binary_int_arg<b5>::b, v4_ = (v5_ * binary_int_arg<b4>::mul) + binary_int_arg<b4>::b, v3_ = (v4_ * binary_int_arg<b3>::mul) + binary_int_arg<b3>::b, v2_ = (v3_ * binary_int_arg<b2>::mul) + binary_int_arg<b2>::b, v1_ = (v2_ * binary_int_arg<b1>::mul) + binary_int_arg<b1>::b, v0_ = (v1_ * binary_int_arg<b0>::mul) + binary_int_arg<b0>::b, }; public: enum { b = v0_ }; }; #endif // BOOST_BINARY_INT_HPP

4 3

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers (Was: [1.33.0] Status as of July 14)
by Rene Rivera 15 Jul '05

15 Jul '05

Carl Daniel wrote: > 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. Is that a "willing to run vc8 tests but not vc71" ? For those volunteering it would be good to mention what resources you have available; CPU, memory, disk space, and machine time. As it takes a considerable amount of resources for testing, especially disk space. And having the faster machine and large ram will speed up the testing. I'm not trying to discourage people from volunteering though :-) Just want to make sure we keep up a reasonable testing pace. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [boost] weak_ptr triple states
by Jaap Suter 14 Jul '05

14 Jul '05

>> 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. > There is no particular reason to make 1 and 3 indistinguishable. You are > right that weak_ptr could have provided an "is empty" query in addition to > expired(). There just aren't any compelling use cases for it, as far as I > know. Are there compelling reasons not to add such a member function, i.e. a different shared_ptr implementation wouldn't be able to provide such a function? A friend of mine actually came up with a use case in his code, which is what prompted this question. In pseudo-code, it looked like this: struct guarded_memory { void* memory; weak_ptr guard; guarded_memory(void* m) : guard(), memory(m) {} guarded_memory(void* m, weak_ptr g) : guard(g), memory(m) {} void access() { if (guard.never_been_assigned_to_before()) { // no guard means always accessible do_something_with(memory); } else { if (shared_ptr p = guard.lock()) { do_something_with(memory); } } } }; Basically; if the user never provided a guard, the memory is deemed accesible at all times, otherwise accessibility depends on the liveliness of the pointed to guard. In my opinion, the code is ackwardly assymetrical and not an example of great design, but alas, it's what he came up with in some context. The solution to the above code is too add a litle boolean that remembers which of the two constructors has been called. This boolean is strictly speaking redundant because weak_ptr already stores this information. Hence my question. Thanks, Jaap Suter

3 2

Type Traits Documentation Outdated?
by David Abrahams 14 Jul '05

14 Jul '05

It seems like the type traits docs have suffered some stagnation over time. For example, is it documented somewhere that almost all the traits are also Metafunctions? Also, the "guidelines for integral constant expressions" probably ought to be updated to recommend the use of MPL operations on integral constant wrappers instead of the baroque and long-winded ice_whatever templates. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost Wiki is corrupt
by Jody Hagins 14 Jul '05

14 Jul '05

Recent changes show... July 14, 2005 * (diff) BoostSocket/TimeValueConcept 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) BoostSocket/TimeValueConcept 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) BOOST WIKI 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) RecentChanges 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) RecentChanges 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com

2 1