comp.std.c++ Google Group

Re: Semantics of some std::atomic member functions

2009-11-08T00:05:27Z

Oops, that was a typo. I meant paragraph 26 (which is what I quoted
above), but yes everything from 22 onwards is relevant.
Anthony

Re: Why there are both complex::real and std::real?

2009-11-07T05:39:49Z

I was aware of this case, but was under the impression that overloads for
user defined types were also permitted. The underlying logic being the same.
I suppose that would not be needed if all functions where adding an overload
for a user defined type could be useful are actually function templates, so

Re: Lambda captures in N2960

2009-11-06T20:56:17Z

On Nov 6, 7:55 pm, Ville Voutilainen <ville.voutilai...@gmail.com>
wrote:
Sorry to reply to myself, but Daveed Vandevoorde helpfully pointed out
that if a closure class contains reference members, the assignment
becomes
difficult to do correctly in all cases. That's the reason why lambdas
can be copy-constructed but not copy-assigned.

Re: Plauger resigned as convener?

2009-11-06T20:55:48Z

You're missing the point. With a properly set up system,
the discussions would happen continually on line.

Re: Semantics of some std::atomic member functions

2009-11-06T20:43:39Z

Okay, I see it now. Silly me, searching for "|=" in an attempt to
find a description of semantics for operator|=.
For the record, my copy of N2960 has this information in paragraphs
22ff, not paragraph 6.
Scott

Re: Lambda captures in N2960

2009-11-06T17:57:01Z

That is correct AFAIK. It would be beneficial to see whether that is a
problem,
we corrected the reach of lambda in order to be able to port
functional code
from other languages to c++, so if there are cases (or existing
algorithms)
where modification of copies in a lambda is necessary, we may want to

Re: Plauger resigned as convener?

2009-11-06T17:51:30Z

Good idea in theory, but the risk is that the practice of typing all
of the discussions into a forum takes longer to do than any benefit
gained from having every thought public. It's much quicker for those
involved to have a group discussion in person than it is to type out
long essays to each other.

Re: Lambda captures in N2960

2009-11-06T17:55:21Z

Other parts of that are correct, but the assignment is not.
[expr.prim.lambda]/p18
states that
"The closure type associated with a lambda-expression has a deleted
default constructor and a deleted copy
assignment operator."
The copy assignment is deleted so you can't assign lambdas. You can
copy construct them, though.

Re: Plauger resigned as convener?

2009-11-05T23:26:59Z

Discussions. You can get some feel for what's going on by
looking at the mailings, e.g.,
<[link]>,
but look at this in a paper by Stroustrup and Crowl:
<[link]>
Paper N2904 examined the generation of default copy

Re: Lambda captures in N2960

2009-11-05T23:27:23Z

Thank you, that's very helpful. I am sure people appreciate that
feedback.
You can do capture-by-reference for objects stored on the free store.
You can also
capture-by-value smart pointers. There are ways to do closures that do
not become
"toast". Capturing objects by value makes it easy to capture snapshots

Re: Brace initializers and template type deduction

2009-11-05T22:28:23Z

Agreed.
<snip and rearrange>
Yes - but it is not clear to me what portion of the standard
prescribes gcc
4.4's behavior here in allowing that template constructor to work.
I thought that the following code would not work with list-
initialization per
the standard (my variadic syntax might be a little off):

Re: Virtual function call for an object under construction

2009-11-05T22:28:46Z

I think, the presence of two interpretations of "most derived type"
and two interpretations of "most derived object" makes the rules
inconsistent. For example,
"the function called is the one defined in the constructor or
destructor's own class or in one of its bases, but not a function
overriding it in a class derived from the constructor or destructor's

Re: Lambda captures in N2960

2009-11-05T22:27:36Z

There is an important reason for this: the reference_closure type
basically requires lambdas that capture everything by reference to be
implemented as a pair of a function pointer and a scope pointer*. So
there is no data member corresponding to x above. There's a data
member pointing to the start of the stack frame of the invocation of

Re: Virtual function call for an object under construction

2009-11-05T22:27:18Z

Seems, I missed something important. Second try:
* When a virtual function specified by unqualified-id is called for an
object under construction _or destruction_ and the call occurs during
execution of:
-- body of the object's constructor
-- initialization of the object's non-static data member
-- body of the object's destructor

Re: Lambda captures in N2960

2009-11-05T22:28:04Z

These C++ closures are a joke anyway; they are not first class.
That's false. They can be assigned, stored, composed, and called
repeatedly.
In Lisp speak, we would say they are ``downward funargs only''.
That's fine, and is exactly what one expects of C++.
C++ isn't trying to be Lisp, and there is no chance