Is there a nice syntax to achieve optional named parameters?
evilrat666 at gmail.com
Fri Jan 18 12:09:10 UTC 2019
On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote:
> On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
>> struct Config
>> string title;
>> int width;
>> struct Window
>> this(Config config)
> It likely is a bad idea for a small struct like this but if it
> was much bigger would it makes sense to write this as :-
> this(const ref Config config)
> Which is what you might do in C++ or does D handle this
You'd better profile and only then act.
Seriously, whatever you know and familiar with in C++ might not
work with D, you'll just end up with C++'ish code that just
happens to be written in D.
D is not C++, and such premature optimizations might cause more
harm if applied on occassion or out of habit.
IIRC D structs are all movable, so doing const refs here and
there or using writing to ref parameter instead normal
return(RVO) is likely bad for your code.
D has its own ABI, it's not even compatible with C++, so when you
pass structs by value it may or may not produce similar asm as
C++ compilers does.
When struct contains strings/arrays they are anyway managed by
GC(unless you allocated it on your own), but this is something
that more seasoned D users can explain in better details and
cleaner explanation than me, if it means anything at all.
Even without all this, do you really want to mess up your
codebase with implementation details about how it should do it,
or write clean (self)documented code? Is it really going to be a
bottleneck in your program? Passing one big struct at widget's
creation on program startup and some rare events really going to
Why not just write working code first and then identify
bottlenecks and optimize when it absolutely ultimately necessary?
Btw I don't remember much ref parameters in phobos, just look at
it... I found only 4 ref consts it in std.file, 3 in std.array,
other modules more likely to have them in comparison operators(I
have no idea why, to not introduce potential RVO case?) and in
unit tests for testing correct behavior.
Again, D is not C++, what might work or even considered "good
practice" there may or may not work here. So just profile it!
More information about the Digitalmars-d-learn