Re: [boost] New Library Proposal: dual_state
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen
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
Jost, Andrew wrote: 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
Jost, Andrew wrote:
*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:
[snip]
The concept of using self-evident constructs to obviate documentation is a valuable one. It is detailed in the Boost.noncopyable notes.
Boost.Optional has some interaction with (including initialization from) boost::none, which seems to correspond to your "undef". Regarding guaranteed object delivery: I must say I find this design aim questionable. The whole point of these facilities (Boost.Optional and your dual_state) is that there are situations where it is simply not possible to assign a meaningful value to the object. It is only logical that this implies that wherever the object is used, there must either be some invariant in user code that guarantees that it is defined, or an if/else to deal with both cases. Quickly default constructing the underlying object when it turns out that the user is attempting to use it when it is not defined seems like a very arbitrary thing to do, and I believe it will only be sensible and correct in very few situations. This is the first reason why the notion of Boost.Optional being a model of OptionalPointee appeals to me. Regarding full operator support: I'm very skeptic about this design aim, mainly because it is an attempt at making the class as a whole a transparent wrapper around the underlying object, which is fundamentally not possible in C++ and will only cause confusion. Sure, the syntax is nice for a few cases, but conceptually it makes the interface complex and inconsistent. This is the second reason why the notion of Boost.Optional being a model of OptionalPointee appeals to me: the syntax and semantics are pretty much as one would expect (from a smart pointer). So, in conclusion, the motivation for your dual_state is very valid, but personally I think Boost.Optional is a more appropriate design. Eelis
Eelis van der Weegen <gmane@contacts.eelis.net> writes:
So, in conclusion, the motivation for your dual_state is very valid, but personally I think Boost.Optional is a more appropriate design.
IMO the "guaranteed object delivery" feature makes for a useful specialization of the Boost.Optional design. However, it would be nice to have both; it's not an alternative to Boost.Optional. There's a lot of resonance with the Boost.Parameter library in here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen
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
Jost, Andrew wrote: 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.
Oh, you're right! That is a terrible one-line description, because a. It uses technical terms that many people probably don't know "discriminated union" b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions. <snip>
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.
Interesting. Sounds like dual_state should be built on top of optional.
*FULL OPERATOR SUPPORT* A second difference is that dual_state directly supports the full complement of operators (for built-in types),
That sounds a bit like Alexander Nasonov's dynamic_any.
this due to the fact that most operators are delegated through the implicit conversion-to-base-type operator.
Oh, that's less interesting, but still useful. Expect a debate over whether the implicit conversion is a good idea, though.
*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.
Nice idea. It's good to have something like that available, at least. Asking whether it should be required makes it, as you say, a very personal issue. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Well, even despite I do understand what "discriminated union" is, it's more an implementation detail than a brief descripton of practical applications for the library. I found Boost.Optional very useful for myself. http://www.boost.org/libs/optional/doc/optional.html#inplace describes a usage scenario which has almost nothing to do with optionality. With boost::optional in-place construction facilities I can easily store non-Copyable or non-DefaultConstructible objects in STL containers and avoid extra construction, copy and dynamic memory allocation operations in many scenarios, even in those not related to containers. For example, I can return a fresh NonCopyable and NonDefaultConstructible object from a function without often expensive heap operations. I even had my own placeholder<> implementation. But I felt myself too weak to perform boost-style "all possible overloads", and lack of the safety prevented me from using that class widely. I wonder how many more pearls are still hidden deeply in Boost documentation. I'm going to contribute to the documentation (at least in Wiki due to my poor English) when I finish with Boost.Build. Andrey
On 7/11/05, Andrey Melnikov <melnikov@simplexsoft.com> wrote:
David Abrahams wrote:
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Well, even despite I do understand what "discriminated union" is, it's more an implementation detail than a brief descripton of practical applications for the library.
I found Boost.Optional very useful for myself.
http://www.boost.org/libs/optional/doc/optional.html#inplace describes a usage scenario which has almost nothing to do with optionality.
With boost::optional in-place construction facilities I can easily store non-Copyable or non-DefaultConstructible objects in STL containers and avoid extra construction, copy and dynamic memory allocation operations in many scenarios, even in those not related to containers. For example, I can return a fresh NonCopyable and NonDefaultConstructible object from a function without often expensive heap operations.
Isnt that the boost::ref goal? Or am I missing something?
I even had my own placeholder<> implementation. But I felt myself too weak to perform boost-style "all possible overloads", and lack of the safety prevented me from using that class widely.
I wonder how many more pearls are still hidden deeply in Boost documentation. I'm going to contribute to the documentation (at least in Wiki due to my poor English) when I finish with Boost.Build.
Andrey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Felipe Magno de Almeida <felipe.m.almeida@gmail.com> writes: <snip> a giant message
I can return a fresh NonCopyable and NonDefaultConstructible object from a function without often expensive heap operations.
Isnt that the boost::ref goal? Or am I missing something?
<snip> some more of the message http://www.boost.org/more/discussion_policy.htm#quoting -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Felipe Magno de Almeida <felipe.m.almeida@gmail.com> writes:
<snip> a giant message>
I can return a fresh NonCopyable and NonDefaultConstructible object from a function without often expensive heap operations.
Isnt that the boost::ref goal? Or am I missing something?
<snip> some more of the message
David, you are the man. Now I can answer this message! Well, I'm going to give rise to a new giant... Readers, please bother to crop it when replying. From Introduction section at http://www.boost.org/doc/html/ref.html I see that boost::ref I see that is isn't the boost::ref goal. Boost.Ref can save some CPU cycles only if I deal with hostile pieces of code such as std::foreach() which refuse to work with references. If I write all code myself, I don't need boost::ref. In complex cases type_traits can help me and compiler to handle references correctly. Consider the following rather typical scenarios when you return a std::string. These examples are a bit artificial, but in some circumstances default construction, dynamic memory and copying can be computationally too expensive or not available at all. The following versions are not ideal: std::string foo() { return "bar"; } ... std::string bar = foo(); -------- void foo( std::string & bar) { bar = "bar" ; } ... std::string bar; foo(bar); ---------- std::string * foo() { return new std::string("bar"); } ... std::auto_ptr<std::string> bar = foo(); ----------- Each of them includes some extra operations which aren't necessary. Version 1 is terrible, version 2 uses an extra default construction, version 3 uses an extra memory allocation. Here is a better version: void foo( std::string * bar ) { new (bar) std::string("bar"); } ... char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder); foo(bar); ... bar->~std::string(); It uses just one constructor call, no extra default constructors and no dynamic memory allocation. So far after reading the documentation, it seems to me that boost::optional provides a nice encapsuation for this bulk of code. void foo(boost::optional<std::string> & bar) { bar = boost::in_place("bar"); } ... boost::optional<std::string> bar; foo(bar); But unlike raw code, this approach also creates a copy of "bar" char* stored in a temporary factory object. Does boost::optional have a way to avoid these temporaries too? Does it have something like bar.in_place("bar); or in_place(bar, "bar"); ? Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Each of them includes some extra operations which aren't necessary. Version 1 is terrible, version 2 uses an extra default construction, version 3 uses an extra memory allocation.
Here is a better version:
void foo( std::string * bar ) { new (bar) std::string("bar"); } ... char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder);
reinterpret_cast is nonportable.
foo(bar); ... bar->~std::string();
It uses just one constructor call, no extra default constructors and no dynamic memory allocation. So far after reading the documentation, it seems to me that boost::optional provides a nice encapsuation for this bulk of code.
Or just an opportunity for premature optimization. On a compiler supporting RVO and other kinds of copy elision, the "terrible" version could be just as efficient, or more so. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder);
reinterpret_cast is nonportable.
Why? I don't see any reasons why reinterpert_cast from char [] to std::string * could be nonportable. The only thing I see is that it isn't supported by some compilers. Anyways, it was just an example. Don't judge me too strictly.
foo(bar); ... bar->~std::string();
It uses just one constructor call, no extra default constructors and no dynamic memory allocation. So far after reading the documentation, it seems to me that boost::optional provides a nice encapsuation for this bulk of code.
Or just an opportunity for premature optimization.
I don't think that "don't give opportunities for premature optimization" can be a design goal :) Don't think about this idea just as about an optimization trick. It doesn't require an object to have a default or a copy constructor. It do relax container requirements for stored types. It is useful *sometimes*. And why premature? I didn't recommend to use this code everywhere instead of returning values from functions. Did you miss a paragraph? :) I explicitly stated: ...*In some circumstances* default construction, dynamic memory and copying *can* be computationally too expensive or not available at all... Maybe I should have used "may" there. I definitely need to improve my English skills.
On a compiler supporting RVO and other kinds of copy elision, the "terrible" version could be just as efficient, or more so.
It could of course. But SOMETIMES it doesn't help. I can't imagine how a compiler can avoid calling a non-trivial copy constructor like in case of std::string. Don't forget that such a copy operation includes memory reallocation, which is much more expensive than just a memcpy() operation. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder);
reinterpret_cast is nonportable.
Why? I don't see any reasons why reinterpert_cast from char [] to std::string * could be nonportable.
The standard says so. It's implementation-defined. <snip>
I can't imagine how a compiler can avoid calling a non-trivial copy constructor like in case of std::string.
The standard says it can. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder);
reinterpret_cast is nonportable.
Why? I don't see any reasons why reinterpert_cast from char [] to std::string * could be nonportable.
The standard says so. It's implementation-defined.
I know that this is your favorite, but in my opinion, "implementation defined" doesn't equal "nonportable" in this particular case. (Alignment problems notwithstanding.)
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
char bar_placeholder[sizeof(std::string]; std::string *bar = reinterpret_cast<std::string*>(bar_placeholder);
reinterpret_cast is nonportable.
Why? I don't see any reasons why reinterpert_cast from char [] to std::string * could be nonportable.
The standard says so. It's implementation-defined.
I know that this is your favorite,
It's right up there with the greats ;-) I also claim that most people get the relative safeness of static_cast and const_cast backwards ;-)
but in my opinion, "implementation defined" doesn't equal "nonportable" in this particular case. (Alignment problems notwithstanding.)
There's "nonportable according to the standard" and "nonportable in practice." This one is only the former, it's true. But why write something that might turn out to be nonportable somewhere when we can do something that the standard guarantees? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
but in my opinion, "implementation defined" doesn't equal "nonportable" in this particular case. (Alignment problems notwithstanding.)
There's "nonportable according to the standard" and "nonportable in practice." This one is only the former, it's true. But why write something that might turn out to be nonportable somewhere when we can do something that the standard guarantees?
Because it's clearer, it (arguably) matches the intent of the standard (see 9.2/17), and because deducing that T* -> void* -> char* is guaranteed to work correctly is nontrivial. I suspect that 5.2.10 doesn't give semantics to T* -> char* only because "everyone knows" how this conversion is supposed to work. It's probably a defect.
Deane Yang <deane_yang@yahoo.com> writes:
David Abrahams wrote:
I also claim that most people get the relative safeness of static_cast and const_cast backwards ;-)
I'm biting on this one. Could you explain or provide a reference?
http://lists.boost.org/boost/2004/09/12651.php -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Deane Yang <deane_yang@yahoo.com> writes:
David Abrahams wrote:
I also claim that most people get the relative safeness of static_cast and const_cast backwards ;-)
I'm biting on this one. Could you explain or provide a reference?
I think my point was that when you use const_cast, people reading your code typically demand an explanation or just assume you're doing something fishy, whereas when you use static cast people typically just verify that the cast is correct and leave it at that. Maybe it shouldn't be that way -- I gather that's your point -- but it is. Jonathan
On 7/11/05, Andrey Melnikov <melnikov@simplexsoft.com> wrote:
David Abrahams wrote:
On a compiler supporting RVO and other kinds of copy elision, the "terrible" version could be just as efficient, or more so.
I can't imagine how a compiler can avoid calling a non-trivial copy constructor like in case of std::string. Don't forget that such a copy operation includes memory reallocation, which is much more expensive than just a memcpy() operation.
Modern compilers do. You can verify this with the attached test program that wraps std::string with "noisy" constructors, assignment op and destructor so you can see what is happening. With gcc 3.3.4 and no optimizations I get the following output: noisy_string::ctor: 0xfeffad90: forty-two noisy_string::dtor: 0xfeffad90: forty-two With MS VC++ 7.1 I get this output for any optimization levels I try: noisy_string::ctor: 0012FEA0: forty-two noisy_string::copy ctor: 0012FEC8: forty-two noisy_string::dtor: 0012FEA0: forty-two noisy_string::dtor: 0012FEC8: forty-two With MS VC++ 2005 Beta 2 I get the same output as above with no optimization, but at /O1 or /O2 I see NRVO kick in: noisy_string::ctor: 0012FF54: forty-two noisy_string::dtor: 0012FF54: forty-two With Sun C++ I get this: noisy_string::ctor: ffbee63c: forty-two noisy_string::copy ctor: ffbee6c0: forty-two noisy_string::dtor: ffbee63c: forty-two noisy_string::dtor: ffbee6c0: forty-two See what you get with your compiler. -- Caleb Epstein caleb dot epstein at gmail dot com
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> escribió en el mensaje news:a2b17b6050711023823971693@mail.gmail.com...
On 7/11/05, Andrey Melnikov <melnikov@simplexsoft.com> wrote:
David Abrahams wrote:
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Well, even despite I do understand what "discriminated union" is, it's more an implementation detail than a brief descripton of practical applications for the library.
I found Boost.Optional very useful for myself.
http://www.boost.org/libs/optional/doc/optional.html#inplace describes a usage scenario which has almost nothing to do with optionality.
With boost::optional in-place construction facilities I can easily store non-Copyable or non-DefaultConstructible objects in STL containers and avoid extra construction, copy and dynamic memory allocation operations in many scenarios, even in those not related to containers. For example, I can return a fresh NonCopyable and NonDefaultConstructible object from a function without often expensive heap operations.
Isnt that the boost::ref goal? Or am I missing something?
No it isn't... and becasue your're asking, is evident that the documentation for this is still inadequate. Fernando Cacciola SciSoft
Fernando Cacciola wrote:
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> escribiу en el mensaje news:a2b17b6050711023823971693@mail.gmail.com...
Isnt that the boost::ref goal? Or am I missing something?
No it isn't... and becasue your're asking, is evident that the documentation for this is still inadequate.
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find.
http://sourceforge.net/tracker/?group_id=7586 -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find.
Above in the thread you wrote:
Yeah, I wanted to use that, but the documentation seemed incomplete. I reported it (http://lists.boost.org/MailArchives/boost/msg71490.php)
You didn't reference a tracker item. This means that the tracker isn't always used and that it isn't very effective. It isn't referenced on the home page. A lot of people who know that such tracker exists on Sourrceforge won't use it because some SF projects doesn't use the tracker. If the tracker is actively used (and from SF page it seems so), it should be referenced in participation/contribution sections along with mail lists. A lot of people will prefer anonymous web form over the need to subscribe to a moderated mail list in order to report a bug or post a suggestion. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find.
Above in the thread you wrote:
Yeah, I wanted to use that, but the documentation seemed incomplete. I reported it (http://lists.boost.org/MailArchives/boost/msg71490.php)
You didn't reference a tracker item. This means that the tracker isn't always used and that it isn't very effective.
Agreed.
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
A lot of people who know that such tracker exists on Sourrceforge won't use it because some SF projects doesn't use the tracker.
I think mostly it doesn't get used because it's inconvenient for the bug reporter, and because the mailing list tends to work most of the time.
If the tracker is actively used (and from SF page it seems so), it should be referenced in participation/contribution sections along with mail lists.
Can you post suggested patches to the CVS version of the site?
A lot of people will prefer anonymous web form over the need to subscribe to a moderated mail list in order to report a bug or post a suggestion.
Well, that's a problem too. People often leave off their SF userid or other identifying information, so when we follow up to the tracker items we have no idea whether the reporter sees the reply. -- Dave Abrahams Boost Consulting www.boost-consulting.com
A lot of people will prefer anonymous web form over the need to subscribe to a moderated mail list in order to report a bug or post a suggestion.
Well, that's a problem too. People often leave off their SF userid or other identifying information, so when we follow up to the tracker items we have no idea whether the reporter sees the reply.
That to me is a big issue: I've closed several issues because the submitter was anonymous, and posted insufficient information to get even close to reproducing their problem, and requests for more information went unanswered. There was even a recent case of someone who posted the same query *four times* even though there had been a reply to the first query he posted. Presumably he expected the reply to reach him by magic :-O Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO. Throwing in my 2c worth yours, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
A lot of people will prefer anonymous web form over the need to subscribe to a moderated mail list in order to report a bug or post a suggestion.
Well, that's a problem too. People often leave off their SF userid or other identifying information, so when we follow up to the tracker items we have no idea whether the reporter sees the reply.
That to me is a big issue: I've closed several issues because the submitter was anonymous, and posted insufficient information to get even close to reproducing their problem, and requests for more information went unanswered. There was even a recent case of someone who posted the same query *four times* even though there had been a reply to the first query he posted. Presumably he expected the reply to reach him by magic :-O
Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO.
I don't think we can do that with the SF tracker, but there are better systems. For example, we could use BugZilla (same as the GCC tracker) ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO.
I don't think we can do that with the SF tracker, but there are better systems. For example, we could use BugZilla (same as the GCC tracker) ;-)
Of course "better" is a matter of debate... For example I would not consider BugZilla better than SF tracker, more functional maybe. But I would consider MantisBT better than both. -- -- 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
On 2005-07-13, Rene Rivera <grafik.list@redshift-software.com> wrote:
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO. I don't think we can do that with the SF tracker, but there are better systems. For example, we could use BugZilla (same as the GCC tracker) ;-) Of course "better" is a matter of debate... For example I would not consider BugZilla better than SF tracker, more functional maybe. But I would consider MantisBT better than both.
And having used BugZilla and MantisBT I would be inclined to agree. And from a configuration point of view, MantisBT is *trivial*. phil -- change name before "@" to "phil" for email
Phil Richards <news@derived-software.ltd.uk> writes:
On 2005-07-13, Rene Rivera <grafik.list@redshift-software.com> wrote:
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO. I don't think we can do that with the SF tracker, but there are better systems. For example, we could use BugZilla (same as the GCC tracker) ;-) Of course "better" is a matter of debate... For example I would not consider BugZilla better than SF tracker, more functional maybe. But I would consider MantisBT better than both.
And having used BugZilla and MantisBT I would be inclined to agree. And from a configuration point of view, MantisBT is *trivial*.
What, still no debate?! ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Phil Richards <news@derived-software.ltd.uk> writes:
On 2005-07-13, Rene Rivera <grafik.list@redshift-software.com> wrote:
David Abrahams wrote:
Of course "better" is a matter of debate... For example I would not consider BugZilla better than SF tracker, more functional maybe. But I would consider MantisBT better than both.
And having used BugZilla and MantisBT I would be inclined to agree. And from a configuration point of view, MantisBT is *trivial*.
What, still no debate?! ;-)
I've never used MantisBT before. But I dislike Bugzilla. Andrey
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Is it possible to insist that all posts to the tracker are from folks who are logged on? The gcc bug tracker does that and it works very well IMO.
I don't think we can do that with the SF tracker, but there are better systems. For example, we could use BugZilla (same as the GCC tracker) ;-)
Of course "better" is a matter of debate... For example I would not consider BugZilla better than SF tracker, more functional maybe. But I would consider MantisBT better than both.
I don't know enough about any of these things to say much; I'll take your word for it (so no debate from me)! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find.
<skipped>
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
Not in the left-hand column. That page is outdated. The new design has this link in the left-hand column, and it's even less prominent than on the previous design. At least I failed to find it when I explicitly searched for it and I knew what I was looking for. But now I looked again and found it.
A lot of people who know that such a tracker exists on Sourceforge won't use it because some SF projects doesn't use the tracker.
I think mostly it doesn't get used because it's inconvenient for the bug reporter,
The only way to avoid such inconveniences is to start Boost.Tracker project :) From my practice no existing trackers are good enough to be called "universal". Some like Rational ClearQuest are extremely customizable, but customization takes ages and such guns are too big and sometimes are too expensive too.
and because the mailing list tends to work most of the time.
The volume of the mailing list is much larger than the number of items on TODO list. We cannot easily calculate how many issues we forgot to fix. For example, why recent discussion about Getting Started guide isn't integrated into CVS? http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/more/getting_st... is an old one.
If the tracker is actively used (and from SF page it seems so), it should be referenced in participation/contribution sections along with mail lists.
Can you post suggested patches to the CVS version of the site?
I'll try. First, I'd like to express bad things in Participation section. 1. We don't need the first paragraph:
Although Boost was begun by members of the C++ Standards Committee Library Working Group, participation has expanded to include thousands of programmers from the C++ community at large.
This is "Background" information. (I dislike the "Background" header on the page though) It doesn't help people wanting to contribute to get involved, and doesn't help Boost to involve more potential contributors. 2. Participation section should tell people *why* they should participate, *how* they can help Boost, *how easy for them* and *how useful for them* their participation can be. Just like all free software projects, Boost doesn't pay salaries to its developers. And most competent commercial developers will refuse to participate actively in writing free code. On the other hand, getting a lot of real-life feedback is essential for Boost to be a successful project. People can contribute without a need to write actual code. They can help Boost to be better by providing arguments other people missed, by pointing to weak places in the design, by suggesting the changes they'd like to get. Many people can actually benefit just reading the discussions. Most discussion end with highly grounded and highly practically useful "best practice" statements. I'd like to have a more informative and motivating description there in Participation chapter. Current information can be placed on a separate page. I'll try to create my version tomorrow. Personally, I fear joining "developer mailing lists". I don't like to read discussions of diffs in code I don't understand and don't use. In my spare time I don't like to get CVS access, get assigned to some tasks, and check in changes. I use Boost so called "developer" mailing list for the reasons I didn't realized when I subscribed to it. Pure "development" part, at least in this pre-release period, is about regressions for specific compilers, and I ignore such threads. But I do read threads like "MS compiler detection" and "Defining compiler suggestions" because I can use that information in my daily work. The amount of fresh ideas and reusable idioms is impressive. The original reasons were to get performance issues in Date_Time and lexical_cast fixed so I won't have to apply my own patches every time I migrate to a new version. Now I use it because the list is a pretty good advanced C++ community. The discussions are really *highly* technical. No simple "which API call to use" or "help me with my college assignment" questions. No flames. I really learn "best practices", I learn more high end C++ every day by reading questions and answers and actively participating in non-trivial discussions. Also I learn more about Boost and its libraries, including very important practical applications. The list is much better than just a documentation, and the list is an extremely useful component of the project. My propositions don't get rejected because I don't want to implement them myself, they don't get rejected without a high motivation, without *highly technical* reasons. I always get a competent answer and if I don't agree, I can continue arguing until all my arguments are over, or until my opinion is accepted. No people have hard-coded stereotypes, no pattern thinking, no argumentation based just on "trustworthy" opinions. Of course I wouldn't publish such a complimentary ad on the website, but current description is non-informative, misleading and scary. Andrey
David Abrahams writes:
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
I disagree. The fact that they are sent to the list doesn't mean that the submitter follows the list, which in its turn means that if you want to make sure that they see your reply, you and anybody else who might have something to say should reply on the tracker itself, which is a pain and greatly reduces chances of the submitter getting a reply, in particular because people who are not library maintainers but are on the list and might have something to say most definitely won't go to the tracker to do that. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
David Abrahams writes:
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
I disagree. The fact that they are sent to the list doesn't mean that the submitter follows the list, which in its turn means that if you want to make sure that they see your reply, you and anybody else who might have something to say should reply on the tracker itself, which is a pain and greatly reduces chances of the submitter getting a reply, in particular because people who are not library maintainers but are on the list and might have something to say most definitely won't go to the tracker to do that.
This means that SF tracker doesn't work. People on the list don't read tracker, and people submitting to the tracker don't read the list. We could use the tracker only internally and tell people to post their problems to the list. However with this approach we lose the ease of (anonymous) web forms and replace it with a need to subscribe to the list in order to get a reply. Sending bugs and asking questions should be easy for users. Many people even don't know what mail lists are. And asking them to subscribe to a high-volume list just in order to get a pair of replies is a bad idea. One possible solution is to write a mail bot which will track threads initiated from tracker and post replies from the list back to the tracker. Or we could ask people to write to community-support@boost.org. Their messages will be forwarded to the list, and they will get replies only from the thread they initiated. But these are rather complex things to implement. Are there any systems that will help us out of the box? Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Aleksey Gurtovoy wrote:
David Abrahams writes:
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
I disagree. The fact that they are sent to the list doesn't mean that the submitter follows the list, which in its turn means that if you want to make sure that they see your reply, you and anybody else who might have something to say should reply on the tracker itself, which is a pain and greatly reduces chances of the submitter getting a reply, in particular because people who are not library maintainers but are on the list and might have something to say most definitely won't go to the tracker to do that.
This means that SF tracker doesn't work. People on the list don't read tracker,
That part is false, because all tracker changes go to the list.
and people submitting to the tracker don't read the list.
That part is true.
We could use the tracker only internally and tell people to post their problems to the list.
However with this approach we lose the ease of (anonymous) web forms and replace it with a need to subscribe to the list in order to get a reply.
Sending bugs and asking questions should be easy for users. Many people even don't know what mail lists are. And asking them to subscribe to a high-volume list just in order to get a pair of replies is a bad idea.
One possible solution is to write a mail bot which will track threads initiated from tracker and post replies from the list back to the tracker.
That could work. I think other systems work that way, like GCC's bugzilla system.
Or we could ask people to write to community-support@boost.org. Their messages will be forwarded to the list, and they will get replies only from the thread they initiated.
But these are rather complex things to implement. Are there any systems that will help us out of the box?
See above? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
This means that SF tracker doesn't work. People on the list don't read tracker,
That part is false, because all tracker changes go to the list.
and people submitting to the tracker don't read the list.
That part is true.
Maybe my wording confused you. If we disable this forwarding, people on the list won't go to the tracker every day to read the updates, just like people who use tracker don't always subscribe to the list now.
We could use the tracker only internally and tell people to post their problems to the list.
However with this approach we lose the ease of (anonymous) web forms and replace it with a need to subscribe to the list in order to get a reply.
Sending bugs and asking questions should be easy for users. Many people even don't know what mail lists are. And asking them to subscribe to a high-volume list just in order to get a pair of replies is a bad idea.
One possible solution is to write a mail bot which will track threads initiated from tracker and post replies from the list back to the tracker.
That could work. I think other systems work that way, like GCC's bugzilla system.
For me it was scary to use bugzilla's mail bot system. So I submitted everything using a web interface. I think bugzilla's requirements for mail formatting are too strict. At least it seemed to me so when I was using Bugzilla in my project.
Or we could ask people to write to community-support@boost.org. Their messages will be forwarded to the list, and they will get replies only from the thread they initiated.
But these are rather complex things to implement. Are there any systems that will help us out of the box?
See above?
Bugzilla isn't the simplest thing to work with. Its forms have a lot of fields we won't need, and don't have fields we will need. It will be hard to scale it up or down. When I say "scale down" I mean creation of a lightweight form most users expect. Users don't like to classify their problem using 8 or even more criterias Bugzilla proposes out of the box. I'm not sure that Bugzilla is the best place to start from. Its not very modular Perl spaghetti code scares me. Andrey
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
It isn't referenced on the home page.
Sure it is. "Request Support" in the left-hand column. It probably could be more prominent, and more routes to the tracker should be better emphasized, e.g. through the "Report Bugs" and "Suggest Features" links. Those two pages tend to discourage using the tracker, but now that tracker entries get automatically sent to the lists, I'd say we should explicitly encourage it and discourage sending these reports to the lists.
I disagree. The fact that they are sent to the list doesn't mean that the submitter follows the list, which in its turn means that if you want to make sure that they see your reply, you and anybody else who might have something to say should reply on the tracker itself,
Right.
which is a pain
Only a slight one. You get a link to click through. It's much less painful than what the submitter had to go through to set up the tracker item initially.
and greatly reduces chances of the submitter getting a reply, in particular because people who are not library maintainers but are on the list and might have something to say most definitely won't go to the tracker to do that.
Well, there's always the chance of changing the culture to encourage people to do so. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 7/11/05, Fernando Cacciola <fernando_cacciola@hotmail.com> wrote:
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> escribió en el
Isnt that the boost::ref goal? Or am I missing something?
No it isn't... and becasue your're asking, is evident that the documentation for this is still inadequate.
Its goal is to be used in template functions where a functor was supposed to be used, where copy construction in the functor is to be avoided(like algorithms with expensive copy constructors functors)? So, the boost::reference_wrapper wasnt suppose to be used in client code is it? Could you shed me some light?
Fernando Cacciola SciSoft
Thanks in advance, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Felipe Magno de Almeida <felipe.m.almeida@gmail.com> writes:
On 7/11/05, Fernando Cacciola <fernando_cacciola@hotmail.com> wrote:
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> escribió en el
Isnt that the boost::ref goal? Or am I missing something?
No it isn't... and becasue your're asking, is evident that the documentation for this is still inadequate.
Its goal is to be used in template functions where a functor was supposed to be used,
ref() has nothing to do with functors per se. s/functor/value// -- Dave Abrahams Boost Consulting www.boost-consulting.com
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Well, even despite I do understand what "discriminated union" is, it's more an implementation detail than a brief descripton of practical applications for the library.
I found Boost.Optional very useful for myself.
http://www.boost.org/libs/optional/doc/optional.html#inplace describes a usage scenario which has almost nothing to do with optionality.
Yeah, I wanted to use that, but the documentation seemed incomplete. I reported it (http://lists.boost.org/MailArchives/boost/msg71490.php) but it's not clear that the docs have been updated since then. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uy88d7b00.fsf@boost-consulting.com...
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
[SNIP]
I found Boost.Optional very useful for myself.
http://www.boost.org/libs/optional/doc/optional.html#inplace describes a usage scenario which has almost nothing to do with optionality.
Yeah, I wanted to use that, but the documentation seemed incomplete. I reported it (http://lists.boost.org/MailArchives/boost/msg71490.php) but it's not clear that the docs have been updated since then.
You're right, I haven't updated the documentation in this point. I'll try my best to work on it as soon as possible. Fernando Cacciola SciSoft
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uoe9abw3k.fsf@boost-consulting.com...
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen
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
Jost, Andrew wrote: 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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Very good point. Right now I can think of "A library to wrap and manipulate values can be be 'optional': that is, (explicitely) uninitialized" but that doesn't sound very inspired. Any proposals? Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uoe9abw3k.fsf@boost-consulting.com...
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen
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
Jost, Andrew wrote: 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.
Oh, you're right! That is a terrible one-line description, because
a. It uses technical terms that many people probably don't know "discriminated union"
b. optional doesn't really act like a union (in any way that matches my intuition)! I understand the theoretical connection, of course, but nobody is thinking that way when they read brief descriptions.
Very good point. Right now I can think of
"A library to wrap and manipulate values can be be 'optional': that is, (explicitely) uninitialized"
but that doesn't sound very inspired.
Any proposals?
A container that uses no dynamic memory and holds at most one element: optional<T> can hold any value of T or none at all. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: "Fernando Cacciola" <fernando_cacciola@hotmail.com>
"A library to wrap and manipulate values can be be 'optional': that is, (explicitely) uninitialized"
How's this? A library creating value wrappers that may have a value or be left uninitialized. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
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) 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) Parametrizing 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. Another thing to consider is were exactly do default values appear; and how are the semantics defined in this case.
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. re 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.
The problem I see in your design is that the "benefit" of having a default optional value can only exist at the consumption point (becasue the code producing an uninitialized optional does not have a default value, otherwise it wouldn't be uninitialized); But *there*, what is a meaningful default value and whether is important for the design to be explicit about the fact that the value being consumed is not the one produced is a local problem. An optional<>/dual_state<> is an object constructed by a producer that does not know what a good default is (if it knew, if wouldn't construct uninitialized values), so is unclear how could the class/instance by itself could provide such local information (the default value beneficial at the consumtion point). As David Abraham mentioned, optional<> instances are similar to default parameters, and notice how there the default value is specified at the consumtion point, not the production point. IOWs, the following: void foo ( int age = -1 ) ; foo(35); foo(); reads: The function foo() uses an age, but if you don't have one, don't worry, just don't specify it. foo() will take care itself of a reasonable default value. Now the analogy for optional<> would go something like this: optional<int> get_age(); optional<int> age = get_age(); *** do something with age here ** IMO, get_age() cannot and would not return any default value, if it could, then it should have a return type of just 'int'; or at most, return an initialized value. So it is up to the consumer code to deal with the possible empty age. But how? That really depens on the consumer code. I can choose to deal only with real ages, so my code would start like: if ( age ) Or I might decide that -1, or perhaps 0, are good fallback values... But in any event, these decisions are local to the consumer code, so I can't picture how to encode such decisions in optional<> itself. Well, others have already commented on the rest of your post so I won't repeat that here :-) Best regards, Fernando Cacciola SciSoft
participants (15)
-
Aleksey Gurtovoy -
Andrey Melnikov -
Caleb Epstein -
David Abrahams -
Deane Yang -
Eelis van der Weegen -
Felipe Magno de Almeida -
Fernando Cacciola -
John Maddock -
Jonathan Turkanis -
Jost, Andrew -
Peter Dimov -
Phil Richards -
Rene Rivera -
Rob Stewart