www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to delegate varargs

reply Frank Benoit <keinfarbton googlemail.com> writes:
How can I delegate the variadic argument list to another variadic
argument function?

e.g.
void myWritef( char[] frm, ... ){
  writefln( frm, ??? );
}

And how can I add or remove arguments to these varargs?
Nov 20 2007
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Frank Benoit wrote:
 How can I delegate the variadic argument list to another variadic
 argument function?
 
 e.g.
 void myWritef( char[] frm, ... ){
   writefln( frm, ??? );
 }
 
 And how can I add or remove arguments to these varargs?
You have to write a "wrapper" function that explicitly takes the hidden arguments. In the case of writefln, phobos provides OutputStream.writefx. To modify the hidden arguments, you would have to know the size of the buffer _argptr points to. I don't see how this is possible with DMD :/
Nov 20 2007
parent reply Sean Kelly <sean f4.ca> writes:
Tomas Lindquist Olsen wrote:
 Frank Benoit wrote:
 How can I delegate the variadic argument list to another variadic
 argument function?

 e.g.
 void myWritef( char[] frm, ... ){
   writefln( frm, ??? );
 }

 And how can I add or remove arguments to these varargs?
You have to write a "wrapper" function that explicitly takes the hidden arguments. In the case of writefln, phobos provides OutputStream.writefx.
Yup, and this stinks. I don't suppose some language feature could be provided for working around this? Sean
Nov 20 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:fhvhck$204d$5 digitalmars.com...
 Tomas Lindquist Olsen wrote:
 Frank Benoit wrote:
 How can I delegate the variadic argument list to another variadic
 argument function?

 e.g.
 void myWritef( char[] frm, ... ){
   writefln( frm, ??? );
 }

 And how can I add or remove arguments to these varargs?
You have to write a "wrapper" function that explicitly takes the hidden arguments. In the case of writefln, phobos provides OutputStream.writefx.
Yup, and this stinks. I don't suppose some language feature could be provided for working around this? Sean
It would be nice if varargs were passed instead as a reference to an array that's built on the stack out of (typeinfo, value) pairs. Problem with that, of course, is that each value can be a different size.. Tricky indeed.
Nov 20 2007
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Sean Kelly wrote:
 Tomas Lindquist Olsen wrote:
 Frank Benoit wrote:
 How can I delegate the variadic argument list to another variadic
  argument function?
 
 e.g. void myWritef( char[] frm, ... ){ writefln( frm, ??? ); }
 
 And how can I add or remove arguments to these varargs?
You have to write a "wrapper" function that explicitly takes the hidden arguments. In the case of writefln, phobos provides OutputStream.writefx.
Yup, and this stinks. I don't suppose some language feature could be provided for working around this? Sean
It should be possible, I can't really see anything that could be a showstopper. Except using real variadic function to implement it. On x86-64 va_list is not a simple pointer to data, so the storage for the variadic arguments would have to alloca'd by the caller for this idea to work. This is exactly what I do in LLVMDC [1] btw, as implementing a variadic function is broken on x86-64 (my development platform). Only calling one works... Ok :) Here's the idea, it's very simple! The way it currently works: // --------------------------- // the function: void func(...); // really gets the prototype void func_impl(TypeInfo[], void*); // calling it like this: void func(3.0f, "hello"[]); // is implemented like this: TypeInfo[2] arg_ti = [typeid(float), typeid(char[])]; struct Tmp { float f, char[] c; } Tmp arg_val = Tmp(3.0f, "hello"); func_impl(arg_ti[], cast(void*)&arg_val); // ---------------------------- Now to be able to pass on the arguments (and possible add to them), we need another parameter: size_t _argptrLength; Further, we also need to be able to pass ... as an argument in a call expression. // --------------------------- // lets implement func2 void func2(...) { // call the first one adding some params func(42, ... , 8.0i); } // --------------------------- // now... // the function: void func2(...); // really gets the prototype void func(TypeInfo[], void*, size_t); // calling it like this: func(42, ...); // gets implemented like this: TypeInfo[] arg_ti = (cast(TypeInfo*)alloca(TypeInfo.size*(1+_arguments.length)))[0..1+_arguments.length]; arg_ti[0] = typeid(int); arg_ti[1..1+arguments.length] = _arguments[]; void* arg_val = alloca(int.sizeof + _argptrLength); *(cast(int*)arg_val) = 42; func_impl(arg_ti, arg_val); // ---------------------------- I hope this makes sense, it could be written better, but it should show the idea. All this is stuff the compiler could figure out. Thinking in terms of LLVMDC and codegen, it could be done fairly easily. I'm not sure how much work it would be to get the DMD frontend to accept the '...' token as a function argument and generate something meaningful in the AST though. Excuse all the LLVMDC references, I know nobody is using it yet (with good reason), but it's my only reference to compiler development :) Hope to get some feedback, don't think I've spent this much time on a NG post before :P - Tomas Lindquist Olsen [1] LLVMDC - LLVM D Compiler - http://www.dsource.org/projects/llvmdc
Nov 20 2007
next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
ok seem I should have read the code again before posting, hope the message
comes across even 
with the flaws.
Nov 20 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:
 Sean Kelly wrote:
 Tomas Lindquist Olsen wrote:
 Frank Benoit wrote:
 How can I delegate the variadic argument list to another variadic
  argument function?

 e.g. void myWritef( char[] frm, ... ){ writefln( frm, ??? ); }

 And how can I add or remove arguments to these varargs?
You have to write a "wrapper" function that explicitly takes the hidden arguments. In the case of writefln, phobos provides OutputStream.writefx.
Yup, and this stinks. I don't suppose some language feature could be provided for working around this? Sean
It should be possible, I can't really see anything that could be a showstopper. Except using real variadic function to implement it. On x86-64 va_list is not a simple pointer to data, so the storage for the variadic arguments would have to alloca'd by the caller for this idea to work. This is exactly what I do in LLVMDC [1] btw, as implementing a variadic function is broken on x86-64 (my development platform). Only calling one works... Ok :) Here's the idea, it's very simple! The way it currently works: // --------------------------- // the function: void func(...); // really gets the prototype void func_impl(TypeInfo[], void*); // calling it like this: void func(3.0f, "hello"[]); // is implemented like this: TypeInfo[2] arg_ti = [typeid(float), typeid(char[])]; struct Tmp { float f, char[] c; } Tmp arg_val = Tmp(3.0f, "hello"); func_impl(arg_ti[], cast(void*)&arg_val); // ---------------------------- Now to be able to pass on the arguments (and possible add to them), we need another parameter: size_t _argptrLength; Further, we also need to be able to pass ... as an argument in a call expression. // --------------------------- // lets implement func2 void func2(...) { // call the first one adding some params func(42, ... , 8.0i); } // --------------------------- // now... // the function: void func2(...); // really gets the prototype void func(TypeInfo[], void*, size_t); // calling it like this: func(42, ...); // gets implemented like this: TypeInfo[] arg_ti = (cast(TypeInfo*)alloca(TypeInfo.size*(1+_arguments.length)))[0..1 _arguments.length]; arg_ti[0] = typeid(int); arg_ti[1..1+arguments.length] = _arguments[]; void* arg_val = alloca(int.sizeof + _argptrLength); *(cast(int*)arg_val) = 42; func_impl(arg_ti, arg_val); // ---------------------------- I hope this makes sense, it could be written better, but it should show the idea. All this is stuff the compiler could figure out. Thinking in terms of LLVMDC and codegen, it could be done fairly easily. I'm not sure how much work it would be to get the DMD frontend to accept the '...' token as a function argument and generate something meaningful in the AST though. Excuse all the LLVMDC references, I know nobody is using it yet (with good reason), but it's my only reference to compiler development :) Hope to get some feedback, don't think I've spent this much time on a NG post before :P - Tomas Lindquist Olsen [1] LLVMDC - LLVM D Compiler - http://www.dsource.org/projects/llvmdc
I don't care how it works, but some clean way to forward function varargs that doesn't look like a clumsy afterthought would be fantastic. --bb
Nov 20 2007
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:
 
 I don't care how it works, but some clean way to forward function 
 varargs that doesn't look like a clumsy afterthought would be fantastic.
 
 --bb
From a users point of view the only change to the D spec would be: At the end of the section "D-style Variadic Functions" append: <<<<< The variadic arguments can be forwarded to another D-style variadic function by passing '...' as an argument. The forwarded arguments are bit-copied onto a new argument list. void foo(...) { // do something } void bar(...) { foo(1, ..., 3.0); }

With this approach there is still no way to slice the argument list, for that a more high-level approach like the ones mentioned by Jarret in the "Variadic arguments and map" thread is probably needed.
Nov 20 2007
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Tomas Lindquist Olsen wrote:
 
  From a users point of view the only change to the D spec would be:
 
 At the end of the section "D-style Variadic Functions" append:
 
 <<<<<
 The variadic arguments can be forwarded to another D-style variadic 
 function by passing '...' as an argument. The forwarded arguments are 
 bit-copied onto a new argument list.
 
     void foo(...)
     {
         // do something
     }
     void bar(...)
     {
         foo(1, ..., 3.0);
     }
  >>>>>
 
 With this approach there is still no way to slice the argument list, for 
 that a more high-level approach like the ones mentioned by Jarret in the 
 "Variadic arguments and map" thread is probably needed.
Possibly also the section about "_argptr" should be changed to: "These variadic functions have a special local variable declared for them, _argptr, which is a void* pointer to the first of the variadic arguments. To access the arguments, _argptr must be cast to a pointer to the expected argument type. There is also a special local variable, _argptrLength, which holds the length in bytes of the variadic argument list" This could however just be an implementation detail.
Nov 20 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Tomas Lindquist Olsen wrote:
 Tomas Lindquist Olsen wrote:
  From a users point of view the only change to the D spec would be:

 At the end of the section "D-style Variadic Functions" append:

 <<<<<
 The variadic arguments can be forwarded to another D-style variadic 
 function by passing '...' as an argument. The forwarded arguments are 
 bit-copied onto a new argument list.

     void foo(...)
     {
         // do something
     }
     void bar(...)
     {
         foo(1, ..., 3.0);
     }
  >>>>>

 With this approach there is still no way to slice the argument list, 
 for that a more high-level approach like the ones mentioned by Jarret 
 in the "Variadic arguments and map" thread is probably needed.
Possibly also the section about "_argptr" should be changed to: "These variadic functions have a special local variable declared for them, _argptr, which is a void* pointer to the first of the variadic arguments. To access the arguments, _argptr must be cast to a pointer to the expected argument type. There is also a special local variable, _argptrLength, which holds the length in bytes of the variadic argument list" This could however just be an implementation detail.
Why not just make it void[] _argdata? It would save us some naming clutter.
Nov 20 2007
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Chad J wrote:
 
 Why not just make it void[] _argdata?  It would save us some naming 
 clutter.
But it would become a breaking change.
Nov 20 2007