On Tuesday, 30 June 2020 at 06:16:26 UTC, Kagamin wrote:
On Saturday, 27 June 2020 at 14:49:34 UTC, James Gray wrote:
I have produced something which essentially reproduces my
problem.
What is the problem? Do you have a leak or you want to know how
GC works?
I have managed to resolve my
On Saturday, 27 June 2020 at 14:49:34 UTC, James Gray wrote:
I have produced something which essentially reproduces my
problem.
What is the problem? Do you have a leak or you want to know how
GC works?
On Saturday, 27 June 2020 at 14:49:34 UTC, James Gray wrote:
On Saturday, 27 June 2020 at 14:12:09 UTC, kinke wrote:
[...]
Thank you for doing this. I hope my example doesn't obscure
what you show here.
(I borrowed some of your code).
[...]
In case it helps, setting all the next and
On Saturday, 27 June 2020 at 16:03:12 UTC, kinke wrote:
On Saturday, 27 June 2020 at 15:27:34 UTC, Stanislav Blinov
wrote:
Hrm... What happens if you call collect() twice?
Nothing changes, even when collecting 5 times at the end of
each iteration. In the filed testcase, I've extracted the
On Saturday, 27 June 2020 at 15:27:34 UTC, Stanislav Blinov wrote:
On Saturday, 27 June 2020 at 14:12:09 UTC, kinke wrote:
Note that I explicitly clear the `str` slice before
GC.collect(), so that the stack shouldn't contain any refs to
the fat string anymore.
Hrm... What happens if you
On Saturday, 27 June 2020 at 14:12:09 UTC, kinke wrote:
Note that I explicitly clear the `str` slice before
GC.collect(), so that the stack shouldn't contain any refs to
the fat string anymore.
Hrm... What happens if you call collect() twice?
On Saturday, 27 June 2020 at 14:12:09 UTC, kinke wrote:
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
have run into a memory leak
Something seems really off indeed. I've run this on Win64 with
DMD (2.092) and LDC (1.22), without any extra cmdline options:
-
import
=> https://issues.dlang.org/show_bug.cgi?id=20983
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
have run into a memory leak
Something seems really off indeed. I've run this on Win64 with
DMD (2.092) and LDC (1.22), without any extra cmdline options:
-
import core.memory;
import core.stdc.stdio;
import std.range;
import
On Saturday, 27 June 2020 at 12:07:19 UTC, Stanislav Blinov wrote:
On Saturday, 27 June 2020 at 11:35:12 UTC, Arafel wrote:
If you are using linux, have in mind that the memory is often
not returned to the OS even after a (libc) free.
That's a good observation. Although a GC implementation
On Saturday, 27 June 2020 at 12:53:01 UTC, James Gray wrote:
On Saturday, 27 June 2020 at 12:07:19 UTC, Stanislav Blinov
wrote:
On Saturday, 27 June 2020 at 11:35:12 UTC, Arafel wrote:
[...]
That's a good observation. Although a GC implementation is not
required to actually use malloc, so
On Saturday, 27 June 2020 at 11:35:12 UTC, Arafel wrote:
If you are using linux, have in mind that the memory is often
not returned to the OS even after a (libc) free.
That's a good observation. Although a GC implementation is not
required to actually use malloc, so depending on that falls
On 27/6/20 13:21, Stanislav Blinov wrote:
I would think collect + minimize should do the trick. Just keep in mind
that that's grossly inefficient.
If you are using linux, have in mind that the memory is often not
returned to the OS even after a (libc) free. If you check with tools
like
On Saturday, 27 June 2020 at 11:11:38 UTC, James Gray wrote:
I am measuring the memory usage using top from the command line.
GC.minimize() does seem to stop the leak.
That is not a memory leak. That's the allocator keeping pages for
itself to not have to go to the kernel every time you
On Saturday, 27 June 2020 at 11:11:38 UTC, James Gray wrote:
I am measuring the memory usage using top from the command line.
GC.minimize() does seem to stop the leak. But it doesn't
explain why
the program isn't releasing essentially all the memory between
calls
to f (it using around 2GB
On Saturday, 27 June 2020 at 11:00:58 UTC, Stanislav Blinov wrote:
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
I find that the memory usage grows to about 1.5GB and never
decreases. Is there something I am not understanding?
How are you measuring that? GC.collect() does not
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
I find that the memory usage grows to about 1.5GB and never
decreases. Is there something I am not understanding?
How are you measuring that? GC.collect() does not necessarily
release the pages to the OS. For that, there's the
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
I am writing a web application using vibe.d (not sure whether
that is relevant or not), and have run into a memory leak. I
wrote the following code to try and replicate the problem.
[...]
I now compiled the same code above with
I am writing a web application using vibe.d (not sure whether
that is relevant or not), and have run into a memory leak. I
wrote the following code to try and replicate the problem.
import std.algorithm;
import std.range;
import std.format;
import std.stdio;
import core.thread;
import
On Monday, 1 June 2020 at 12:37:05 UTC, Steven Schveighoffer
wrote:
I was under the impression that TLS works by altering a global
pointer during the context switch. I didn't think accessing a
variable involved a system call.
For sure they are slower than "normal" variables, but how much
On 6/1/20 6:51 AM, IGotD- wrote:
On Sunday, 31 May 2020 at 16:57:06 UTC, Steven Schveighoffer wrote:
I can't imagine much of druntime working at all without TLS. Indeed,
it is a requirement these days.
I believe that's where these roots are being stored.
I would really like if druntime
On 6/1/20 5:53 AM, a11e99z wrote:
On Sunday, 31 May 2020 at 16:57:06 UTC, Steven Schveighoffer wrote:
I can't imagine much of druntime working at all without TLS. Indeed,
it is a requirement these days.
TLS is evil for async/await when any thread can execute any fiber (case
where fiber
On Sunday, 31 May 2020 at 16:57:06 UTC, Steven Schveighoffer
wrote:
I can't imagine much of druntime working at all without TLS.
Indeed, it is a requirement these days.
I believe that's where these roots are being stored.
-Steve
I would really like if druntime could remove its TLS
On Sunday, 31 May 2020 at 16:57:06 UTC, Steven Schveighoffer
wrote:
I can't imagine much of druntime working at all without TLS.
Indeed, it is a requirement these days.
TLS is evil for async/await when any thread can execute any fiber
(case where fiber tied to thread is wrong/dead version
On 5/30/20 9:51 PM, Marius Cristian Baciu wrote:
I am encountering a strange problem with the GC on a specific platform:
at the first attempt to clear the current memory pool to make room for a
new allocation, the GC considers that the page in which the main thread
resides (the one created in
I am encountering a strange problem with the GC on a specific
platform:
at the first attempt to clear the current memory pool to make
room for a new allocation, the GC considers that the page in
which the main thread resides (the one created in the init
function of the GC) can be freed..
On Tuesday, 8 October 2019 at 16:48:55 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 8 October 2019 at 16:43:23 UTC, Ferhat Kurtulmuş
wrote:
On Tuesday, 8 October 2019 at 16:28:51 UTC, Marcel wrote:
[...]
I think you may find this interesting:
significant
advantages. Unfortunately, the project will heavily rely on
custom memory allocators written in C, so the presence of
garbage collection in the language is a problem. While I'm
aware that the nogc attribute exists, I haven't actually seen a
way to apply it to a whole project
++ instead,
it has become clear that D's introspection facilities will
offer significant advantages. Unfortunately, the project will
heavily rely on custom memory allocators written in C, so the
presence of garbage collection in the language is a problem.
While I'm aware that the nogc attribute exists
significant
advantages. Unfortunately, the project will heavily rely on
custom memory allocators written in C, so the presence of
garbage collection in the language is a problem. While I'm
aware that the nogc attribute exists, I haven't actually seen a
way to apply it to a whole project
will heavily rely on
custom memory allocators written in C, so the presence of garbage
collection in the language is a problem. While I'm aware that the
nogc attribute exists, I haven't actually seen a way to apply it
to a whole project. Is this possible?
On Friday, 8 February 2019 at 15:42:13 UTC, Jonathan Levi wrote:
I should be able to use `core.memory.GC.removeRange` right?
That would leave dangling references in the array. You may be
interested in this, but I have not used it myself:
https://repo.or.cz/w/iv.d.git/blob/HEAD:/weakref.d
I have observers and listeners.
class Observer {
Listener[] listeners;
}
class Listener {}
The observers keep references to listeners, but I would like the
GC to garbage collect listeners even if observers have references
to it and remove the references in observers.
I should be able to
On Wednesday, 28 June 2017 at 15:55:41 UTC, John Burton wrote:
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's implications. I have a function
that creates a std.socket.Socket using new
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I
On Wednesday, 28 June 2017 at 13:19:37 UTC, Guillaume Piolat
wrote:
https://forum.dlang.org/post/pmulowxpikjjffkrs...@forum.dlang.org
Not an issue with DerelictUtil, an issue with the strategy of
closing resources in GC with this case.
Derelict loaders work-around this by not unloading
On Wednesday, 28 June 2017 at 12:33:24 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner
wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
On Wednesday, 28 June 2017 at 13:02:04 UTC, Mike Parker wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with DerelictUtil?
On Wednesday, 28 June 2017 at 12:28:28 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner
wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
reference is != invalid resource reference before trying to
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had
On Wednesday, 28 June 2017 at 09:22:07 UTC, Guillaume Piolat
wrote:
Deterministic destruction is a _solved_ problem in C++, and a
number of users to convert are now coming from C++.
It is also in D, as long as you don't use the GC (which is
inherently non-deterministic).
3. Suggest a
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had (implicitly): B needs to be `@disable finalize`.
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case
in point: if you have a socket class, it makes perfect sense
for it to have a finalizer. Yes,
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case in
point: if you have a socket class, it makes perfect sense for
it to have a finalizer. Yes, it's better to close it manually,
but it will work just fine for the GC
On 2017-06-27 11:54, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that creates a
std.socket.Socket using new and connects to a tcp server, and writes
some stuff to it. I then explicitly close the socket
On 2017-06-27 17:24, Steven Schveighoffer wrote:
Yes, Tango solved this by having a separate "finalize()" method. I wish
we had something like this.
Not sure if this is the same, but I remember that Tango had a separate
method called "dispose" that was called if a class was allocated on the
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via
Digitalmars-d-learn wrote:
Not every class can't be finalized, so it might make sense for
finalization to remain an available option.
There are definitely cases where
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via Digitalmars-d-learn
wrote:
> On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
>
> wrote:
> > On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
> >> - Replace calls by the GC to `~this` with calls to `finalize`
>
On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
wrote:
On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
- Replace calls by the GC to `~this` with calls to `finalize`
(or invent some cool other shortened name for the latter)
My point is that in such a "finalize()"
On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
Do you mean destructors?
Yes.
- Replace calls by the GC to `~this` with calls to `finalize`
(or invent some cool other shortened name for the latter)
My point is that in such a "finalize()" function the only sane
things to
On Tuesday, 27 June 2017 at 23:42:38 UTC, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:
Well, technically speaking the `~this` for D classes *is* a
finalizer that you may optionally manually call (e.g. via
destroy).
It would be nice, though, to
On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:
Well, technically speaking the `~this` for D classes *is* a
finalizer that you may optionally manually call (e.g. via
destroy).
It would be nice, though, to change class `~this` into a
destructor and move the finalization into
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
The GC still needs to call something to clean up non-memory
resources,
Well, I'd much prefer if the GC would simply not call
destructors. Yes, destructor can work for _some_ resources, but
because of ordering it also
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
[...]
Arguably, std.socket should have used structs instead of
classes for sockets for precisely this reason (though there are
some advantages in
On 6/27/17 2:04 PM, Moritz Maxeiner wrote:
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is
On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer
wrote:
But I would use a close method, and not destroy(obj). The
reason is because often times, you have wrapper
On 6/27/17 12:16 PM, Steven Schveighoffer wrote:
On 6/27/17 11:24 AM, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
That's how the GC-proof resource class came to existence, after many
destruction bugs, and it let's you use the GC as a detector for
On 6/27/17 11:24 AM, Steven Schveighoffer wrote:
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
That's how the GC-proof resource class came to existence, after many
destruction bugs, and it let's you use the GC as a detector for
non-deterministic destruction. I miss it in @nogc :)
On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is
because often times, you have wrapper types around your socket type,
and just one extra level of indirection
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer
wrote:
But I would use a close method, and not destroy(obj). The
reason is because often times, you have wrapper types around
your socket type, and just one extra level of indirection means
the destructor cannot be used to clean up
On 6/27/17 8:29 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
Am I doing this right with GC? In C++ I'd ensure that the Socket class
had a destructor that closed the socket and I'd also assume that once
it went out of scope there was no memory left
On Tuesday, 27 June 2017 at 12:29:03 UTC, Guillaume Piolat wrote:
[...]
Hmm... Isn't it possible to just allocate the object/a pool of
objects outside the loop and reuse it? Everybody's proposing
other means of allocations which is nice, but I wonder why there
is such a need for
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I assume that I do need to explicitly call close on the socket
as there is no deterministic destructor for class objects.
Yes.
I further assume that the runtime will garbage collect any
memory allocated to the socket object at a
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
Now the issue is that I now need to call this function more
than once every second. I worry that it will create large
amounts of uncollected "garbage" which will eventually lead to
problems.
Since nobody has mentioned Allocator,
On Tuesday, 27 June 2017 at 11:43:27 UTC, John Burton wrote:
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis
wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's
On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via
Digitalmars-d-learn wrote:
I'm coming from a C++ background so I'm not too used to
garbage collection and it's implications. I have a function
that creates a std.socket.Socket
On Tuesday, June 27, 2017 09:54:19 John Burton via Digitalmars-d-learn
wrote:
> I'm coming from a C++ background so I'm not too used to garbage
> collection and it's implications. I have a function that creates
> a std.socket.Socket using new and connects to a tcp server, and
> write
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that creates
a std.socket.Socket using new and connects to a tcp server, and
writes some stuff to it. I then explicitly close the socket, and
the socket object goes out of scope
On Monday, 19 June 2017 at 09:18:56 UTC, Dsby wrote:
void uses(scope void delegate() dg);
will it be not alloc memory?
I test it , if use scope it will not alloc memony.
Right, using `scope` at the point the delegate variable is
defined means it will never allocate.
On Monday, 19 June 2017 at 09:10:16 UTC, Dsby wrote:
On Saturday, 17 June 2017 at 17:15:50 UTC, Adam D. Ruppe wrote:
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
[...]
Where the variable is defined that is referenced in the
closure.
So:
[...]
if the uses parma is 'scope':
On Saturday, 17 June 2017 at 17:15:50 UTC, Adam D. Ruppe wrote:
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
[...]
Where the variable is defined that is referenced in the closure.
So:
[...]
if the uses parma is 'scope':
void uses(scope void delegate() dg);
will it be not
On Saturday, 17 June 2017 at 17:15:50 UTC, Adam D. Ruppe wrote:
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced".
What the deep you mean? The deep of a closure or deep of the
function where the variable is defined. Can you
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced".
What the deep you mean? The deep of a closure or deep of the
function where the variable is defined. Can you give an example
code?
Where the variable is defined that is
On Saturday, 17 June 2017 at 13:13:17 UTC, Adam D. Ruppe wrote:
On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote:
Is GC called every iteration of this loop?
No, it will once on scope entry; where the deepest-referenced
variable that is actually captured is defined. The compiler
On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote:
Is GC called every iteration of this loop?
No, it will once on scope entry; where the deepest-referenced
variable that is actually captured is defined. The compiler
allocates heap space instead of stack space for the locals, then
Hello! I can't understand one thing related to closures and
calling of GC. I have the following demo snippet, where a closure
is passed to `receive` function in a loop.
bool isDone = false;
while(!isDone)
receive((bool val){ isDone = val });
Is GC called every iteration of this loop?
Since you access a field through `a` instance, this is usually
done by loading the instance address into some register and
reading from a location at a certain offset from that register
mov esi, [ebp-4] # the instance address
mov eax, [esi+8] # first field
...
mov [ebp-4], 0 # clear stack
Hello everybody. I am new to D, and I am trying to familiarize
with all the new (to me) features.
I have a question about a strange behavior I cannot understand.
(In case it matters, I am using gdc 2.065 for Windows, but the
same happens with dmd).
Example code :
class A {
void
I'm just guessing, but it looks to me that the delegate's pointer
might be on the stack there and isn't overwritten when the one
function returns, so the gc still thinks there might be an active
pointer to it.
Is it possible to temporarily prevent the garbage collector from
collecting a memory block even if there are no references to it?
The use case is as follows: I want to call a C library function
which expects to take ownership of a buffer. It looks something
like this:
alias FreeFunc =
On Thu, 24 Apr 2014 19:55:37 +, Lars T. Kyllingstad wrote:
Is it possible to temporarily prevent the garbage collector from
collecting a memory block even if there are no references to it?
The use case is as follows: I want to call a C library function which
expects to take ownership
On Thursday, 24 April 2014 at 20:09:38 UTC, Justin Whear wrote:
You can use GC.addRoot() from core.memory before passing the
pointer to
the C function, then use GC.removeRoot in your myFree function.
Perfect, thanks!
On 2013-07-11 04:59, Maxim Fomin wrote:
To be pedantic dynamic arrays are implemented in D simply as
struct Array
{
size_t length;
void* ptr;
}
and there is no type parametrization since such arrays handling is
opaque for users (in druntime they are treated as void[]).
On 2013-07-10 20:22, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
I thought ptr came first, that's the reason you could cast to the
pointer type. Not that one should do that. Perhaps there's some
compiler/runtime magic
On 2013-07-11 09:43, Maxim Fomin wrote:
It's in the user side. In druntime it is void[] + typeinfo. I am not
aware of any part in dmd/druntime where arrays are repsented as
templates (or strongly typed) as depicted in this dicsussion. And
current treatment can be barely called templatization as
On 2013-07-11 13:19, Jacob Carlborg wrote:
Yes, but that is easier to type. All the above or:
struct Array (T)
{
size_t length;
T* ptr;
}
that should have been what.
--
/Jacob Carlborg
On 07/11/2013 12:23 AM, Jacob Carlborg wrote:
On 2013-07-10 20:22, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
I thought ptr came first, that's the reason you could cast to the
pointer type. Not that one should do
On Thursday, 11 July 2013 at 17:07:18 UTC, Ali Çehreli wrote:
On 07/11/2013 12:23 AM, Jacob Carlborg wrote:
On 2013-07-10 20:22, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
I thought ptr came first, that's the
On 07/11/2013 10:20 AM, Maxim Fomin wrote:
On Thursday, 11 July 2013 at 17:07:18 UTC, Ali Çehreli wrote:
that magic should be the same as
getting the .ptr property.
Yes.
In context of slices cast(int*)arr is essentially s.ptr.
And yes. :)
Ali
this. Also what is returned by this
function? Does this function return a pointer or the contents of
an array? If I do export this what does it do to the Garbage
Collection? Does the Garbage Collection collect tstStr or st?
Also notice the comment in the function.
and C has no type like this.
Also what is returned by this function? Does this function return a
pointer or the contents of an array? If I do export this what does it
do to the Garbage Collection? Does the Garbage Collection collect
tstStr or st? Also notice the comment in the function.
A string
A string in D, and all arrays, is a struct looking like this:
struct Array (T)
{
T* ptr;
size_t length;
}
I always thought it looks like this:
struct Array(T) {
T* ptr;
size_t length, capacity;
}
On Jul 10, 2013, at 10:45 AM, Namespace rswhi...@googlemail.com wrote:
A string in D, and all arrays, is a struct looking like this:
struct Array (T)
{
T* ptr;
size_t length;
}
I always thought it looks like this:
struct Array(T) {
T* ptr;
size_t length, capacity;
}
On 07/10/2013 11:10 AM, Sean Kelly wrote:
On Jul 10, 2013, at 10:45 AM, Namespace rswhi...@googlemail.com wrote:
A string in D, and all arrays, is a struct looking like this:
struct Array (T)
{
T* ptr;
size_t length;
}
I always thought it looks like this:
struct Array(T) {
On Wednesday, 10 July 2013 at 18:22:24 UTC, Ali Çehreli wrote:
On 07/10/2013 11:10 AM, Sean Kelly wrote:
On Jul 10, 2013, at 10:45 AM, Namespace
rswhi...@googlemail.com wrote:
A string in D, and all arrays, is a struct looking like
this:
struct Array (T)
{
T* ptr;
size_t length;
On Wed, Jul 10, 2013 at 07:45:25PM +0200, Namespace wrote:
A string in D, and all arrays, is a struct looking like this:
struct Array (T)
{
T* ptr;
size_t length;
}
I always thought it looks like this:
struct Array(T) {
T* ptr;
size_t length, capacity;
}
Nope, the
1 - 100 of 152 matches
Mail list logo
