www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - variadic functions

reply 0ffh <frank youknow.what.todo.interNETz> writes:
Hrmmnn... I hope this is not the gazillionth time:

Can I pass on the parameters from one variadic function to the next?
Just passing on _argptr (in analogy to C) does not seem to work. :(

regards, frank
Jan 03 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"0ffh" <frank youknow.what.todo.interNETz> wrote in message 
news:fljc2m$ah7$1 digitalmars.com...

 Hrmmnn... I hope this is not the gazillionth time:

 Can I pass on the parameters from one variadic function to the next?
 Just passing on _argptr (in analogy to C) does not seem to work. :(


Actually I think it's something like the _three_ gazillionth time ;)

You can't do it.  I know.  It's dumb.

Actually, passing _argptr in C probably wouldn't work either, at least not 
portably.
Jan 03 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley wrote:


 "0ffh" <frank youknow.what.todo.interNETz> wrote in message
 news:fljc2m$ah7$1 digitalmars.com...

 Hrmmnn... I hope this is not the gazillionth time:

 Can I pass on the parameters from one variadic function to the next?
 Just passing on _argptr (in analogy to C) does not seem to work. :(


 
 Actually I think it's something like the _three_ gazillionth time ;)
 
 You can't do it.  I know.  It's dumb.
 
 Actually, passing _argptr in C probably wouldn't work either, at least not
 portably.


It's really sad that D, the language I've heard called "C++ without the
warts", inherits this type of funcitonality.  I know Tango had issues with
64 bit gdc because of how the variadic stuff is handled.  It'd be nice to
see a clean, typesafe alternative/replacement.

PS: the official docs are at http://www.digitalmars.com/d/function.html
    They don't comment on platform-specific.
Jan 03 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:

 Jarrett Billingsley wrote:
 

 "0ffh" <frank youknow.what.todo.interNETz> wrote in message
 news:fljc2m$ah7$1 digitalmars.com...

 Hrmmnn... I hope this is not the gazillionth time:

 Can I pass on the parameters from one variadic function to the next?
 Just passing on _argptr (in analogy to C) does not seem to work. :(


 Actually I think it's something like the _three_ gazillionth time ;)

 You can't do it.  I know.  It's dumb.

 Actually, passing _argptr in C probably wouldn't work either, at least not
 portably.


 
 It's really sad that D, the language I've heard called "C++ without the
 warts", inherits this type of funcitonality.  I know Tango had issues with
 64 bit gdc because of how the variadic stuff is handled.  It'd be nice to
 see a clean, typesafe alternative/replacement.
 
 PS: the official docs are at http://www.digitalmars.com/d/function.html
     They don't comment on platform-specific.


Indeed.  It was one of my first shockers with D.  Variadic args are one 
of the first things I'd be trying to make easier and cleaner if I set 
out to build a better C/C++.

The other shocker to me was how kludgy and raw opApply functions look. 
I still find it weird that I the programmer am responsible for handing D 
back an int from my opApply that D generated to begin with!  It just 
seems wrong that I should have to be the middle man there for an 
implementation detail like that.  (Not to mention that the reason for 
that mystery int is never explained in the documentation, making it all 
the more perplexing).

--bb
Jan 04 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:

 Indeed.  It was one of my first shockers with D.  Variadic args are one 
 of the first things I'd be trying to make easier and cleaner if I set 
 out to build a better C/C++.
 
 The other shocker to me was how kludgy and raw opApply functions look. 
 I still find it weird that I the programmer am responsible for handing D 
 back an int from my opApply that D generated to begin with!  It just 
 seems wrong that I should have to be the middle man there for an 
 implementation detail like that.  (Not to mention that the reason for 
 that mystery int is never explained in the documentation, making it all 
 the more perplexing).
 
 --bb


I totally agree.  I guess we need someone to champion a solution to these that
both makes more sense and preserves efficiency.

I assume having the opApply delegate raising an exception could result in slow
handling of break statements?  At the very least, an enum outlining what the
return values mean would be nice.  

For variadic functions, using a tuple makes a whole lot more sense.
Jan 04 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:

 Bill Baxter Wrote:

 Indeed.  It was one of my first shockers with D.  Variadic args are one 
 of the first things I'd be trying to make easier and cleaner if I set 
 out to build a better C/C++.

 The other shocker to me was how kludgy and raw opApply functions look. 
 I still find it weird that I the programmer am responsible for handing D 
 back an int from my opApply that D generated to begin with!  It just 
 seems wrong that I should have to be the middle man there for an 
 implementation detail like that.  (Not to mention that the reason for 
 that mystery int is never explained in the documentation, making it all 
 the more perplexing).

 --bb


 
 I totally agree.  I guess we need someone to champion a solution to these that
both makes more sense and preserves efficiency.
 
 I assume having the opApply delegate raising an exception could result in slow
handling of break statements?  At the very least, an enum outlining what the
return values mean would be nice.  


Oh geez, yeh.  Duh.  That's the part I forgot about in my other post: 
control flow -- getting the user's op apply to return prematurely.


 For variadic functions, using a tuple makes a whole lot more sense.  


But that doesn't really work if you want a function that you get a 
pointer to and pass around in your code.

--bb
Jan 04 2008
parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
Bill Baxter wrote:

 Jason House wrote:

 Bill Baxter Wrote:

 Indeed.  It was one of my first shockers with D.  Variadic args are 
 one of the first things I'd be trying to make easier and cleaner if I 
 set out to build a better C/C++.
 [...]
 --bb


 I totally agree.  I guess we need someone to champion a solution to 
 these that both makes more sense and preserves efficiency.
 [...]
 For variadic functions, using a tuple makes a whole lot more sense.  


 
 But that doesn't really work if you want a function that you get a 
 pointer to and pass around in your code.
 
 --bb


I know people will hate me for this, but IMHO the problem with variadic
args is not a lack of sophistication, but an abundance of the same.
In C it works because C tries to be simple and straightforward (from a
machine pov, not necessarily from a human one), while the additional
sophistry that D introduced stands in the way of a simple solution.
The simplest way to fix this would probably be to give up the array
of the _arguments. But as in these times it is practically unthinkable
(and also, I admit, not really desirable) to live without the type
information they provide, the only way out I can see is to add yet more
complexity to the D compiler to handle this as a special case.

Anyways, I don't think this is really a big issue. It's just a bit of a
surprise for those of us who are used to a simpler paradigm.

regards, frank
Jan 04 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"0ffh" <frank youknow.what.todo.interNETz> wrote in message 
news:flmmgh$24hb$1 digitalmars.com...


 I know people will hate me for this, but IMHO the problem with variadic
 args is not a lack of sophistication, but an abundance of the same.
 In C it works because C tries to be simple and straightforward (from a
 machine pov, not necessarily from a human one), while the additional
 sophistry that D introduced stands in the way of a simple solution.
 The simplest way to fix this would probably be to give up the array
 of the _arguments. But as in these times it is practically unthinkable
 (and also, I admit, not really desirable) to live without the type
 information they provide, the only way out I can see is to add yet more
 complexity to the D compiler to handle this as a special case.

 Anyways, I don't think this is really a big issue. It's just a bit of a
 surprise for those of us who are used to a simpler paradigm.


What would make most sense to me would be if there were a built-in variant 
type, or maybe a library-provided (library-extended?) variant type.  Then 
variadic functions just become a flavor of typesafe varidic functions with 
some implicit casting to Variant.  Then you can mess around with the array 
of args, change the values, change the size of the array, save it somewhere, 
pass it along, pass a slice along etc.
Jan 04 2008
parent 0ffh <frank youknow.what.todo.interNETz> writes:
Jarrett Billingsley wrote:

 "0ffh" <frank youknow.what.todo.interNETz> wrote in message 
 news:flmmgh$24hb$1 digitalmars.com...
 

 [...]
 Anyways, I don't think this is really a big issue. It's just a bit of a
 surprise for those of us who are used to a simpler paradigm.


 
 What would make most sense to me would be if there were a built-in variant 
 type, or maybe a library-provided (library-extended?) variant type.  Then 
 variadic functions just become a flavor of typesafe varidic functions with 
 some implicit casting to Variant.  Then you can mess around with the array 
 of args, change the values, change the size of the array, save it somewhere, 
 pass it along, pass a slice along etc. 


Right, there's that one solution, the array of variants where all the rest
goes. But I can do that now already, just with a different syntax than the
ellipsis. And just thinking of the runtime cost makes me dizzy, but that's
a personal thing. Probably comes from doing too much coding on 24MHz 16bit
machines. =)

regards, frank
Jan 05 2008
prev sibling parent 0ffh <frank youknow.what.todo.interNETz> writes:
Jarrett Billingsley wrote:

 Actually, passing _argptr in C probably wouldn't work either, at least not 
 portably. 


Just for the record: Right, I misremembered! Awkward! :-(

I went back to my archives and found two solutions I used, one compiler-
specific and one an ugly hack involving macros like: "#define va_pass_4 
*(int*)args,((int*)args)[1],((int*)args)[2],((int*)args)[3]".

regards, frank (blushing)
Jan 09 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to 0ffh,


 Hrmmnn... I hope this is not the gazillionth time:
 
 Can I pass on the parameters from one variadic function to the next?
 Just passing on _argptr (in analogy to C) does not seem to work. :(
 
 regards, frank
 


WANRING HACK

byte* from = "the lower bound of the args";
byte* to = "the upper bound of the args";
variadicFn(from[0..to-from]);

As long as you arn't using the type safe version that might work.
Jan 03 2008
parent 0ffh <frank youknow.what.todo.interNETz> writes:
BCS wrote:

 Reply to 0ffh,
 

 Hrmmnn... I hope this is not the gazillionth time:

 Can I pass on the parameters from one variadic function to the next?
 Just passing on _argptr (in analogy to C) does not seem to work. :(

 regards, frank


 
 WANRING HACK
 
 byte* from = "the lower bound of the args";
 byte* to = "the upper bound of the args";
 variadicFn(from[0..to-from]);
 
 As long as you arn't using the type safe version that might work.


Thanks a bunch! I'll try that out of curiosity, but I admit I have
already settled on a workaround to make the downstream functions
non-variadic, with an explicit argptr parameter (although that's
a kluge, admittedly).

regards, frank
Jan 04 2008
prev sibling parent novice2 <sorry noem.ail> writes:
please, vote for "variadic arguments re-passing" at unofficial wishlist
http://www.all-technology.com/eigenpolls/dwishlist/index.php
Jan 04 2008