Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
January 01, 2014 Encapsulate arguments | ||||
---|---|---|---|---|
| ||||
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 ? |
January 01, 2014 Re: Encapsulate arguments | ||||
---|---|---|---|---|
| ||||
Posted in reply to alex burton | 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.
|
January 02, 2014 Re: Encapsulate arguments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 ?
|
January 02, 2014 Re: Encapsulate arguments | ||||
---|---|---|---|---|
| ||||
Posted in reply to alex burton | 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.
|
January 02, 2014 Re: Encapsulate arguments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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
|
Copyright © 1999-2021 by the D Language Foundation