Thanks Jonathan!
Hm... why would don't add it for portability? Of course, i don't see codes with
Nested-Functions so much, but...
I think that better would delete it, or add full support?
And, it's contradicts to standart of C, nope?:)
~~~
About lambda:
Yeah is very
On 01/03/2018 07:52 PM, Austin T wrote:
By nested functions, I'm assuming that means raw function definitions that
are valid inside a temporary scope of a function. If I'm not mistaken,
they're equivalent to C++ lambda expressions but just written in a
syntactic sugar syntax.
On 4 January 2018 at 00:54, nick wrote:
>
>
> On 2018-01-03 07:52 PM, Austin T wrote:
>> By nested functions, I'm assuming that means raw function definitions that
>> are valid inside a temporary scope of a function. If I'm not mistaken,
>> they're equ
;
>
> It depends actually, lambdas are consider the C++ standard of this. I am
> wondering what
> you mean Alexsandir and what is your use case as lambdas tryto solve this for
> most use
> cases of antonymous and nested functions. What are the requirements if any
> that la
On 2018-01-03 07:52 PM, Austin T wrote:
> By nested functions, I'm assuming that means raw function definitions that
> are valid inside a temporary scope of a function. If I'm not mistaken,
> they're equivalent to C++ lambda expressions but just written in a s
By nested functions, I'm assuming that means raw function definitions that
are valid inside a temporary scope of a function. If I'm not mistaken,
they're equivalent to C++ lambda expressions but just written in a
syntactic sugar syntax.
Austin
On Jan 3, 2018 2:44 PM, "nick
s. I am
wondering what
you mean Alexsandir and what is your use case as lambdas tryto solve this for
most use
cases of antonymous and nested functions. What are the requirements if any that
lambdas
don't meant and have you looked at the C++14/17 standard for them if your
compiler
suppo
On 3 January 2018 at 21:13, Alexsandr Yvarov wrote:
> Why would dont add it at GNU G++?
Aren't C++ lambda expressions more powerful and flexible?
Why would dont add it at GNU G++?
> Yes. Instead of a direct call, load the fptr for _mcount and do an
> indirect call. That'll avoid the dynamic linker. You can conditionalize
> this on cfun->static_chain_decl to avoid the extra work when nested
> functions aren't involved.
Ah! yes, of course, writin
on cfun->static_chain_decl to avoid the extra work when nested
functions aren't involved.
Also, technically fptrs (and thus dynamic linking) isn't used when either
TARGET_NO_PIC or TARGET_AUTO_PIC are set. Of course, I wouldn't expect
nested functions to be used here either, but...
r~
itten in glibc (in
particular the 'alloc' line) is quite annoying. Or is that a lost cause and
should profiling require static linking in presence of nested functions?
Thanks in advance.
--
Eric Botcazou
Hi,
Is GCC + gprof supposed to handle nested functions?
It looks like they are not properly reported.
The original problem was on Ada code with nested
functions. This is with HEAD and GNU gprof 2.15.91.0.2
on a SuSE 9.2 system.
Thanks in advance,
Laurent
$ cat cn.c
#define N 1000
static
13 matches
Mail list logo
