Variadic templates themselves don't avoid the copy, but combined with
perfect forwarding you should be doing well (see, for example,
make_shared)
From: Jordy Rose
Sent: 8/21/2011 10:34 AM
To: Carlo Alberto Ferraris
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Accessing arguments in a caller
What I can think of:
1. Anonymous struct, to avoid a copy.
2. Use stdarg.h...dangerous but accomplishes what you're looking for.
3. Split up F: giant switch statements often indicate that your
function is doing several different things. (IMHO...)
4. Don't worry about it, it's probably not a bottleneck. (Or rather,
profile first...)
But no, there's no standard way to do this. Even C++11's variadic
templates don't avoid the copy, and initializer lists are pretty much
equivalent to an anonymous struct / const struct reference.
(Why not? Because calling conventions differ from platform to
platform; often the first few arguments of a function are passed in
registers, not on the stack.)
Jordy
On Aug 21, 2011, at 6:23, Carlo Alberto Ferraris wrote:
> Nella citazione giovedì 18 agosto 2011 09:11:36, Carlo Alberto Ferraris ha
scritto:
>> I need some advice on "forwarding" arguments to a callee.
Suppose I have a function F that is called at the beginning of all other
functions in the module. From F I need to access (read) the arguments passed to
its immediate caller. Right now I do something like boxing all arguments in the
caller inside a struct and passing a pointer to the struct to F, alongside an
identifier telling which caller F is being called from. F has then a giant
switch that branches to the appropriate unboxing code. This is obviously
suboptimal because I need to allocate the struct on the stack, copy the
arguments inside of it and then passing an additional pointer to F.
>> I was wondering if there's a better way to do this, e.g. a way to
access the stack frame of the caller (knowing, thanks to the identifier, which
caller F was called from) or, more in general, arbitrary values d
> efined
>> in the caller. Any suggestions?
>
> Are there really no better ways of doing this?
> <cafxx.vcf>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
