Re: [boost] New Library Proposal: dual_state
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart Sent: Thursday, July 14, 2005 9:53 PM To: boost@lists.boost.org Cc: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
Here is a real example. Imagine a researcher with many instruments
Okay. This works, but what about that ugly call to loadPoint? The problem is that the library function is expecting a signal value, not a Boost.Optional! Boost.Optional helped us manage data collection, but does not help us call trend::loadPoint. Let's look at
The library can just as easily expect a Boost.Optional.
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life.
If you can change the library to use an adaptor for an optional, why can't you change the library to use the optional directly?
But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects.
Using adapters, the call to trend::loadPoint in the first example might look like this:
// -- begin // call trend::loadPoint opt_dp::adapter f(-1); for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( f(*p) ); } // -- end
Your version, with Boost.Optional was like this:
for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( *p ? p->get() : -1 ); }
(I think you could change "p->get()" to "**p" if you like, BTW.)
The latter is simpler and seems far more direct and, therefore, readable. I don't see that your adapter has added any value.
I tried to make the examples as syntactically plain as possile; they are optimized for clarity. There is a key advantage in the example with adapters because the adapter is a function object. In that respect, the door has been flung open to many templated constructs that are more difficlt with the ?: operator. For example, a boost::transform_iterator could be created with the adapter to automatically access the underlying objects in a sequence.
Hmmm. This reminds me of using the STL algorithms before having Boost.Lambda, Boost.Bind, etc. Without a library of predefined function objects that perform useful, reusable adaptations, or a lambda approach to creating the adapters, one winds up separating the value extraction logic from the context in which it is used.
The Boost.Optional::adapter syntax is its own predefined library and, though lambda is a fantastic approach, it won't compile using Microsoft so we can't say it's the new paradigm.
I don't really see the value as presented thus far. There is a tiny amount of syntactic sugar, but is that warranted?
I'm not sure.
It was your idea, and now you're questioning it? I take from that the responses you've gotten have caused you to rethink not just the approach, but the idea?
Not at all. I would distrust anyone who has total faith in the usefulness of a new idea such as this one. The need for another opinion is why forums such as this one even exist.
Your requirements are flawed. The adapter should hold an instance of type T as provided by the constructor. Then, if the Boost.Optional has no value, the adapter can return it's default instance. IOW, the adapter shouldn't impose its needs on the optional type. Boost.Optional would then work fine, though I still question the value of your adapter.
I would also like to see the adapter avoid "imposing its needs" on the optional object, but conversely, I don't think it would be right to to return whole T objects (instead of references).
There's no need. As I pointed out, the adapter can hold its own T instance which represents the default. Then, when asked for a value (returned by reference), the adapter queries the optional. If the optional has a value, the adapter returns the optional's value. If not, the adapter returns the default value it holds.
I considered that approach. It could be used to return only const references, which may or may not be enough. -Andy
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? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Jost, Andrew wrote:
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?
Some people still write commercial code with VC6 due to various reasons. I'm happy that I don't have to, but sometimes people are bound to legacy code too tight. Andrey
Andrey Melnikov wrote:
Joel de Guzman wrote:
Jost, Andrew wrote:
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?
Some people still write commercial code with VC6 due to various reasons. I'm happy that I don't have to, but sometimes people are bound to legacy code too tight.
Fair enough. I just want it to be clear that you can't declare that lambda "won't compile using Microsoft". It can and it will. VC6 is ancient. I dare say that legacy code that still requires that clunky vintage compiler can be regarded as "old paradigm". The "new paradigm" is about moving forward to the future and not being locked to the past. When was VC6 released? 1998? 1999? Man! Let's move on! That's more than half a decade ago! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Why do you quote incorrect messages? Is this a bug in your mail program? It's really hard to get used to the way you break message threading. Andrey Jost, Andrew wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart Sent: Thursday, July 14, 2005 9:53 PM To: boost@lists.boost.org Cc: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
I considered that approach. It could be used to return only const references, which may or may not be enough.
-Andy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrey Melnikov wrote:
Why do you quote incorrect messages? Is this a bug in your mail program? It's really hard to get used to the way you break message threading.
I can't answer for Andrew here but Outlook Express does has a bug and sometimes quotes are TERRIBLY wrong. I use OE-QuoteFix: http://home.in.tum.de/~jain/software/oe-quotefix/ Fernando Cacciola SciSoft
Fernando Cacciola wrote:
Andrey Melnikov wrote:
Why do you quote incorrect messages? Is this a bug in your mail program? It's really hard to get used to the way you break message threading.
I can't answer for Andrew here but Outlook Express does has a bug and sometimes quotes are TERRIBLY wrong.
I use OE-QuoteFix:
If such a fix exists I think we should put it on Discussion Policy page. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Fernando Cacciola wrote:
Andrey Melnikov wrote:
Why do you quote incorrect messages? Is this a bug in your mail program? It's really hard to get used to the way you break message threading.
I can't answer for Andrew here but Outlook Express does has a bug and sometimes quotes are TERRIBLY wrong.
I use OE-QuoteFix:
If such a fix exists I think we should put it on Discussion Policy page.
Done. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
The library can just as easily expect a Boost.Optional.
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life.
If you can change the library to use an adaptor for an optional, why can't you change the library to use the optional directly?
But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects.
Huh? Your first example showed code using Boost.Optional and the conditional operator. Then you changed it to use an adapter. What unchangeable library code can use an adapter that couldn't have used Boost.Optional in the first place? That is, the library code would have been written to take a value initially. To account for the optional/default behavior, the library must change to take an adapter or a boost::optional. Since your adapter doesn't have value semantics, but rather function call semantics, a library written to expect a value cannot work *without change* with an adapter. What have I missed?
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.
Huh? What is "Boost.Optional::adapter syntax?" By "Microsoft," I assume you mean MSVC. Since BLL was only one of the libraries I mentioned, I have to ask: what's your point?
I don't really see the value as presented thus far. There is a tiny amount of syntactic sugar, but is that warranted?
I'm not sure.
It was your idea, and now you're questioning it? I take from that the responses you've gotten have caused you to rethink not just the approach, but the idea?
Not at all. I would distrust anyone who has total faith in the usefulness of a new idea such as this one. The need for another opinion is why forums such as this one even exist.
If you're unsure of the idea, though, we can't move forward.
I would also like to see the adapter avoid "imposing its needs" on the optional object, but conversely, I don't think it would be right to to return whole T objects (instead of references).
There's no need. As I pointed out, the adapter can hold its own T instance which represents the default. Then, when asked for a value (returned by reference), the adapter queries the optional. If the optional has a value, the adapter returns the optional's value. If not, the adapter returns the default value it holds.
I considered that approach. It could be used to return only const references, which may or may not be enough.
Are you considering the possibility that the value returned by the adapter could be a reference to non-const? I wasn't thinking of that at all. I saw it purely as getting a value. In fact, I thought your use case was simply that the value needed might not be available, so a substitute can be provided. Indeed, returning a non-const reference to T would mean that one should use a copy of the original optional because one might need different defaults for different uses of that optional. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
>From: boost-bounces@lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando >Cacciola
The library can just as easily expect a Boost.Optional.
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life.
If you can change the library to use an adaptor for an optional, why can't you change the library to use the optional directly?
But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects.
Huh? Your first example showed code using Boost.Optional and the conditional operator. Then you changed it to use an adapter.
What unchangeable library code can use an adapter that couldn't have used Boost.Optional in the first place? That is, the library code would have been written to take a value initially. To account for the optional/default behavior, the library must change to take an adapter or a boost::optional.
Since your adapter doesn't have value semantics, but rather function call semantics, a library written to expect a value cannot work *without change* with an adapter.
What have I missed?
The unchangeable library code is tr object and its loadPoint() method in particular. Adapter is outside the library, not inside it. The example doesn't contain library code at all. The code that cannot be changed is loadPoint() method itself. The example is just a glue between 2 libraries - boost::optional and tr. Andrey
participants (6)
-
Andrey Melnikov -
David Abrahams -
Fernando Cacciola -
Joel de Guzman -
Jost, Andrew -
Rob Stewart