Re: Why is sformat and formattedWrite (appender) allocating GC mem here?
On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote: I've made a pull request to get rid of those allocations: https://github.com/dlang/phobos/pull/7163 Thanks for the responses, very cool seeing these updates happen so fluidly.
Re: Quick question regarding dynamic array deletions
On Sunday, September 1, 2019 12:42:54 PM MDT Dennis via Digitalmars-d-learn
wrote:
> On Sunday, 1 September 2019 at 18:26:20 UTC, WhatMeWorry wrote:
> > Maybe my question is when would be want to use 3) without also
> > adjusting the .ptr ?
>
> It matters when casting to a boolean, since an empty array with a
> non-null pointer is still `true` while an array with null pointer
> casts to `false`. This could be useful when you want to
> distinguish 'no array' and an empty array.
>
> For example:
> ```
> int[] getList(); // might fail
>
> void main() {
>if (auto list = getList) {
> writeln(list); // could be an empty list
>} else {
> error("could not retrieve list"); // must be 'null' list
>}
> }
> ```
This is a difference, but it's also a rather error-prone approach. It's
rarely the case that it's a good idea to differentiate null from empty with
dynamic arrays, because too many operations don't treat them as different
from one another. There are people who do it, and it can work if you're very
careful, but it's very error-prone. That's also why using a dynamic array in
a boolean condition like this is a code smell. If you're reading someone
else's code that does this, unless there's a comment clarifying things, you
generally can't assume that it's working as intended, because the odds are
very high that the person who wrote the code misunderstood how dynamic
arrays work in boolean conditions. And even if you wrote the code and do
understand the difference, it's very easy to inadvertently end up with a
null array when you were previously getting an empty one or to end up with
an empty one where you were getting null.
Personally, about the only time that I would consider differentiating
dynamic arrays based on null would be when the dynamic array would be null,
because it would either have been returned as a null literal, or it would
have been a dynamic array which was only default-initialized - and even
then, I wouldn't do it if there were code in between the point of
initialization and the check which did much with the array beyond initialize
it, because the risk of getting null when you don't expect it is too high -
especially if other people are working on the code as well. And there are
plenty of people who would argue that Nullable should be used in such
situations rather than ever trying to distinguish between null and empty.
Certainly, I would argue that under normal circumstances, assigning null to
a dynamic array is what you should be doing rather than setting its length
to 0, because then, that reference to the dynamic array has been removed,
and that increases the chances of the GC being able to collect it. The
primary exception would be when you intend to set the length to 0 in
conjuction with using assumeSafeAppend so that you can reuse the memory, and
for that to be safe to do, you have to know that either no other dynamic
arrays referring to that block of memory exist or that they won't be used
again without first being given a new value.
- Jonathan M Davis
Re: Input/Output multiple values from function
On Sunday, 1 September 2019 at 20:42:28 UTC, Jabari Zakiya wrote: It still won't compile, with this error. Error: AliasSeq!(modpg, res_0, restwins, resinvrs) is not an lvalue and cannot be modified Here's a gist of the code. Top functions in code with issues are genPgParameters and selectPG https://gist.github.com/jzakiya/9227e4810e1bd5b4b31e949d1cbd5c5d You can't do multiple assignments at once using AliasSeq; you have to assign each variable individually: auto parameters = genPgParameters(pg); modpg = parameters[0]; res_0 = parameters[1]; restwins = parameters[2]; resinvrs = parameters[3];
Re: Input/Output multiple values from function
On Thursday, 29 August 2019 at 10:58:47 UTC, Simen Kjærås wrote:
On Thursday, 29 August 2019 at 10:39:44 UTC, Jabari Zakiya
wrote:
[...]
Great - then you can use shared(immutable(uint)[]). You should
be able to convert from immutable(uint[]) to that without
issue. There's a utility function in std.exception called
assumeUnique that can be used for conversion to immutable that
may be more informative than cast(immutable):
shared(uint) modpg;
shared(uint) res_0;
shared(immutable(uint)[]) restwins;
shared(immutable(uint)[]) resinvrs;
auto genPGparameters(int i) {
import std.typecons;
import std.exception;
// Showing both cast and assumeUnique:
return tuple(1u, 2u, cast(immutable)[3u],
[4u].assumeUnique);
}
unittest {
import std.meta : AliasSeq;
int pg;
// No need for temporaries:
AliasSeq!(modpg, res_0, restwins, resinvrs) =
genPGparameters(pg);
}
[...]
Correct - since there are no indirections in a uint, you can
assign directly to a shared(uint) - nobody else will have a
non-shared pointer to that uint, so it's somewhat safe. If you
do the same with uint[], you'll still have a pointer to the
same values, and changing a value that says it's thread-local
(no shared) will change values that is shared with the rest of
the program. There are some issues with the current shared
design, but this is what it's intended to do.
--
Simen
It still won't compile, with this error.
Error: AliasSeq!(modpg, res_0, restwins, resinvrs) is not an
lvalue and cannot be modified
Here's a gist of the code.
Top functions in code with issues are genPgParameters and selectPG
https://gist.github.com/jzakiya/9227e4810e1bd5b4b31e949d1cbd5c5d
Re: Quick question regarding dynamic array deletions
On Sunday, 1 September 2019 at 18:26:20 UTC, WhatMeWorry wrote:
Maybe my question is when would be want to use 3) without also
adjusting the .ptr ?
It matters when casting to a boolean, since an empty array with a
non-null pointer is still `true` while an array with null pointer
casts to `false`. This could be useful when you want to
distinguish 'no array' and an empty array.
For example:
```
int[] getList(); // might fail
void main() {
if (auto list = getList) {
writeln(list); // could be an empty list
} else {
error("could not retrieve list"); // must be 'null' list
}
}
```
Quick question regarding dynamic array deletions
int[] a = [ 3, 7, 9 ]; 1) a = []; and 2) a = null; sets both the .ptr property of the array to null, and the length to 0. whereas 3) a.length = 0; just sets the length to 0. If all the above is correct, does this mean we should just stick to either of the first two forms and never use 3). Maybe my question is when would be want to use 3) without also adjusting the .ptr ?
Re: problems with swig generated code
Do you know whether SWIG's D generator is even being maintained? I've searched for it on the forums in the past and got the impression that it's outdated.
Re: Java to D
On Saturday, 31 August 2019 at 16:44:01 UTC, Patrick wrote: On Wednesday, 28 August 2019 at 10:33:33 UTC, GreatSam4sure wrote: On Wednesday, 28 August 2019 at 09:35:55 UTC, Jacob Carlborg wrote: [...] Thanks i will check it up Take a look at JavacTo https://sourceforge.net/projects/javacto/ This is a java tool that uses the javac compiler to translate java to another language. And includes a java to D code set. It is a very visual tool and has great animation during translation and works well while using the java debugger. I include “How to get started with Eclipse”. You can find more translations statistics at this post: https://forum.dlang.org/thread/yuamvgsdfshgrbesm...@forum.dlang.org#post-yuamvgsdfshgrbesmjlt:40forum.dlang.org Hope this helps Patrick Thanks a lot. I will dive in soon. I am in the mid of a project now
