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
parent reply "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
parent reply "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
parent reply "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
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