www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Encapsulate arguments

reply "alex burton" <alexibu.remove me.com> writes:
struct Init
{
Factory * factory;
Other arg1;
Another arg2;
};

void foo(const Init& init);

void bar(const Init& init)
{
       foo(init);
       other stuff;
};

bar(Init(factory,other args));


In C++ I often wrap some arguments that are common to multiple
functions in a struct.
This idiom can reduce typing when the args change.
It is particularly useful in testable code for constructors and
factory methods.
It adds minimal overhead and is really just syntax.
In D there are no header files to change making it slightly less
useful. In D you dont need to write the trivial ctor for Init
making it easier.

In D this would be void bar(in Init init) which makes init const
making all of the parts of init const. This means this idiom
cannot be applied as often args will be refences to mutable
objects.

Does anyone know an equivalent idiom for D ?
Jan 01 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 1 January 2014 at 23:00:33 UTC, alex burton wrote:
 In D this would be void bar(in Init init) which makes init const

You should just take Init, without the in. "in" means that you won't modify AND that you won't let any reference to the argument escape the function's scope. The second part isn't enforced by the compiler right now, but this may change at some point. "in" basically is "look, don't keep", and since ctor arguments are often kept in the class, it isn't ideal there. But plain non-const, non-in structs should be fine, that works the same way as a regular function argument list.
Jan 01 2014
prev sibling next sibling parent "alex burton" <alexibu.remove me.com> writes:
On Wednesday, 1 January 2014 at 23:11:49 UTC, Adam D. Ruppe wrote:
 On Wednesday, 1 January 2014 at 23:00:33 UTC, alex burton wrote:
 In D this would be void bar(in Init init) which makes init 
 const

You should just take Init, without the in. "in" means that you won't modify AND that you won't let any reference to the argument escape the function's scope. The second part isn't enforced by the compiler right now, but this may change at some point. "in" basically is "look, don't keep", and since ctor arguments are often kept in the class, it isn't ideal there. But plain non-const, non-in structs should be fine, that works the same way as a regular function argument list.

Thanks but won't the struct be copied at every function call then ?
Jan 01 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 2 January 2014 at 01:07:01 UTC, alex burton wrote:
 Thanks but won't the struct be copied at every function call 
 then ?

Yeah (unless the compiler optimizes it out), but that's not a big deal, and might even be better, since the fields need to be loaded anyway and doing it through a pointer might be a waste. But normal function arguments are copied anyway, so it is no loss.
Jan 01 2014
prev sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 2014-01-02 02:44, Adam D. Ruppe wrote:
 On Thursday, 2 January 2014 at 01:07:01 UTC, alex burton wrote:
 Thanks but won't the struct be copied at every function call then ?

Yeah (unless the compiler optimizes it out), but that's not a big deal, and might even be better, since the fields need to be loaded anyway and doing it through a pointer might be a waste. But normal function arguments are copied anyway, so it is no loss.

Also, if copying is problematic, use ref. -- Simen
Jan 02 2014