Re: question as to when a new command gets executed
On Wednesday, 11 November 2020 at 22:29:00 UTC, SealabJaster wrote: On Wednesday, 11 November 2020 at 22:10:38 UTC, WhatMeWorry wrote: Thanks. Would you or anyone reading this know if this is unique to D or does C++ also behave like this? Also, where is the memory, that new allocates? Is it in the heap (thought heap was available only at runtime) or some other place? (Certainly not the stack, right?) I'm pretty sure this is the way it works in C# as well. C# isn't compile time, it is more a pre-constructor generated by the compiler.
Re: question as to when a new command gets executed
On Wednesday, 11 November 2020 at 22:10:38 UTC, WhatMeWorry wrote: Thanks. Would you or anyone reading this know if this is unique to D or does C++ also behave like this? Also, where is the memory, that new allocates? Is it in the heap (thought heap was available only at runtime) or some other place? (Certainly not the stack, right?) I'm pretty sure this is the way it works in C# as well.
Re: question as to when a new command gets executed
On Wednesday, 11 November 2020 at 22:10:38 UTC, WhatMeWorry wrote: Also, where is the memory, that new allocates? It is in the executable's static data block, just like if you declared a static array in the global space. I think this is D specific but I'm not sure about that.
Re: question as to when a new command gets executed
On Wednesday, 11 November 2020 at 06:21:38 UTC, Jacob Carlborg
wrote:
On 2020-11-11 06:29, WhatMeWorry wrote:
Which begs the question, how would the statement, m_State =
new BreakState() ever get executed?
class DebuggerSession
{
private BreakState m_State = new BreakState();
private UnrealCallback m_UnrealCallback;
this( )
{
}
// rest of class
}
It gets executed at compile time. All instances of
`DebuggerSession` will share the same single instance of
`BreakState`.
Thanks. Would you or anyone reading this know if this is unique
to D or does C++ also behave like this? Also, where is the
memory, that new allocates? Is it in the heap (thought heap was
available only at runtime) or some other place? (Certainly not
the stack, right?)
Re: Two "references" to dynamic array, why not change both when reallocating?
On Wednesday, 11 November 2020 at 13:30:16 UTC, Simen Kjærås wrote: The short answer is 'because that's how we've chosen to define it'. A more involved answer is that changing every reference is prohibitively expensive - it would require the equivalent of a GC collection on every reallocation, as references to the array could exist anywhere in the program, be that on the stack, heap, even on other threads. That's the performance side of it. No... Not true. But either way, D and Golang only have simple windows onto memory rather than dynamic array ADTs. That is bad for correctness, static analysis and ownership modelling. A simple choice, plausible for libraries, but bad for application code. If D is going to support non-GC code well, it has to change this. C++ got this right btw, where slices can only decrease in size. Then again, extending arrays is generally a bad idea for performance in all languages... So try to avoid increasing size after initial building.
Re: Two "references" to dynamic array, why not change both when reallocating?
Alright, thanks for sharing this thoughts and arguments!
Re: scope front vs [0]
Or similar problem:
class Foo{}
struct Slice{
Foo[] data;
this(return scope Foo[] data)@safe {
this.data = data;
}
Slice opSlice()@safe return scope{
return Slice(data);
}
Foo opIndex(size_t i)@safe return scope{
return data[i];
}
}
void main()@safe{
Foo foo;
scope Slice slice = Slice([new Foo]);
foo = slice[][0]; //OK, Why?
foo = slice[].opIndex(0); //Error: scope variable slice
assigned to foo with longer lifetime
}
scope front vs [0]
Hello,
Why does expression 'foo = bars[][0].foo' work but 'foo =
bars[].front.foo' doesn't?
example:
class Foo{}
struct Bar{
Foo foo;
}
void main()@safe{
import std;
Foo foo;
scope Bar[] bars = [Bar.init];
foo = bars[][0].foo;//OK, WHY?
foo = bars[].front.foo; //Error: scope variable bars
assigned to foo with longer lifetime
}
Re: Is there a similar library to FreeMarker like in Java
On Wednesday, 11 November 2020 at 08:13:23 UTC, Namal wrote: Hello, I want to do a small project but I need a text replacement tool/lib like Apache's FreeMarker. Is there something similar for D? Thx Maybe not so powerful but useful: mustache-d
Re: Two "references" to dynamic array, why not change both when reallocating?
On Wednesday, 11 November 2020 at 10:17:09 UTC, zack wrote: I am new to D. Appending to an array can lead to reallocation, that's clear. But why is the "reference" b not changed accordingly to the new position and still points to "old" memory? Why is b not also changed when reallocating array a and the old data getting invalid/freed? auto a = [55,10,20]; auto b = a; a ~= [99,99,99,99,99,99]; a[0] = 1; assert(b[0] == 1); // could fail (similar to p.103-104 in "The D Programming language") The short answer is 'because that's how we've chosen to define it'. A more involved answer is that changing every reference is prohibitively expensive - it would require the equivalent of a GC collection on every reallocation, as references to the array could exist anywhere in the program, be that on the stack, heap, even on other threads. That's the performance side of it. Another heavy argument is 'can you make it behave the other way?' Currently, that's simple: use a pointer to a slice (T[]*), and share that around. I don't see how I would get the current behavior if reallocation caused reassignment of all references (though admittedly I haven't thought too much about it). Next up: does b, ending on the same element as a, refer to the whole length of a (i.e. should b's length be reassigned when a is reallocated?), or is it a slice only referencing the first three elements? Either choice is going to be unexpected in some cases. All in all, there's many reasons to choose the behavior D has chosen. There are some drawbacks, but I feel it's the right choice. -- Simen
Re: C++ or D?
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote: I haven't looked into the newest C++. In theory, they might have added something helpful in the past years. I guess you could say that the latest version of C++ allows you to write code that is a little bit less verbose than before. C++ itself won't really change drastically because of backwards compatibility. In my opinion it is not a suitable language for hobbyists, as you need to spend a lot of time with it (measured in years) to become proficient... and basically, if you don't use C++ on a regular basis, there are details that are easy to forget. D has some of those issues too, but D can be used more like a high level language.
Re: Two "references" to dynamic array, why not change both when reallocating?
On Wednesday, 11 November 2020 at 10:17:09 UTC, zack wrote: I am new to D. Appending to an array can lead to reallocation, that's clear. But why is the "reference" b not changed accordingly to the new position and still points to "old" memory? Why is b not also changed when reallocating array a and the old data getting invalid/freed? auto a = [55,10,20]; auto b = a; a ~= [99,99,99,99,99,99]; a[0] = 1; assert(b[0] == 1); // could fail (similar to p.103-104 in "The D Programming language") `b` is not a "reference" to `a`. Consider that under the hood, an array is a pointer/length pair. `b = a` means that `b` is initialized such that `b.length == a.length` and `b.ptr == a.ptr`. Now when you append to `a`, one of two things can happen: 1. there's no allocation, in which case `a.length != b.length` and `a.ptr == b.ptr`. 2. there's a reallocation, in which case `a.length != b.length` and `a.ptr != b.ptr`. And when you append to `b`, it can also reallocate and `a` will not be affected.
Re: How to get address of a nested function?
On Tuesday, 10 November 2020 at 20:13:30 UTC, Daniel Kozak wrote:
non static nested function is a delegate, so you can just
assign it to delegate like I have posted or you can du this:
import std.stdio;
void main() {
void foo() {
writeln("It works as expected");
}
enum pfoo =
void delegate() dg;
dg.ptr = pfoo.ptr;
dg.funcptr = pfoo.funcptr;
dg();
}
I need the funcptr at *compile time*, just as I can do "enum p =
" for a non-static member function.
I wrote "weird" not because '&' returns a delegate, but because I
was surprised that we can have enum delegates at all, given that
delegates carry a context pointer, which is not known at compile
time. That is, the enum delegate appears to be some kind of alias
of the '&' expression.
Not that the issue is critical, but it makes a library I am
writing incomplete.
Two "references" to dynamic array, why not change both when reallocating?
I am new to D. Appending to an array can lead to reallocation, that's clear. But why is the "reference" b not changed accordingly to the new position and still points to "old" memory? Why is b not also changed when reallocating array a and the old data getting invalid/freed? auto a = [55,10,20]; auto b = a; a ~= [99,99,99,99,99,99]; a[0] = 1; assert(b[0] == 1); // could fail (similar to p.103-104 in "The D Programming language")
Is there a similar library to FreeMarker like in Java
Hello, I want to do a small project but I need a text replacement tool/lib like Apache's FreeMarker. Is there something similar for D? Thx
