"Augustus Saunders" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Fernando Cacciola wrote: > > >And pointers have historically been used to deal with optional > >objects precisely because they model this concept. > > I think this is important, and so I want to dwell on it for a moment. > For many years, if a programmer needed optional functionality, she > used a pointer. There are a large number of existing libraries and > APIs that use pointers to convey exactly this notion. A pointer is > essentially a defacto standard for this usage. > > Consider one more time, why do iterators look like pointers? I > wouldn't be surprised if a similar discussion took place back in the > day: > > A: "I've got it! Make iterators look like pointers!" > B: "Hmm... That might confuse people. They aren't really pointers." > A: "You're right, some operators won't work on iterators." > C: "On the other hand, it would be convenient." > A: "Exactly! " > A,B,C: (thinks real hard) > C: "Also, if we make iterators look like pointers, then we can write > generic code that takes either. That way, we can interface to legacy > systems with generic code." > > Eventually, they come up with concepts, which at the time I'm sure > was a radical idea. If there weren't already a large number of > libraries that use this idiom, then generic code wouldn't really > benefit. > > Yes, this generic code is hypothetical right now. Since the > OptionalValue concept has not been defined, nobody has tried to use > it. If we do define it and release it into the wild, will it lead to > better libraries? Consider your OS of choice's system APIs. How > many functions take or return pointers for this purpose? > > Please do not dismiss the pointer interface until you have considered > this. And remember that if you push hard enough, you will discover > that smart pointers and iterators aren't really pointers. The > equivalence doesn't need to be absolute; just *useful* and *safe*. > I couldn't agree more. In fact, I think the OptionalValue concept has been implicitly defined for decades and this is why I prefer the pointer-like interface even if it requires the poisoned relops.
I realize now that part of the confusion was introduced by the poor documentation which didn't set the concepts straight. (which of course was a direct reflex of my poor understanding of the issues) Thanks to the clear arguments made by the reviewers, I see the picture a lot more clear now. Specially the fact that optional<> is itself a container, or perhaps, a union of T and nil_t. But your previous post were you developed those concepts were very helpful as an argument to keep the pointer-like interface. I have a deeper understanding of the issues involved now and I'm deeply reworking the documentation. Of course, I will formally present the OptionalValue concept on the documentation, and you will be credited for that :-) -- Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
