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

"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.

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.

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.

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

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

please, vote for "variadic arguments re-passing" at unofficial wishlist http://www.all-technology.com/eigenpolls/dwishlist/index.php

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.

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

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