Sorry for not getting back to your original post Paolo. I haven't been
picking up mails for a while.
On 2017-05-01 16:56, Jason Merrill wrote:
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini
wrote:
On 26/04/2017 12:32, Paolo Carlini wrote:
in 2013 (2013-09-16) Adam added two slightly obscur
This only supports the explicit template parameter syntax and does not
correctly support conversion to static ptr-to-function for generic
stateless lambdas.
---
gcc/cp/mangle.c| 2 ++
gcc/cp/parser.c| 43 +--
gcc/cp/semantics.c | 24
Hi Jason,
I did find some code in the end but it wasn't much use due to the
changes in gcc/cp since the old lambda branch from which the original
patch was based.
I've since been finding 10 minutes here and there to have a hack about
and have finally got the first stage of generic lambda support
Hi Jason,
On 23.04.2013 14:42, Jason Merrill wrote:
On 22.04.2013 17:42, Jason Merrill wrote:
> On 08/10/2009 08:33 PM, Adam Butcher wrote:
> > Attached are my latest experimental polymorphic lambda patches
> > against the latest lambda branch.
>
> Polymorphic lambdas were
On Thu, January 20, 2011 4:43 pm, Jonathan Wakely wrote:
> On 20 January 2011 14:26, Adam Butcher wrote:
> > Hi there,
> >
> > Attached is a tentative patch ...
> > [snip]
>
> thanks for working on this. Patches should be sent to the gcc-patches
> list for r
Hi there,
Attached is a tentative patch to support using decltype as a
base-type-specifier (Re:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42603).
It should handle also the case where decltype is used as the start of a
nested-name-specifier when this is supported in the future.
Any feedback wel
On Fri, January 15, 2010 3:57 pm, Dave Korn wrote:
> Adam Butcher wrote:
>> On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>>> I mean, why a well designed application should refuse to listen to ctrl-c
>>> when something goes wrong? Why every time for some reaso
On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>
> I mean, why a well designed application should refuse to listen to
> ctrl-c when something goes wrong? Why every time for some reason it gets
> stuck, I have to kill it from another shell? That's definitely annoying.
>
If you're on a posix-
Thanks for the feedback.
Jason Merrill wrote:
>Adam Butcher wrote:
>> The following examples produce
>> equivalent functions:
>>
>>1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
>>2. [] (X x, Y& y, Z const& z) {
>>
Attached are my latest experimental polymorphic lambda patches against the
latest lambda branch. Template parameters
implied by auto in the lambda's call parameter list no longer lose qualifiers.
The following examples produce
equivalent functions:
1. [] (auto x, auto& y, auto const& z) {
Adam Butcher wrote:
>John Freeman wrote:
>>
>> I just inspected my code again. The call to layout_class_type at the
>> beginning of finish_lambda_function_body at semantics.c:5241 was
>> intended to recalculate offsets to members in the case of default captures.
>&
Hi Jason,
Pending response from assign at gnu dot org, I've attached diffs made against
your latest lambda head. They are
cleaned up a little to from the previous diffs against trunk. First is the
re-layout fix, second is experimental
polymorphic lambda support.
Cheers,
Adam
0001-Re-laid-ou
Jason Merrill wrote:
> On 08/03/2009 09:36 PM, Adam Butcher wrote:
>> Thanks. I haven't any copyright assignments on file -- this is my first
>> dabbling with gcc and I've been doing it
>> mostly to experiment with C++ lambda support and non-standard extensions
Hi
Esben Mose Hansen writes:
> this program SEGFAULTs
>
> #include
>
> int main() {
> int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> const std::size_t nn = sizeof(numbers)/sizeof(int);
> int sum = 0;
> int f = 5;
> std::for_each(&numbers[0], &numbers[nn], [&] (int n) {
> sum +=
14 matches
Mail list logo
