Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor

--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote: [snip] For this reason, and for the fact that I have some upcoming deadlines at work, I'll summarize what I see and where I stand now, then I'll step back a bit for a while. I hope you come back later

Re: [boost] optional/type_with_alignment.hpp vs. metrowerks8.3 PPC CFM

--On Tuesday, September 02, 2003 3:32 PM -0400 Douglas Paul Gregor <[EMAIL PROTECTED]> wrote: On Tue, 2 Sep 2003, Mat Marcus wrote: --On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor <[EMAIL PROTECTED]> wrote: > I suspect they are both '4', but that leaves m

Re: [boost] optional/type_with_alignment.hpp vs. metrowerks8.3 PPC CFM

--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor <[EMAIL PROTECTED]> wrote: On Tuesday 02 September 2003 01:36 pm, Mat Marcus wrote: We're trying to use optional from 1.30.0 (sorry legal hasn't approved our use of 1.30.2 yet). However on one compiler (Metrowerks 8.

[boost] optional/type_with_alignment.hpp vs. metrowerks 8.3 PPC CFM

We're trying to use optional from 1.30.0 (sorry legal hasn't approved our use of 1.30.2 yet). However on one compiler (Metrowerks 8.3 PPC CFM) we're getting static asserts from the alignment calculation metafunctions. Below is an abstracted example of the problem. I'm curious about what's going

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: [snip] As a final aside, I think much of this thread is degenerating into Parkinson's Bicycle Shed[*], with respect to "is it a pointer/container/X?" At this point, I think we know what set of methods should

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote: Joel de Guzman <[EMAIL PROTECTED]> wrote in message One can think of an optional as conceptually a specialized but nevertheless, *IS-A* T, with the added specialization that it can be in a dead-uninitial

Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

--On Monday, September 01, 2003 2:57 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote: Mat Marcus <[EMAIL PROTECTED]> wrote in message [snip] After reading the documentation more carefully I learned that optional models pointer behavior. I spelled out how the code might look:

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Sunday, August 31, 2003 9:56 PM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: As for the use-case with the function returning a pair of iterators that we'd like to assign to optionals via a tie(), I think there should also be a different method in the interface which returns the "hole" i

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: So I completely disagree that optionals should mix the interfaces of optional and the wrapped object into one. I think there should be an explicit unwrapping operation. But this is just my opinion, based on n

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote: In this post I will put forward a use-case or two to help see whether something a little different then the current version of optional mi

Re: [boost] Re: Optional, tie, and iterator_adaptor

In this post I will put forward a use-case or two to help see whether something a little different then the current version of optional might be useful. I also begin making a case that a Concept like PossiblyUninitializedVariable might be more generally useful than OptionalPointee. As I mentioned i

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Friday, August 29, 2003 4:02 PM -0400 David Abrahams <[EMAIL PROTECTED]> wrote: Mat Marcus <[EMAIL PROTECTED]> writes: Well, that's a slightly different issue and you may be right. On the other hand, you can always define a type which implements those implicit const

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Friday, August 29, 2003 2:56 PM -0400 David Abrahams <[EMAIL PROTECTED]> wrote: Mat Marcus <[EMAIL PROTECTED]> writes: ### Question 2 In another case I am trying to use optional with iterator_adaptor (1.30.x version). Whoa; don't do that ;-> It'll hurt (compar

[boost] Optional, tie, and iterator_adaptor

I'm finally getting around to playing with optional. A couple of questions. ### Question 1 One of the projects that I am working on makes heavy use of tuples/pairs and as a result tie. It appears that some of the code may be improved by the use of optional. It is not clear to me whether I can

Re: [boost] [bind] result type deduction/access?

It is not uncommon to use boost::function to hold on to the result of boost::bind. Will that work for you? - Mat --On Tuesday, August 26, 2003 4:17 PM +0200 Daniel Frey <[EMAIL PROTECTED]> wrote: In my current project, there are a lot of code fragments that read like this: result->insert( "pos

Re: [boost] Re: Deadline for the Standard Library TechnicalReport

--On Thursday, January 30, 2003 7:45 PM +0100 Gennaro Prota <[EMAIL PROTECTED]> wrote: But where is the true proposal? I just know this: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1406. pdf which seems rather a magazine article to me. The template typedef is being semi-formally

Re: [boost] Re: MPL lambda

Scatter hierarchies can be achieved by using inherit_linearly together with mpl::inherit. See the second example that Aleksey cited *is* an example of a scatter hierarchy.