On Thursday, 5 January 2023 at 17:23:39 UTC, H. S. Teoh wrote:
On Thu, Jan 05, 2023 at 06:32:47AM +, areYouSureAboutThat
Also, I cannot read hex,
[...]
IMNSHO, anyone who claims to be a programmer should at least
know that much.
??
Well, like all, I learnt this at uni. .. as well as
On Thursday, 5 January 2023 at 05:59:26 UTC, Ali Çehreli wrote:
While we're here, you can force the class objects to be on the
stack as well:
scope MyClassVar1 = new MyClass();
I replaced 'auto' with 'scope'.
Ali
Very interesting. Thanks Ali.
ne this if you are privy to the
internal implementation details of the allocator or code that created
the reference (GC, other allocator, or whatever took an address of a
stack-allocated object), or the platform-specific details of your
runtime environment (range of stack addresses).
> Also, I cannot read hex
On Thursday, 5 January 2023 at 04:04:39 UTC, Paul wrote:
..
Do I have this much right?
...
First, i would say, add @safe to your main.
@safe void main() ...
Then you will see you are treading on dangerous waters ;-)
Second, to be sure your getting the correct results, it would be
nice if
On 1/4/23 20:04, Paul wrote:
>> (Again, there is no problem here; we are just learning.)
>> Ali
>
> Do I have this much right?
> ..with this output?
Looks good to me.
While we're here, you can force the class objects to be on the stack as
well:
scope MyClassVar1 = new MyClass();
I
(Again, there is no problem here; we are just learning.)
Ali
Do I have this much right?
```d
import std.stdio, std.traits;
class MyClass {char c;}
void main() {
auto MyInt = 1;
writeln("The address of MyInt is : ",," (stack)");
auto MyClassVar1 = new MyClass();
On 1/4/23 13:43, H. S. Teoh wrote:
> You do realize that the compiler is free to reorder local variables on
> the stack, right? ;-)
Of course. :)
I was trying different strategies to catch the compiler (dmd here) in a
single act of 8-byte object alignment as reported by .alignof.
A
On Wed, Jan 04, 2023 at 01:20:12PM -0800, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 1/4/23 12:02, Steven Schveighoffer wrote:
> > On 1/4/23 2:27 PM, Ali Çehreli wrote:
>
> >> I put the objects into a 2-length
> >> static array but the difference was still 0x20. (?)
> >
> > Are you putting
On 1/4/23 12:02, Steven Schveighoffer wrote:
> On 1/4/23 2:27 PM, Ali Çehreli wrote:
>> I put the objects into a 2-length
>> static array but the difference was still 0x20. (?)
>
> Are you putting the class *references* in a 2-length static array?
I lied. As I could not put the objects in a
On 1/4/23 2:27 PM, Ali Çehreli wrote:
On 1/4/23 10:48, H. S. Teoh wrote:
> Allocations are not necessarily consecutive; the GC may have its own
> strategy of allocation that doesn't follow a linear sequence.
That was one of my guesses. So, I put the objects into a 2-length static
array but
On 1/4/23 11:27, Ali Çehreli wrote:
> writeln("hidden 0: ", hiddenValue(addr, 0));
> writeln("hidden 1: ", hiddenValue(addr, 1));
Silly me! :) Those members have names:
writeln("__vptr : ", obj.__vptr);
writeln("__monitor : ", obj.__monitor);
mentation is 32 bytes.
I've just realized that I was confusing myself by thinking the object
pointer that cast(void*) produces was the first member's address. I was
wrong: That is the address of the first of the two hidden members (the
vtbl pointer and the monitor).
My current guess is, al
27202000 27727202020
> > ```
> > If my size is 17 bytes and my alignment is 8 bytes, shouldn't my
> > MyClassObj2 in this example be @ 277272020**18** ?
>
> Good question.
>
> I made some guesses about object layouts, GC allocation schemes, etc.
> but did not like
example be @ 277272020**18** ?
Good question.
I made some guesses about object layouts, GC allocation schemes, etc.
but did not like any of them.
Ali
matheus, using dmd64 on my laptop to compile and run this:
```d
import std.stdio, std.traits;
class MyClass {char[16] c;}
void main() {
writeln(" Size Alignment Type\n",
"=");
size_t size = __traits(classInstanceSize, MyClass);
size_t alignment
Thank you, Teoh, Ali, & Matheus
heus's values were 8 apart because that
compilation was 64 bits.
> So, I guess my question is actually how do I print out the addresses of
> the MyClassO1 & O2 objects themselves?
You must have missed my earlier answer: You need to cast the variable to
'void*'. That special operation will give
On Sunday, 1 January 2023 at 09:01:24 UTC, Paul wrote:
...
If the size of MyClass is 9 bytes why do MyClassO1 & O2
addresses only differ by 4 bytes?
Because those addresses(4FFB20 4FFB24) are the addresses of
the class **variables**, not the addresses of the **objects**
themselves?
Thanks all. Yes it seems my understanding and "D" vocabulary are
still a bit confused.
So I'm taking a D course online and was trying to verify what I
was learning. The course example printed out the size and
alignment of types...something close to this:
```d
import std.stdio;
import
On 12/31/22 16:35, Paul wrote:
> Can I acquire the address of a class object,
Answering that question literally, yes, you can by casting the class
variable to void*. But note: 'class object' means the instance of class
in D.
> not a class variable (i.e.
> the instantiations of the
On Sun, Jan 01, 2023 at 12:35:40AM +, Paul via Digitalmars-d-learn wrote:
> Hello. Thanks for any assistance.
>
> Can I acquire the address of a class object, not a class variable
> (i.e. the instantiations of the class) but the object definition
> itself?
>
> ```d
&g
Hello. Thanks for any assistance.
Can I acquire the address of a class object, not a class variable
(i.e. the instantiations of the class) but the object definition
itself?
```d
class MyClass {char c}
...
MyClass MyClassVar;
writeln(); // this compiles
writeln();// this does not
```
working
with objects that have memory management external to D.
I know you already solved the problem, but just for future
reference, if you use something like `RefCounted`, you can
avoid copying and destruction until everyone is done with the
object. This is how my io library works, the IO objects
already solved the problem, but just for future reference, if
you use something like `RefCounted`, you can avoid copying and
destruction until everyone is done with the object. This is how my io
library works, the IO objects are non-copyable, and you wrap them in
`RefCounted` if you want
On Sunday, 2 October 2022 at 18:24:51 UTC, Ali Çehreli wrote:
On 10/2/22 10:55, data pulverizer wrote:
> ```
> this(T)(ref return scope T original)
> if(is(T == RVector!(Type)))
> {
> //... code ...
> }
> ```
I've just tested. That is used only for explicit constructor
syntax:
auto
On Sunday, 2 October 2022 at 18:24:51 UTC, Ali Çehreli wrote:
I've just tested. That is used only for explicit constructor
syntax ...
Many thanks. Knowledgeable as always!
a; // non-templatized
Certainly confusing and potentially a bug... :/
> No idea why. `Type` is a template parameter of the object.
Minor convenience: You can replace all RVector!(Type) with just RVector
in the implementation of RVector because the name of the struct template
*is* th
or simpler, disallow
copying altogether.
Thanks for the advice, for a while now I didn't know what was
creating the issue.
The code I'm running is my D connector to the R API and for ages
I didn't know where the multiple destructor calls to allow an
object to be garbage collected by the R API
constructor):
```
this(T)(ref return scope T original)
if(is(T == RVector!(Type)))
{
//... code ...
}
```
But this now works:
```
this(ref return scope RVector!(Type) original)
{
//... code ...
}
```
No idea why. `Type` is a template parameter of the object.
d
'auto ref'. Hence the status quo...
> Sorry I'll need to implement all the overloaded copy constructors and
> see if that fixes it.
The best solution I know is to disable copying and printing not the
object but an explicit string representation of it:
Added:
@disable
On Sunday, 2 October 2022 at 17:19:55 UTC, data pulverizer wrote:
Any reason why this could be?
Sorry I'll need to implement all the overloaded copy constructors
and see if that fixes it.
On Sunday, 2 October 2022 at 16:44:25 UTC, Paul Backus wrote:
It's because `writeln` is copying the object, and each of the
copies is being destroyed. If you add a copy constructor to
your example, you can see it happening:
...
I thought something like this could be happening in my original
On Sunday, 2 October 2022 at 16:21:47 UTC, data pulverizer wrote:
I've noticed that `writeln` calls the destructor of a struct
multiple times and would like to know how to stop this from
happening.
It's because `writeln` is copying the object, and each of the
copies is being destroyed
appears to
have been called 4 times with one call of `writeln` before the
object actually goes out of scope:
Code:
```
import std.stdio: writeln;
struct MyObject
{
int id;
this(int id) @nogc
{
this.id = id;
}
~this()
{
writeln("Object destr
On Tuesday, 7 June 2022 at 13:56:23 UTC, Steven Schveighoffer
wrote:
So you are safe, it will see the pointer inside the array
reference, and see that it doesn't point at GC memory, so
nothing further will be done.
Thanks for the detailed explanation, and everyone who has replied.
owning object
...
}
```
So when `obj` is cleanup by the GC, obj.data won't be freed by the GC:
because the `data` is non-gc-allocated (and it's allocated on the non-gc
heap), the GC scanner will just skip that field during a collection
scan. Is this understanding correct?
Others have
On Tuesday, 7 June 2022 at 09:12:25 UTC, ag0aep6g wrote:
On 07.06.22 11:00, max haughton wrote:
On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote:
[...]
That wasn't mw's question.
I also answered this in my original one IIRC.
You didn't.
Ok I must have assumed it was obvious it
On 07.06.22 11:00, max haughton wrote:
On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote:
[...]
That wasn't mw's question.
I also answered this in my original one IIRC.
You didn't.
On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote:
On 07.06.22 03:02, max haughton wrote:
I'm talking about the data in the array.
void[] might contain pointers, float[] does not so it won't be
scanned.
That wasn't mw's question.
I also answered this in my original one IIRC. There's
On 07.06.22 03:02, max haughton wrote:
I'm talking about the data in the array.
void[] might contain pointers, float[] does not so it won't be scanned.
That wasn't mw's question.
On Tuesday, 7 June 2022 at 00:40:56 UTC, ag0aep6g wrote:
On 07.06.22 00:22, max haughton wrote:
float[] doesn't contain pointers, so the GC won't do anything
to or with it.
wat
float[] is a pointer (plus a length). The GC will deal with it
like any other pointer.
I'm talking about the
On 07.06.22 00:22, max haughton wrote:
float[] doesn't contain pointers, so the GC won't do anything to or with
it.
wat
float[] is a pointer (plus a length). The GC will deal with it like any
other pointer.
stdlib.malloc(nBytes)[0 .. nBytes]);
> }
> }
>
> void foo() {
> auto obj = new GCAllocated(); // gc-allocated owning object
> ...
> }
>
> ```
>
> So when `obj` is cleanup by the GC, obj.data won't be freed by the GC:
> because the `data` is non-gc-allocated (an
On Monday, 6 June 2022 at 22:24:45 UTC, Guillaume Piolat wrote:
My understanding is that while scanning, the GC will see the
data.ptr pointer, but will not scan the area it points to since
it's not in a GC range (the runtime can distinguish managed
pointer and other pointers).
After
On Monday, 6 June 2022 at 22:22:05 UTC, max haughton wrote:
float[] doesn't contain pointers, so the GC won't do anything
to or with it.
does every array have a .ptr attr?
https://dlang.org/spec/arrays.html
Dynamic Array Properties
.ptrReturns a pointer to the first element of the
On Monday, 6 June 2022 at 22:18:08 UTC, mw wrote:
So when `obj` is cleanup by the GC, obj.data won't be freed by
the GC: because the `data` is non-gc-allocated (and it's
allocated on the non-gc heap), the GC scanner will just skip
that field during a collection scan. Is this understanding
(); // gc-allocated owning object
...
}
```
So when `obj` is cleanup by the GC, obj.data won't be freed by
the GC: because the `data` is non-gc-allocated (and it's
allocated on the non-gc heap), the GC scanner will just skip
that field during a collection scan. Is this understanding
correct?
I
Hi,
Suppose I have this code:
```
class GCAllocated {
float[] data;
this() {
// non-gc-allocated field
this.data = cast(float[])(core.stdc.stdlib.malloc(nBytes)[0
.. nBytes]);
}
}
void foo() {
auto obj = new GCAllocated(); // gc-allocated owning object
...
}
```
So when
functions that traverses through all fields. Thx.
Not for classes. The compiler is free to reorder if it wants to.
Yes for structs.
To clarify, the compiler can reorder the members to fit them better. But
it will be the same order for any particular build of the object files.
Any compile
On Thursday, 27 January 2022 at 12:45:20 UTC, frame wrote:
Is the order of fields guaranteed returned by `.tupleof` and
`__traits(getMember,...)`, can I rely on this? I know that are
different things, I mean just per each use case if I have more
functions that traverses through all fields.
Is the order of fields guaranteed returned by `.tupleof` and
`__traits(getMember,...)`, can I rely on this? I know that are
different things, I mean just per each use case if I have more
functions that traverses through all fields. Thx.
files. Also
gcc -M/-MM does not compile while dmd always generated object
file(s), too. Is there any way to stop this object file
generation?
Yes, `-o-`. Not sure about `-MM` equivalent but if you manually
process the dependencies you can filter the "system" files out
anyway.
grep
On Tuesday, 4 January 2022 at 22:17:38 UTC, kdevel wrote:
Is there any chance to rephrase fsobjects.d such that it
becomes a "header only"/"compile only" file of which no object
file must be presented to the linker?
https://wiki.dlang.org/LDC-specific_language_chang
On 1/6/22 6:06 PM, kdevel wrote:
When you import this file, the compiler sees that it has imports, and
assumes you must have built the `ModuleInfo` in some object somewhere,
so it outputs a reference for the import graph.
Makes sense. It seems that if there are just type definitions with enum
generated object
file(s), too. Is there any way to stop this object file
generation?
Yes, `-o-`. Not sure about `-MM` equivalent but if you manually
process the dependencies you can filter the "system" files out
anyway.
I don't understand how your setup works. Is there a
this project.
The way D does this is to store the import graph inside a
`ModuleInfo` struct stored in the object.
When you import this file, the compiler sees that it has
imports, and assumes you must have built the `ModuleInfo` in
some object somewhere, so it outputs a reference for the import
On Thursday, 6 January 2022 at 02:37:41 UTC, frame wrote:
On Tuesday, 4 January 2022 at 22:17:38 UTC, kdevel wrote:
Is there any chance to rephrase fsobjects.d such that it
becomes a "header only"/"compile only" file of which no object
file must be presented to the linke
On 1/4/22 5:17 PM, kdevel wrote:
Is there any chance to rephrase fsobjects.d such that it becomes a
"header only"/"compile only" file of which no object file must be
presented to the linker?
Possibly. You see, you are importing another module. Since you are doing
t
On Tuesday, 4 January 2022 at 22:17:38 UTC, kdevel wrote:
Is there any chance to rephrase fsobjects.d such that it
becomes a "header only"/"compile only" file of which no object
file must be presented to the linker?
You didn't show how you compiled your files.
If y
In a project I have this "controller" function:
```
void create_fso (O) (Request req)
{
:
auto npathname = (extract name from req)
:
O.create (npathname);
:
}
public import fsobjects;
```
which creates a file system object. The possible object types I
collected in
Wow, several different approaches!
Thanks everyone, I find this discussion enriching.
I find `H. S. Teoh`'s template solution to be the closest to what
I need. It adds minimal complexity to the existing implementation.
On Tue, Jan 04, 2022 at 05:01:41PM +, Amit via Digitalmars-d-learn wrote:
> Hi!
>
> I wrote a text parser that takes a File argument and parses that
> file's contents. Now I would like to write a unit-test for that
> parser. I need a File (or a general IO interface) that reads from an
>
On 1/4/22 9:48 AM, Paul Backus wrote:
> On Tuesday, 4 January 2022 at 17:01:41 UTC, Amit wrote:
>> I need a File (or a general IO interface) that reads from an
>> in-memory buffer, similar to python's `StringIO` or go's
>> `strings.Reader`.
>>
>> How can I achieve that?
I don't think it exists
On Tuesday, 4 January 2022 at 17:01:41 UTC, Amit wrote:
Hi!
I wrote a text parser that takes a File argument and parses
that file's contents. Now I would like to write a unit-test for
that parser. I need a File (or a general IO interface) that
reads from an in-memory buffer, similar to
Hi!
I wrote a text parser that takes a File argument and parses that
file's contents. Now I would like to write a unit-test for that
parser. I need a File (or a general IO interface) that reads from
an in-memory buffer, similar to python's `StringIO` or go's
`strings.Reader`.
How can I
On Thursday, 23 September 2021 at 19:32:12 UTC, eugene wrote:
C (more elaborated) variant:
http://zed.karelia.ru/mmedia/bin/edsm-g2-rev-h.tar.gz
Sound, GUI? Easy, see
http://zed.karelia.ru/mmedia/bin/xjiss4.tar.gz
It's computer keyboard 'piano', based on the same engine.
As I've already
On Thursday, 23 September 2021 at 18:53:25 UTC, Steven
Schveighoffer wrote:
On 9/23/21 1:44 PM, eugene wrote:
Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are
received via epoll_wait().
Oh interesting! I didn't read the code
unregister the signal handler,
so it's run again, referencing the now-deleted object.
At this point we have default signal handler
5. segfault
It's theoretically a very very small window.
But even without destructor, no segfault will happen,
because **there is no signal handler**
So it gets
On Thursday, 23 September 2021 at 18:43:36 UTC, Steven
Schveighoffer wrote:
With dmd -O -inline, there is a chance it will be collected.
Inlining is key here.
never mind, GC.addRoot() looks more trustworthy, anyway :)
/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object
ineligible for garbage collection from the start of the routine to
the point, in execution order, where this method is called. Code this
method at the end, not the beginning, of the
"
This method references the obj parameter, making that object
ineligible for garbage collection from the start of the
routine to the point, in execution order, where this method is
called. Code this method at the end, not the beginning, of the
range of instructions where obj must be avai
On Thursday, 23 September 2021 at 17:53:00 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all
On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both
On Thursday, 23 September 2021 at 17:20:18 UTC, Steven
Schveighoffer wrote:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's
members
but both SIGINT and SIGTERM are still **blocked**,
they just will not reach
happens again, but you didn't unregister the signal
handler, so it's run again, referencing the now-deleted object.
At this point we have default signal handler
5. segfault
It's theoretically a very very small window.
But even without destructor, no segfault will happen,
because
. The segfault is
triggered by the signal handler referencing the destroyed object.
So imagine the sequence:
1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's members
4. ctrl-c happens again, but you didn't
On 9/23/21 12:58 PM, eugene wrote:
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object ineli
On Thursday, 23 September 2021 at 15:56:16 UTC, Steven
Schveighoffer wrote:
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
"
This method references the obj parameter, making that object
ineligible for garbage collection from the
On Thursday, 23 September 2021 at 15:53:37 UTC, Steven
Schveighoffer wrote:
Technically, they should live past the end of main, because
it's still possible to receive signals then.
No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and we do not need no
more notifications
suggested -- use the object later.
However, they are recognized by the compiler as an intrinsic which
generates no code or side effects, but is not subject to elimination by
the optimizer.
See more details:
https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks
On 9/23/21 10:55 AM, eugene wrote:
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was distracted by
the general solution of using object lifetimes with it, so that a
struct's destructor would call GC.removeRoot. For your case
On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:
Nice. I thought of GC.addRoot several times but I was
distracted by the general solution of using object lifetimes
with it, so that a struct's destructor would call
GC.removeRoot. For your case just pinning these and forgetting
On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:
And the most strange thing is this - if using gdc with -Os
flag, the program behaves
exactly as when compiled with fresh dmd - destructors for sg0
and sg1 are called soon after program start.
Now I guess, gdc optimization by size
);
Main.run();
auto stopper = new Stopper();
GC.addRoot(cast(void*)stopper);
stopper.run();
```
Fine, works!
Nice. I thought of GC.addRoot several times but I was distracted
by the general solution of using object lifetimes with it, so
that a struct's destructor would call
On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:
For the moment I am personally quite happy
```d
void main(string[] args) {
import core.memory : GC;
auto Main = new Main();
GC.addRoot(cast(void*)Main);
Main.run();
auto stopper = new Stopper();
On Thursday, 23 September 2021 at 13:30:42 UTC, eugene wrote:
So, in C it is MY (potentially wrong) code.
In D, it is NOT MY code, it is GC.
Actually in both cases it is MY+the compiler's code. A very
similar example from C-land (without my digging up the exact
details) is something like
way to do that (similar to C# KeepAlive). I made an
[attempt](https://code.dlang.org/packages/keepalive), but I
think it's not guaranteed to work, I've already found ways to
prove it fails.
For the moment I am personally quite happy
with any reasonable workaround
(use an object in the end of the main fun
On Thursday, 23 September 2021 at 13:05:07 UTC, Steven
Schveighoffer wrote:
UB in C leaves traps for the programmer, similar to this trap
you have found in the GC. Where code doesn't do what you are
expecting it to do.
There is a difference, though.
As I've already said,
GC is a sort of
On Thursday, 23 September 2021 at 12:53:14 UTC, Steven
Schveighoffer wrote:
Show me these rules!
They are here:
https://dlang.org/spec/interfaceToC.html#storage_allocation
With the caveat, of course, that the recommendation to "leave a
pointer on the stack" is not as easy to follow as one
On 9/23/21 8:10 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
I find it interesting how you blame yourself for C's idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
"When my C program crashes, I'm 100% sure I made
On 9/23/21 3:27 AM, eugene wrote:
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven Schveighoffer
wrote:
Your experience is not typical though (clearly, as many of us
long-time D users had no idea why it was happening).
Oh, yeah - I have special trait of bumping against
various low
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
I find it interesting how you blame yourself for C's
idiosyncrasies
Me? Blaming *myself* for C 'idiosyncrasies'? :) Where?
but not for D's ;)
I've been learning D for about 3 months only.
I would say C has far
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
But realize that C has it's share of "shocks" as well
Any language is just an instrument,
most of the 'shocks' come not from
languages themselves, but from the
'enviromment', so to say.
An example that came to
On Wednesday, 22 September 2021 at 18:38:34 UTC, Steven
Schveighoffer wrote:
In terms of any kind of memory management, whether it be ARC,
manual, GC, or anything else, there will always be pitfalls.
It's just that you have to get used to the pitfalls and how to
avoid them.
100% agree.
I
if this turns you off, I can understand how it can
be too frustrating to learn the new rules.
Show me these rules!
Always use an object at the end of a function?
Make a second reference to an object somewhere on the heap?
The 'problem' here is that there is no clear rule.
Any reasonable 'hack
On 9/22/21 11:47 AM, eugene wrote:
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven Schveighoffer
wrote:
On 9/22/21 8:22 AM, eugene wrote:
And it follows that programming in GC-supporting languages
*may* be harder than in languages with manual memory
management, right?
I meant my this
On Wednesday, 22 September 2021 at 12:26:53 UTC, Steven
Schveighoffer wrote:
On 9/22/21 8:22 AM, eugene wrote:
And it follows that programming in GC-supporting languages
*may* be harder than in languages with manual memory
management, right?
I meant my this particular trouble...
I do not want
On 9/22/21 8:22 AM, eugene wrote:
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven Schveighoffer
wrote:
Once it's on the stack, the GC can see it for the full run of `main`.
This is why this case is different.
Note that Java is even more aggressive, and might *still* collect it,
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Once it's on the stack, the GC can see it for the full run of
`main`. This is why this case is different.
Note that Java is even more aggressive, and might *still*
collect it, because it could legitimately set
On Wednesday, 22 September 2021 at 11:44:16 UTC, Steven
Schveighoffer wrote:
Here is what is happening.
Many thanks for this so exhaustive explanation!
101 - 200 of 1432 matches
Mail list logo
