Re: Can I rely on format returned by fullyQualifiedName?
On Saturday, 24 April 2021 at 03:40:20 UTC, Jack wrote:
Can I rely on this format from fullyQualifiedName? for example,
let's say I do:
```d
enum s = fullyQualifiedName!f.split;
```
where f is a function member of a class. Can I realy that s[0]
is the module name, s[1] is the class name and s[2] the functio
name? is this standard or can the compile change that? I've
tested on dmd, does ldc or gdc do something different?
You can rely on the order, but you cannot expect any of the names
to be at a specific index. The FQN includes the symbol's entire
hierarchy. So you could have one or more package names in front
of the module name. Essentially:
{all.package.names.}moduleName.{struct/class/functionName}.symbolName
Can I rely on format returned by fullyQualifiedName?
Can I rely on this format from fullyQualifiedName? for example,
let's say I do:
```d
enum s = fullyQualifiedName!f.split;
```
where f is a function member of a class. Can I realy that s[0] is
the module name, s[1] is the class name and s[2] the functio
name? is this standard or can the compile change that? I've
tested on dmd, does ldc or gdc do something different?
```d
class A
{
void f() { }
void baa()
{
enum s = fullyQualifiedName!f.split;
}
}
```
Re: When should I use SortedRange.release?
On Friday, 23 April 2021 at 21:34:39 UTC, Steven Schveighoffer wrote: `SortedRange` itself is kind of a kludge of "policy" that isn't fit for function. I use release to get the original data type out (via r.save.release), but that's about it. See my rant about it [here](https://forum.dlang.org/post/r7ia94$19uo$1...@digitalmars.com) -Steve Understood, thanks. --Bastiaan.
Re: When should I use SortedRange.release?
On 4/23/21 1:35 PM, Bastiaan Veelo wrote: For reference, `SortedRange.release` is [documented](https://dlang.org/phobos/std_range.html#.SortedRange) as such: "Releases the controlled range and returns it." Wow thanks! I love functions that are named exactly as what they do ;-) Seriously though, I still don't know what it is that it does, and why and when it should be done, and when not. What happens when a range is released? What happens if a range is not released? What happens if a range is released more than once? And what does "controlled" imply here? In what way has `SortedRange` control over the underlaying data? What can I do and what can't I do to the underlying data as long as `SortedRange` has control? My failure to understand this function makes me fear I don't understand `SortedRange` at all, and thereby don't understand how to use `algorithm.sorting` properly. `SortedRange` itself is kind of a kludge of "policy" that isn't fit for function. I use release to get the original data type out (via r.save.release), but that's about it. See my rant about it [here](https://forum.dlang.org/post/r7ia94$19uo$1...@digitalmars.com) -Steve
Re: When should I use SortedRange.release?
On Friday, 23 April 2021 at 18:35:25 UTC, Paul Backus wrote:
On Friday, 23 April 2021 at 17:35:13 UTC, Bastiaan Veelo wrote:
What happens when a range is released?
What happens if a range is not released?
What happens if a range is released more than once?
And what does "controlled" imply here? In what way has
`SortedRange` control over the underlaying data? What can I do
and what can't I do to the underlying data as long as
`SortedRange` has control?
I had to look at the source to figure this out. Fortunately,
the source is pretty simple:
https://phobos.dpldocs.info/source/std.range.d.html#L10833
Turns out, it just calls `core.lifetime.move`. So I guess when
the docs say "control", what they are really talking about is
ownership.
Practically speaking, this means that in generic code, we
should avoid using a `SortedRange` after calling `release`,
since we do not know whether the range is owning or non-owning
w.r.t. the underlying data.
Thanks. There is no word in the documentation about when
`SortedRange` would or would not be owning data, though, and
hence when `release` would be appropriate to call. To me
`release` seems to be calling `std.algorithm.mutation.move` , but
it is probably very similar to `core.lifetime.move`.
In case the underlying data is a slice, I think we end up at
https://phobos.dpldocs.info/source/std.algorithm.mutation.d.html#L1459, which I can't see accomplishes anything in [this example](https://dlang.org/phobos/std_algorithm_sorting.html#.sort) (except returning the slice that went in):
```d
int[] array = [ 1, 2, 3, 4 ];
// sort in descending order
array.sort!("a > b");
writeln(array); // [4, 3, 2, 1]
// sort in ascending order
array.sort();
writeln(array); // [1, 2, 3, 4]
// sort with reusable comparator and chain
alias myComp = (x, y) => x > y;
writeln(array.sort!(myComp).release); // [4, 3, 2, 1]
```
-- Bastiaan.
Re: When should I use SortedRange.release?
On Friday, 23 April 2021 at 17:35:13 UTC, Bastiaan Veelo wrote: What happens when a range is released? What happens if a range is not released? What happens if a range is released more than once? And what does "controlled" imply here? In what way has `SortedRange` control over the underlaying data? What can I do and what can't I do to the underlying data as long as `SortedRange` has control? I had to look at the source to figure this out. Fortunately, the source is pretty simple: https://phobos.dpldocs.info/source/std.range.d.html#L10833 Turns out, it just calls `core.lifetime.move`. So I guess when the docs say "control", what they are really talking about is ownership. Practically speaking, this means that in generic code, we should avoid using a `SortedRange` after calling `release`, since we do not know whether the range is owning or non-owning w.r.t. the underlying data.
When should I use SortedRange.release?
For reference, `SortedRange.release` is [documented](https://dlang.org/phobos/std_range.html#.SortedRange) as such: "Releases the controlled range and returns it." Wow thanks! I love functions that are named exactly as what they do ;-) Seriously though, I still don't know what it is that it does, and why and when it should be done, and when not. What happens when a range is released? What happens if a range is not released? What happens if a range is released more than once? And what does "controlled" imply here? In what way has `SortedRange` control over the underlaying data? What can I do and what can't I do to the underlying data as long as `SortedRange` has control? My failure to understand this function makes me fear I don't understand `SortedRange` at all, and thereby don't understand how to use `algorithm.sorting` properly. Thanks! -- Bastiaan.
Re: dlang opengl / gl / glu /glut library.
If i'm correct, sdl gives you a window opengl allows to draw in this window dlang allows to model the world with objects. "Needing a hello world :)"
Re: Iteratable single linked list of floats.
Here a working code,
```
import std.stdio;
void main(){
struct List {
struct Node {
float f;
Node *next=null;
}
Node * root=null;
bool empty() const {return !root;}
void popFront() {root=root.next;}
float front() const {return root.f;}
void pushfront(float f) {
Node * newnode=new Node();
newnode.f=f;
newnode.next=root;
root=newnode;
}
void pushend(float f){
Node * newnode=new Node();
newnode.f=f;
Node *t=root;
if(t==null)
{t=newnode;}
else{
while(t!=null && t.next!=null)
{t=t.next;}
t.next=newnode;
}
}
void printall(){
Node *l=root;
for( ; l ; l=l.next){
writeln(l.f);
}
}
}
List * l=new List();
l.pushfront(2);
l.pushfront(1);
l.pushend(3);
l.pushend(4);
foreach(element; *l) writeln(element);
(*l).printall();
```
Re: CTFE Assignment to anonymous union shows unexpected behavior
On 4/22/21 6:47 PM, Rekel wrote:
I'm not sure why this is happening, but after simplifying my code I
traced it back to what the title may suggest. The original cause of my
issues being summarized by debug print statements returning a union as:
Mat([nanf, nanF, . . . .], [[1.0F, 0.0F, . . . .])
Even though the nanF should thus be 1.0, 0.0, etc...
This is example code that describes when this happens:
```d
import std.stdio;
struct Apple(uint size) {
union {
int[size * size] a;
int[size][size] b;
}
static immutable typeof(this) pie = _pie();
private static typeof(this) _pie() pure {
typeof(this) result;
static foreach (i; 0 .. size)
static foreach (j; 0 .. size)
//result.a[i + j * size] = 1; // Works
result.b[i][j] = 1; // Fails
return result;
}
}
void main() {
Apple!(4) a = Apple!(4).pie;
writeln(a.a);
writeln(a.b);
}
```
The working code changes the first integers to 1, the failing version
keeps them at 0.
What's the reason for this? Logically this doesn't seem troublesome to
me, and if assigning to non-initial anonymous union varialbes isn't
possible(?!) that would be pretty bad, and I'd be in for quite some
trouble in my actual code :(
I think this is a bug. For sure, the only 2 valid options are, it should
compile and do what you are expecting, or not compile.
CTFE unions are (I think) implemented as a "tagged" union, where only
one value is set. When you assign to a *part* of b, you are assigning to
something that isn't being used.
Normally, in CTFE, using a union member that isn't set is an error
(compile-time because CTFE).
If you assign to b all at once, it works:
```d
private static typeof(this) _pie() pure {
typeof(this) result;
typeof(b) val;
static foreach (i; 0 .. size)
static foreach (j; 0 .. size)
val[i][j] = 1;
result.b = val;
return result;
}
```
I think the compiler is allowing the usage of a part of b without the
tag being updated. Probably the right answer is, setting an element of b
should be an error, or it should switch the tag (if the union was never
set).
BTW, I think the fact that the union members are arrays is important.
Please file a bug.
-Steve
Re: CTFE Assignment to anonymous union shows unexpected behavior
On Friday, 23 April 2021 at 10:36:40 UTC, Imperatorn wrote:
On Thursday, 22 April 2021 at 22:47:17 UTC, Rekel wrote:
I'm not sure why this is happening, but after simplifying my
code I traced it back to what the title may suggest. The
original cause of my issues being summarized by debug print
statements returning a union as:
[...]
Even though the nanF should thus be 1.0, 0.0, etc...
[...]
This actually seems to be a bug related to order of declaration.
Try this
---
union
{
int[size][size] b;
int[size * size] a;
}
---
Lol, formatting. But u get the idea *very* clearly at least
Re: CTFE Assignment to anonymous union shows unexpected behavior
On Thursday, 22 April 2021 at 22:47:17 UTC, Rekel wrote:
I'm not sure why this is happening, but after simplifying my
code I traced it back to what the title may suggest. The
original cause of my issues being summarized by debug print
statements returning a union as:
[...]
Even though the nanF should thus be 1.0, 0.0, etc...
[...]
This actually seems to be a bug related to order of declaration.
Try this
---
union
{
int[size][size] b;
int[size * size] a;
}
---
Re: CTFE Assignment to anonymous union shows unexpected behavior
On Friday, 23 April 2021 at 00:55:50 UTC, H. S. Teoh wrote: [...] If you read the field during CTFE. I've never tested initializing a union in CTFE then reading it at runtime, though. Not sure exactly what would happen in that case. T I'm not referring to reading non-initial variables, though Im surprised that's not possible? In any case, it seems assigning values doesn't work during CTFE either ... And that is very disappointing to me to be quite honest... This only seems to happen when I use CTFE to create a static singleton of the union by assigning to non-initial variables, I couldn't find anything in the docs that say I shouldn't, I might have missed something... I really hope this is a bug... if its not, & assuming its not inevitable, this really shouldn't be a thing. Be it by design or limitation.
Re: String concatenation segmentation error
On Thursday, 22 April 2021 at 21:15:48 UTC, tcak wrote: string fileContent = ""; ... [...] Do you have a minimal reproducible test case? 樂
