foreach

[Rikki Cattermole via Digitalmars-d]

On 17/06/2014 7:59 p.m., monarch_dodra wrote:
> On Monday, 16 June 2014 at 21:47:22 UTC, H. S. Teoh via Digitalmars-d
> wrote:
>> On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via Digitalmars-d
>> wrote:
>>> On Mon, Jun 16, 2014 at 06:37:56PM +0000, Wyatt via Digitalmars-d wrote:
>>> > On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via >
>>> Digitalmars-d wrote:
>>> [...]
>>> > >Or, on the flip side, functions with 10-15 parameters, each > >of
>>> which
>>> > >influences which subset of the others actually have any > >effect.
>>> > >
>>> > Tame.  Gaze upon true horror:
>>> > > #2  0x0809082c in stnz_sutrs (rec=0x461d550,
>>> > app_context_arg=0x461dfd0, attribute_set=0x0, > answer_complete=1,
>>> > present_type=2, cgm=0, graphics=0, highlight_option=1,
>>> > records_requested=1, current_field=76, num_fields=88,
>>> > field=0x462a160, ans=0x0, database=0x45e0628 "REGISTRY",
>>> > esn_list=0x461dd98, issue_break=0x461d754, callback=0x806f82d
>>> > <display_next_answer>, callback_arg=0x461d668,
>>> > field_callback=0x8087bff <field_formatter>,
>>> > field_callback_arg=0x462adb8, callback_scheduled=0xfef92ac0, > dg=0,
>>> > dp=5, line_length=100) at stnz_sutrs.c:399
>>>
>>> Whoa. I think I need therapy after reading this...
>> [...]
>>
>> Aaarrggghh... I thought that was bad, and then I saw this:
>>
>>     http://c2.com/cgi/wiki?BadCode
>>
>> (Search for "SUBROUTINE FEMA" on that page. It's a function with 292
>> parameters(!).)
>>
>>
>> T
>
> We recently did some cleanup in our organization in regards to a couple
> functions whose argument counts were are too damn high: We created a
> helper-class which actually contains the arguments. So the calls now
> look like:
>
> Arguments arg;
> arg.InputSize = 5;
> arg.method = ASSSENDING;
> fun(arg);
>
> It might look like bloat initialy, but it makes things *WORLDS* easier.
> For starters, the arguments are *all* named, even at call sight. Second,
> any un-specified argument has its default value, even if there are other
> arguments you want to modify later.
>
> That said, there might have been better approaches to not fall into this
> trap in the first place, but that's an (arguably) low cost sanity patch.

I've used structs for this purpose in parsers quite a bit. Can be very 
useful, but in saying that. I would use the input args at the first ones 
in a struct and then output/manipulation values to be passed to other 
functions as later ones.

What this means is:

struct MyArgs {
	int x;
         int y;

         int z;
}

void adder(ref MyArgs args) {
     args.z = args.x + args.y;
}

void main() {
     auto args = MyArgs(1, 2);
     adder(args);
     writeln(args.z);
}

While yes there is other ways to do it, for larger argument lists that 
need to be passed around (as a state, and yes classes could do something 
similar) it works well. But more or less this is a trick for CTFE than 
anything else.