Re: Taking arguments by value or by reference

[Max Haughton via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 23:00:46 UTC, Anonymouse wrote:
I'm passing structs around (collections of strings) whose 
.sizeof returns 432.


The readme for 2.094.0 includes the following:

This release reworks the meaning of in to properly support all 
those use cases. in parameters will now be passed by reference 
when optimal, [...]


* Otherwise, if the type's size requires it, it will be passed 
by reference.
Currently, types which are over twice the machine word size 
will be passed by
reference, however this is controlled by the backend and can 
be changed based

on the platform's ABI.


However, I asked in #d a while ago and was told to always pass 
by value until it breaks, and only then resort to ref.


[18:32:16]  at what point should I start passing my 
structs by ref rather than by value? some are nested in 
others, so sizeofs range between 120 and 620UL

[18:33:43]  when you start getting stack overflows
[18:39:09]  so if I don't need ref for the references, 
there's no inherent merit to it unless I get in trouble 
without it?

[18:39:20]  pretty much
[18:40:16]  in many cases the copying is merely 
theoretical and doesn't actually happen when optimized


I've so far just been using const parameters. What should I be 
using?


Firstly, the new in semantics are very new and possibly subtly 
broken (take a look at the current thread in general).


Secondly, as to the more specific question of how to pass a big 
struct around it may be helpful to look at this quick godbolt 
example (https://d.godbolt.org/z/nPvTWz). Pay attention to the 
instructions writing to stack memory (or not). A struct that big 
will be passed around on the stack, whether it gets copied or not 
depends on the semantics of the struct etc.


The guiding principle to your function parameters should be 
correctness - if I am passing a big struct around, if I want to 
take ownership of it I probably want to take it by value but if I 
want to modify it I should take it by reference (or by pointer 
but don't overcomplicate, notice in the previous example they 
lower to the same thing). If I just want to look at it, it should 
be taken by const ref if possible (D const isn't the same as C++ 
const, this may catch you out).


Const-correctness is a rule to live by especially with an big 
unwieldy struct.


I would avoid the new in for now, but I would go with const ref 
from what you've described so far.

Re: any chance to get it working on windows xp?

[Drone1h via Digitalmars-d-learn]

On Monday, 18 May 2020 at 05:36:01 UTC, Mike Parker wrote:

[...]
Unfortunately, the minimum Windows version "officially" 
supported is Windows 7:


https://forum.dlang.org/post/ktfgps$2ghh$1...@digitalmars.com

With no testing on XP, you are bound to run into difficulties 
trying to use the tools there. So yeah, your best bet is using 
a compiler version that works and see if building dub from 
source makes a difference. If you can't get dub to work, then 
you'll want to look into using rdmd, which has shipped with dmd 
for years now, or perhaps makefiles.

[...]


This is not exactly a reply to the original thread, but maybe it 
helps someone who has searched for "Windows XP" in the forum and 
found this discussion.


For version 2.094, dmd.exe and dub.exe require Windows Vista or 
Windows 7 or newer.


We can make these tools support Windows XP (and possibly Windows 
2000 too) by patching them as follows:


- at offset 148h (offset 40h from the "PE" signature), we change 
06h to 05h;
- at offset 150h (offset 48h from the "PE" signature), we change 
06h to 05h;

- in both dmd.exe and dub.exe.

(This support has not been thoroughly tested, but I seem to be 
able to build and run simple applications using Windows XP.)



lld-link.exe also requires Windows Vista or 7 or newer, but I am 
too noob to make it support Windows XP.


ddemangle.exe, dustmite.exe, libcurl.dll, optlink.exe and 
rdmd.exe all support older versions of Windows (at least, they 
support Windows XP).



(All the .exe files mentioned above are the 32-bit ones located 
in the "windows\bin" subfolder, not the 64-bit ones located in 
the "windows\bin64" subfolder etc.)



Good luck ! (Contact: DoctorNoobingstoneIPresume at gmail dot com)

Taking arguments by value or by reference

[Anonymouse via Digitalmars-d-learn]

I'm passing structs around (collections of strings) whose .sizeof 
returns 432.


The readme for 2.094.0 includes the following:

This release reworks the meaning of in to properly support all 
those use cases. in parameters will now be passed by reference 
when optimal, [...]


* Otherwise, if the type's size requires it, it will be passed 
by reference.
Currently, types which are over twice the machine word size 
will be passed by
reference, however this is controlled by the backend and can be 
changed based

on the platform's ABI.


However, I asked in #d a while ago and was told to always pass by 
value until it breaks, and only then resort to ref.


[18:32:16]  at what point should I start passing my 
structs by ref rather than by value? some are nested in others, 
so sizeofs range between 120 and 620UL

[18:33:43]  when you start getting stack overflows
[18:39:09]  so if I don't need ref for the references, 
there's no inherent merit to it unless I get in trouble without 
it?

[18:39:20]  pretty much
[18:40:16]  in many cases the copying is merely 
theoretical and doesn't actually happen when optimized


I've so far just been using const parameters. What should I be 
using?

Re: Whats going on with this?

[Daniel Kozak via Digitalmars-d-learn]

On Sat, Oct 3, 2020 at 11:30 PM Steven Schveighoffer via
Digitalmars-d-learn  wrote:

>
>
> "StructMemberInitializers with the NonVoidInitializer syntax appear in
> the lexical order of the fields in the StructDeclaration" seems to
> suggest it will not call the constructor, but instead initialize the
> fields according to the list.
>
> The fields are not a static array, so clearly it is calling the
> constructor, and not initializing the fields.
>
> I really don't think this case is in the spec.
>
> But I know it works, for instance:
>
> Variant v = anything;
>
> If this required an explicit Variant constructor, it would be quite
> annoying.
>
> -Steve
>

Yes you are right

Re: Whats going on with this?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/3/20 4:46 PM, Daniel Kozak wrote:



On Sat, Oct 3, 2020 at 10:40 PM Daniel Kozak > wrote:


I would say it is here you just need to read it carefully:

https://dlang.org/spec/struct.html#static_struct_init


For case specification is change I will paste it here:
'''
If a StructInitializer is supplied, the fields are initialized by the 
StructMemberInitializer syntax. StructMemberInitializers with the 
Identifier : NonVoidInitializer syntax may be appear in any order, where 
Identifier is the field identifier. StructMemberInitializers with the 
NonVoidInitializer syntax appear in the lexical order of the fields in 
the StructDeclaration.

'''

And StructMemberInitializer is defined as:

'''
StructMemberInitializer:
     NonVoidInitializer
     Identifier : NonVoidInitializer
'''

And NonVoidInitializer is defined as:

'''
NonVoidInitializer:
     ExpInitializer
     ArrayInitializer
     StructInitializer
'''

And as you can see there is ArrayInitializer

And there is definition of Array literals here
https://dlang.org/spec/expression.html#array_literals

and in section 2. there is this text:

'''
By default, an array literal is typed as a dynamic array, but the 
element count is known at compile time. So all array literals can be 
implicitly converted to static array types.

'''


"StructMemberInitializers with the NonVoidInitializer syntax appear in 
the lexical order of the fields in the StructDeclaration" seems to 
suggest it will not call the constructor, but instead initialize the 
fields according to the list.


The fields are not a static array, so clearly it is calling the 
constructor, and not initializing the fields.


I really don't think this case is in the spec.

But I know it works, for instance:

Variant v = anything;

If this required an explicit Variant constructor, it would be quite 
annoying.


-Steve

Re: Whats going on with this?

[Daniel Kozak via Digitalmars-d-learn]

On Sat, Oct 3, 2020 at 10:40 PM Daniel Kozak  wrote:

> I would say it is here you just need to read it carefully:
>
> https://dlang.org/spec/struct.html#static_struct_init
>
>
For case specification is change I will paste it here:
'''
If a StructInitializer is supplied, the fields are initialized by the
StructMemberInitializer syntax. StructMemberInitializers with the
Identifier : NonVoidInitializer syntax may be appear in any order, where
Identifier is the field identifier. StructMemberInitializers with the
NonVoidInitializer syntax appear in the lexical order of the fields in the
StructDeclaration.
'''

And StructMemberInitializer is defined as:

'''
StructMemberInitializer:
NonVoidInitializer
Identifier : NonVoidInitializer
'''

And NonVoidInitializer is defined as:

'''
NonVoidInitializer:
ExpInitializer
ArrayInitializer
StructInitializer
'''

And as you can see there is ArrayInitializer

And there is definition of Array literals here
https://dlang.org/spec/expression.html#array_literals

and in section 2. there is this text:

'''
By default, an array literal is typed as a dynamic array, but the element
count is known at compile time. So all array literals can be implicitly
converted to static array types.
'''

Re: Whats going on with this?

[Daniel Kozak via Digitalmars-d-learn]

On Sat, Oct 3, 2020 at 4:45 PM Steven Schveighoffer via Digitalmars-d-learn
 wrote:

> On 10/3/20 6:52 AM, claptrap wrote:
> > On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer wrote:
> >> On 10/2/20 7:28 PM, claptrap wrote:
> >>
> >>> Why would putting in the writeln cause it to fail? Is it maybe trying
> >>> to create the foo at compile time?
> >>>
> >>
> >> Yes, it is. Any static initialization of static variables happens at
> >> compile-time.
> >>
> >> https://dlang.org/spec/declaration.html#global_static_init
> >>
> >
> > Ah.. ok, any idea why this works?
> >
> > Foo foo = [300,300];
>
> Yeah, it's calling the constructor. I agree with Adam, there's nothing
> in the spec that talks about this that I can find.
>
> -Steve
>

I would say it is here you just need to read it carefully:

https://dlang.org/spec/struct.html#static_struct_init

Re: How to hide a function return type in order to wrap several functions into an associated array?

[tastyminerals via Digitalmars-d-learn]

On Sunday, 27 September 2020 at 20:03:21 UTC, Paul Backus wrote:
On Sunday, 27 September 2020 at 18:54:11 UTC, tastyminerals 
wrote:

[...]


You can use an Algebraic [1] or SumType [2] for this:

alias Feature = SumType!(ulong, double, bool);

Feature numberOfPunctChars(string text)
{
// ...
return Feature(cnt);
}

Feature ratioOfDigitsToChars(string text)
{
// ...
return Feature(ratio);
}

Feature hasUnbalancedParens(string text)
{
// ...
return Feature(!isBalanced);
}

[1] 
http://dpldocs.info/experimental-docs/std.variant.Algebraic.html

[2] https://code.dlang.org/packages/sumtype


Nice, thanks. Never used it, shall take a look.

Re: How to hide a function return type in order to wrap several functions into an associated array?

[tastyminerals via Digitalmars-d-learn]

On Sunday, 27 September 2020 at 22:55:14 UTC, Ali Çehreli wrote:

On 9/27/20 11:54 AM, tastyminerals wrote:

> [...]
input, a string.
> [...]
function does
> [...]

[...]


Thank you. Quite an inspirational example with delegates.

Re: static foreach over constant range in @nogc block

[tspike via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 14:19:27 UTC, Paul Backus wrote:

On Saturday, 3 October 2020 at 14:17:45 UTC, tspike wrote:

On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote:

https://issues.dlang.org/show_bug.cgi?id=18439


Perfect! Thanks for getting back to me so quickly.


FYI I am not Timon Gehr, the person who originally replied to 
you, but I was able to find the bug report by searching 
Bugzilla for "static foreach nogc".


Sorry about getting your name wrong, I got a little overzealous 
when snipping off the quoted part of my post! If I find anything 
else I think might be a bug I'll have to try searching Bugzilla 
before I ask about it on the forums. Thanks again for your help, 
I'm amazed at how fast everyone is to help out here!

Re: Getting Field Names of a specific UDA in compile time.

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/3/20 10:16 AM, realhet wrote:


I tried it to put into a function:

auto getSymbolNamesByUDA(T, string uda)(){
     string[] res;
     static foreach(a; getSymbolsByUDA!(T, uda)) res ~= a.stringof;
     return res;
}


D __traits give you strings, the std.traits thing is giving you symbols. 
Don't use it, just use the compiler traits:


// note, not tested
auto getSymbolNamesByUDA(T, string uda)(){
 string[] res;
 static foreach(n; __traits(allMembers, T)) {
// static, but don't use static foreach so you can break
foreach(u; __traits(getAttributes, __traits(getMember, T, n))
   static if(is(typeof(u) == string) && u == uda) {
   res ~= n;
   break;
   }
 }
 return res;
}

-Steve

Re: Whats going on with this?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/3/20 6:52 AM, claptrap wrote:

On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer wrote:

On 10/2/20 7:28 PM, claptrap wrote:

Why would putting in the writeln cause it to fail? Is it maybe trying 
to create the foo at compile time?




Yes, it is. Any static initialization of static variables happens at 
compile-time.


https://dlang.org/spec/declaration.html#global_static_init



Ah.. ok, any idea why this works?

Foo foo = [300,300];


Yeah, it's calling the constructor. I agree with Adam, there's nothing 
in the spec that talks about this that I can find.


-Steve

Re: static foreach over constant range in @nogc block

[tspike via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote:

https://issues.dlang.org/show_bug.cgi?id=18439


Perfect! Thanks for getting back to me so quickly.

Re: static foreach over constant range in @nogc block

[Paul Backus via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 14:17:45 UTC, tspike wrote:

On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote:

https://issues.dlang.org/show_bug.cgi?id=18439


Perfect! Thanks for getting back to me so quickly.


FYI I am not Timon Gehr, the person who originally replied to 
you, but I was able to find the bug report by searching Bugzilla 
for "static foreach nogc".

Re: Getting Field Names of a specific UDA in compile time.

[realhet via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 14:00:30 UTC, Adam D. Ruppe wrote:

On Saturday, 3 October 2020 at 13:10:31 UTC, realhet wrote:
I only managed to get the string[] by making a static foreach, 
but I don't know how to put that in an enum xxx = ...; 
statement.


There's always other ways but general rule: if you can get it 
one way, just wrap that up in a function and call that function 
for your enum initializer.


string[] your_function() {
 // implementation here you already have
 return it;
}

enum NodeNames = your_function();


Though with arrays btw `static immutable` tends to give better 
results than `enum` since it avoids extra allocations.


I tried it to put into a function:

auto getSymbolNamesByUDA(T, string uda)(){
string[] res;
static foreach(a; getSymbolsByUDA!(T, uda)) res ~= a.stringof;
return res;
}

class Printer{
@("NODES") int gem1, gem2, gem3, gem4, gem5, head1, head2, 
head3, head4;

alias Nodes = getSymbolsByUDA!(typeof(this), "NODES");
enum NodeNames = getSymbolNamesByUDA!(typeof(this), "NODES");
}

void main(){
static foreach(n; Printer.Nodes) n.stringof.writeln;
Printer.NodeNames.writeln;
}

Up until this point, the alias declaration was before the enum 
declaration.

It gives an error:
Error: unknown, please file report on issues.dlang.org

But now I tried to comment out the alias declaration and it 
worked. It also works when I put the alias declaration after the 
enum:

enum NodeNames = getSymbolNamesByUDA!(typeof(this), "NODES");
alias Nodes = getSymbolsByUDA!(typeof(this), "NODES");

Same behavior with "static immutable".
My initial intention was to use the Nodes alias to get the name 
strings out of it. Now it needs more copy paste but it works.


This is weird o.O

Thank you!

Re: static foreach over constant range in @nogc block

[Paul Backus via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 14:02:08 UTC, tspike wrote:

On Saturday, 3 October 2020 at 12:43:01 UTC, Timon Gehr wrote:


It's a compiler bug, the same as this one:

@nogc:
void main(){
static immutable x = { int[] a; a~=1; return a; }();
}


Ah, thank you for the quick reply! Do you know if this bug has 
already been reported?


https://issues.dlang.org/show_bug.cgi?id=18439

Re: Getting Field Names of a specific UDA in compile time.

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 13:10:31 UTC, realhet wrote:
I only managed to get the string[] by making a static foreach, 
but I don't know how to put that in an enum xxx = ...; 
statement.


There's always other ways but general rule: if you can get it one 
way, just wrap that up in a function and call that function for 
your enum initializer.


string[] your_function() {
 // implementation here you already have
 return it;
}

enum NodeNames = your_function();


Though with arrays btw `static immutable` tends to give better 
results than `enum` since it avoids extra allocations.

Re: static foreach over constant range in @nogc block

[tspike via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 12:43:01 UTC, Timon Gehr wrote:


It's a compiler bug, the same as this one:

@nogc:
void main(){
static immutable x = { int[] a; a~=1; return a; }();
}


Ah, thank you for the quick reply! Do you know if this bug has 
already been reported?

Getting Field Names of a specific UDA in compile time.

[realhet via Digitalmars-d-learn]

Hi,

class Printer{
  @("NODES") int gem1, gem2, gem3, gem4, gem5, head1, head2, 
head3, head4;


  import std.traits, std.meta;
  alias Nodes = getSymbolsByUDA!(typeof(this), "NODES");
  enum NodeNames = ["gem1", "gem2", ];
}

Is there a way to make an enum like the above with compile time 
programming?
I only managed to get the string[] by making a static foreach, 
but I don't know how to put that in an enum xxx = ...; statement.

Re: static foreach over constant range in @nogc block

[Timon Gehr via Digitalmars-d-learn]

On 03.10.20 13:18, tspike wrote:
I came across an issue recently that I’m a little confused by. The 
following program fails to compile under LDC and DMD, though it compiles 
fine under GDC:


     @nogc:

     void main()
     {
     static foreach(i; 0 .. 4)
     {
     pragma(msg, i);
     }
     }

Both DMD and LDC report the following error if I try to compile it:

     test.d(7): Error: cannot use operator ~= in @nogc delegate 
test.main.__lambda1


I was just wondering, is this is a compiler bug or is there a reason I'm 
overlooking preventing this sort of code from compiling?


It's a compiler bug, the same as this one:

@nogc:
void main(){
static immutable x = { int[] a; a~=1; return a; }();
}

Re: Whats going on with this?

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 2 October 2020 at 23:28:04 UTC, claptrap wrote:
I cant see anything in the struct docs explaining why that 
array on the right hand side is automatically converted to a 
constructor call.


I'm not sure exactly where it is in the docs but that's perfectly 
normal.


Any declaration with initialization of a struct is turned into a 
construction call if it can. If not, it tries to treat it as a 
struct literal.


I guess this is as close as it comes:
https://dlang.org/spec/struct.html#struct-constructor

"Struct constructors are used to initialize an instance of a 
struct when a more complex construction is needed than is allowed 
by static initialization or a struct literal. "


Which sends you back up here:
https://dlang.org/spec/struct.html#static_struct_init

showing the = syntax.


opAssign is only used AFTER the struct has already been declared.

Re: vibe.d / experience / feedback

[Robert M . Münch via Digitalmars-d-learn]

On 3 Oct 2020 at 13:14:57 CEST, "0xEAB"  wrote:

> On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:
>>  On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin 
>>  wrote:
>>>  Because standard implementation worse?
>> 
>>  What do you mean with "worse"?
> 
> It's said to be pretty slow…

Well, then it should be fixed... it doesn't make sense to spread N version
because everyone things, A or B is not fitting for such a code framework. 

And, this argument sounds like pre-mature optimization. Who has a real life
use-case where the std lib JSON thing is too slow? By how much?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

static foreach over constant range in @nogc block

[tspike via Digitalmars-d-learn]

I came across an issue recently that I’m a little confused by. 
The following program fails to compile under LDC and DMD, though 
it compiles fine under GDC:


@nogc:

void main()
{
static foreach(i; 0 .. 4)
{
pragma(msg, i);
}
}

Both DMD and LDC report the following error if I try to compile 
it:


test.d(7): Error: cannot use operator ~= in @nogc delegate 
test.main.__lambda1


I was just wondering, is this is a compiler bug or is there a 
reason I'm overlooking preventing this sort of code from 
compiling?

Re: vibe.d / experience / feedback

[0xEAB via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:
On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin 
wrote:

Because standard implementation worse?


What do you mean with "worse"?


It's said to be pretty slow…

Re: Whats going on with this?

[claptrap via Digitalmars-d-learn]

On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer 
wrote:

On 10/2/20 7:28 PM, claptrap wrote:

Why would putting in the writeln cause it to fail? Is it maybe 
trying to create the foo at compile time?




Yes, it is. Any static initialization of static variables 
happens at compile-time.


https://dlang.org/spec/declaration.html#global_static_init

-Steve


Ah.. ok, any idea why this works?

Foo foo = [300,300];

Tbh I though I'd defined opAssign to take an array, and was just 
seeing if it worked, but I hadn't and it seems it's calling the 
constructor that takes an array, but I cant see in the docs why 
the above code gets converted to a constructor call.

Re: vibe.d / experience / feedback

[Martin via Digitalmars-d-learn]

On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote:

Because standard implementation worse?


What do you mean with "worse"?
In my experience std.json is a very thin implementation of the 
JSON spec - without/very low "magic". IMO this is what one wants 
in a std lib. Its a good starting point for further simplfication 
wrappers or framework specific magic (what vibe actually do, if i 
am not mistaken