Can somebody summarize other noteworthy results from the Frankfurt
meeting (beyond the removal of concepts)?  I'm particularly interested
in:
- Did async get adopted?
- Were any changes made to the variadic thread constructor?
- What changes were made to lambdas?  Do they now support move capture?
- Has the issue regarding the destructor timing of thread-locals been resolved?

Thanks,

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote
> Can somebody summarize other noteworthy results from the Frankfurt
> meeting (beyond the removal of concepts)?  I'm particularly
> interested in:

> Did async get adopted?

Not yet, but there's certainly progress. Lawrence Crowl and Herb Sutter are
asked to get together and write a new proposal.

> Were any changes made to the variadic thread constructor?

Not yet. The LWG has been discussing #929. ("Thread constructor"). But
before continuing, the question was raised whether this particular overload
is really needed, as it seems redundant. People could use the explicit
constructor, thread::thread(F), instead. Howard Hinnant will open an issue,
proposing to remove the variadic thread constructor.

> What changes were made to lambdas?  Do they now support move capture?

I wasn't in the room when those issues were discussed.

> Has the issue regarding the destructor timing of thread-locals been
> resolved?

Disussed by both Lawrence and Herb. Not yet resolved, IIRC.

BTW, the proposal that I wrote together with Daniel Kruegler was considered
interesting, but eventually got rejected: "Ref-qualifiers for assignment
operators of the Standard Library"
www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html  Reasons for its
rejection include: it would (likely) break backward compatibility of the ABI
of the std library, and it would break user source code. (There were
objections against breaking user code, even in cases when doing so seemed
right to me.)


Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers <usenet@aristeia.com> writes:

> Can somebody summarize other noteworthy results from the Frankfurt
> meeting (beyond the removal of concepts)?  I'm particularly interested
> in:
> - Did async get adopted?

Not yet. Discussion was postponed until Santa Cruz.

> - Were any changes made to the variadic thread constructor?

There was no consensus. There is now an explicit issue for it:

http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1176

> - What changes were made to lambdas?  Do they now support move
> capture?

Lambdas have not been changed to support move capture. The lambda
changes address the following issues:

680: What is a move constructor?
720: Need examples of lambda-expressions
732: Late-speci   ed return types in function de   nitions
750: Implementation constraints on reference-only closure objects
751: Deriving from closure classes
752: Name lookup in nested lambda-expressions
753: Array names in lambda capture sets
754: Lambda expressions in default arguments of block-scope function
declarations
756: Dropping cv-quali   cation on members of closure objects
759: Destruction of closure objects
761: Inferred return type of closure object call operator
762: Name lookup in the compound-statement of a lambda-expression
763: Is a closure object's operator() inline?
764: Capturing unused variables in a lambda expression
766: Where may lambda expressions appear?
767: void parameter for lambdas
768: Ellipsis in a lambda parameter list
769: Initialization of closure objects
770: Ambiguity in late-speci   ed return type
771: Move-construction of reference members of closure objects
772: capture-default in lambdas in local default arguments
774: Can a closure class be a POD?
775: Capturing references to functions
779: Rvalue reference members of closure objects?
782: Lambda expressions and argument-dependent lookup
796: Lifetime of a closure object with members captured by reference

> - Has the issue regarding the destructor timing of thread-locals been
> resolved?

No. There will be follow-up papers and further discussion at subsequent
meetings.

Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jul 18, 7:05 pm, Scott Meyers <use...@aristeia.com> wrote:
> Can somebody summarize other noteworthy results from the Frankfurt
> meeting (beyond the removal of concepts)?  I'm particularly interested
> in:
<snip>
> - Were any changes made to the variadic thread constructor?
<snip>

This one I can answer:  No, but the door has not been yet shut.
Search for "Frankfurt" under:

http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#929

-Howard


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 20 Jul., 21:55, Howard Hinnant wrote:
> On Jul 18, 7:05 pm, Scott Meyers wrote:
> > - Were any changes made to the variadic thread constructor?
>
> This one I can answer:  No, but the door has not been yet shut.
> Search for "Frankfurt" under:
>
> http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#929

Wouldn't be the support for move-only types be a strong case for this
constructor? With neither lambdas nor std::bind being able to handle
move-only types a user would have to write her/his own function
wrapper class to move a unique_ptr into the new thread. Sure, this can
be done generically (the result of "bind_all_once" could forward moved
parameters as rvalues once and throw "already_invoked_before"
exceptions when invoked more than once) but that seems like a very
special case just to enable moving objects into a new thread.

Cheers!
SG


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

SG <s.gesemann@gmail.com> writes:

> On 20 Jul., 21:55, Howard Hinnant wrote:
>> On Jul 18, 7:05 pm, Scott Meyers wrote:
>> > - Were any changes made to the variadic thread constructor?
>>
>> This one I can answer:  No, but the door has not been yet shut.
>> Search for "Frankfurt" under:
>>
>> http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#929
>
> Wouldn't be the support for move-only types be a strong case for this
> constructor? With neither lambdas nor std::bind being able to handle
> move-only types a user would have to write her/his own function
> wrapper class to move a unique_ptr into the new thread. Sure, this can
> be done generically (the result of "bind_all_once" could forward moved
> parameters as rvalues once and throw "already_invoked_before"
> exceptions when invoked more than once) but that seems like a very
> special case just to enable moving objects into a new thread.

Wholeheartedly agreed. This is one of the reasons I am in favour of
keeping the variadic thread constructor.

Another reason I think we should keep this constructor is that it can
actually simplify code where we already have a function or callable
object to invoke on the thread, or where writing one explicitly is
clearer than writing a lambda. In this case the use of std::bind or a
lambda just clutters the code. Given a simple thread function that takes
two integer parameters, here is code to launch the thread using
different techniques:

void my_thread_func(int arg1,int arg2);

std::thread t1(my_thread_func,calculate_arg1(some_param),
              calculate_arg2(other_param));

std::thread t2([=]{my_thread_func(calculate_arg1(some_param),
                                 calculate_arg2(other_param));});

int temp_arg1=calculate_arg1(some_param);
int temp_arg2=calculate_arg2(other_param);
std::thread t3([=]{my_thread_func(temp_arg1,temp_arg2);});

std::thread t4(std::bind(my_thread_func,calculate_arg1(some_param),
                        calculate_arg2(other_param)));

IMO the simplest is the variadic constructor t1.

Though relatively simple, and arguably clearer (once you've got used to
lambdas) as the function call is explicit, the lambda used in t2 adds
syntax and is subtly different --- calculate_arg1 and calculate_arg2 are
called in the new thread rather than the thread doing the
launching. This may or may not be significant depending on what they do.

The temporaries and lambda for t3 *do* have the same semantics as t1,
but at the cost of two explicit variables.

Finally, t4 also has the same semantics, but adds the noise of std::bind
for no benefit in clarity.

Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]