On Wed, Jul 10, 2013 at 08:38:40PM +0200, JohnnyK wrote:
[...]
Reminds me of how Delphi (aka Pascal) strings are work. Thanks
everyone this answers some of my questions. Now what about when the
return type of a function is a string? Is D returning the pointer
to the string structure or is
On Wednesday, July 10, 2013 20:38:40 JohnnyK wrote:
Reminds me of how Delphi (aka Pascal) strings are work. Thanks
everyone this answers some of my questions. Now what about when
the return type of a function is a string? Is D returning the
pointer to the string structure or is it returning
On Wednesday, 10 July 2013 at 18:45:56 UTC, H. S. Teoh wrote:
On Wed, Jul 10, 2013 at 08:38:40PM +0200, JohnnyK wrote:
[...]
Reminds me of how Delphi (aka Pascal) strings are work. Thanks
everyone this answers some of my questions. Now what about
when the
return type of a function is a
come from a C
background 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
On Wednesday, 10 July 2013 at 17:18:09 UTC, JohnnyK wrote:
export string mytest(string tstStr)
{
string st = tstStr;
/* abbreviated to protect the innocent but other operations
such as concatenating and deleting may be done to st
before the return
*/
return st;
}
Arrays are
On Wednesday, 10 July 2013 at 18:22:24 UTC, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
Which is actually property-like because assigning to length
does pretty complex stuff. So the member cannot be named as
'length':
a self referential question came to mind: what collects the
garbage collector's garbage? And I'm not trying to be a
smart-alec here. I'm generally curious. Is a Garbage Collector
written without garbage collection?
On 05/21/2013 08:18 AM, WhatMeWorry wrote:
Is a Garbage Collector written without garbage collection?
Without knowing the details, I wouldn't be surprised. There are various
memory management schemes. Here is a short article that lists some of them:
http://dlang.org/memory.html
On Tue, 21 May 2013 11:18:25 -0400, WhatMeWorry kc_hea...@yahoo.com
wrote:
a self referential question came to mind: what collects the garbage
collector's garbage? And I'm not trying to be a smart-alec here. I'm
generally curious. Is a Garbage Collector written without garbage
On Saturday, 7 July 2012 at 03:02:07 UTC, akaz wrote:
On Friday, 6 July 2012 at 21:10:56 UTC, Simon wrote:
On 06/07/2012 16:39, Alex Rønne Petersen wrote:
Never mind what D says, even in C/C++ just doing the p += 10
is invalid.
Creating a pointer that points at invalid memory is just as
Hi,
Reading about the C++11, I stumbled upon this:
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi
Specifically (quote):
int* p = new int;
p+=10;
// ... collector may run here ...
p-=10;
*p = 10;// can we be sure that the int is still
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi
Specifically (quote):
int* p = new int;
p+=10;
// ... collector may run here ...
p-=10;
*p = 10;// can we be sure that
If you are interested in D read this first:
http://dlang.org/garbage.html
You can find there e.g.:
Do not add or subtract an offset to a pointer such that the
result points outside of the bounds of the garbage collected
object originally allocated.
So `p+=10;` is already undefined behavior.
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi
Specifically (quote):
int* p = new int;
p+=10;
// ... collector may run here ...
p-=10;
*p = 10; // can we be
On 07/06/2012 05:39 PM, Alex Rønne Petersen wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi
Specifically (quote):
int* p = new int;
p+=10;
// ...
On Friday, 6 July 2012 at 15:39:40 UTC, Alex Rønne Petersen
wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
I'll just add: Handling this case is basically impossible to do
sanely. You can't really know
On 06-07-2012 22:07, akaz wrote:
On Friday, 6 July 2012 at 15:39:40 UTC, Alex Rønne Petersen wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
I'll just add: Handling this case is basically impossible to
On 06/07/2012 16:39, Alex Rønne Petersen wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Hi,
Reading about the C++11, I stumbled upon this:
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi
Specifically (quote):
int* p = new int;
p+=10;
// ...
On Friday, 6 July 2012 at 21:10:56 UTC, Simon wrote:
On 06/07/2012 16:39, Alex Rønne Petersen wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Never mind what D says, even in C/C++ just doing the p += 10 is
invalid.
Creating a pointer that points at
Won't some functions doing just what addRange() and
removeRange() do solve that kind of problem (if necessary)?
That means, forbidding the GC to scan some memory area for some
time?
Like their C++11 counterparts:
void declare_reachable(void* p); // the region of memory
starting at p
On 07-07-2012 05:02, akaz wrote:
On Friday, 6 July 2012 at 21:10:56 UTC, Simon wrote:
On 06/07/2012 16:39, Alex Rønne Petersen wrote:
On 06-07-2012 16:07, Denis Shelomovskij wrote:
06.07.2012 17:43, akaz пишет:
Never mind what D says, even in C/C++ just doing the p += 10 is invalid.
Exploring the example a bit further:
If C's malloc is used instead of GC.malloc then the deallocators also
are not called and the program runs out of memory. How are the objects
supposed to get finalized in this case - do I have to use the delete
keyword explicitly?
If you use
Ok, that makes sense. So the deallocators really should not get called
in this case. But why are the destructors not invoked when the GC
finalizes the objects?
For S1 and S2, this is a known bug - destructors of structs on the heap
don't get called.
Ah, I see. You mean #2834. That
Ivo Kasiuk Wrote:
- Is there any way the regular finalization sequence (i.e. including
automatic invoking of the destructors) can be run for an object that
uses non-GC memory?
It should happen when delete is called. Here's the code executed for delete:
Hi,
to improve my understanding of the GC and when/how
allocators/deallocators and constructors/destructors get called, I wrote
a little test program. And now I understand even less than before...
Here is the program:
import core.memory;
import std.stdio;
Ivo Kasiuk Wrote:
Hi,
to improve my understanding of the GC and when/how
allocators/deallocators and constructors/destructors get called, I wrote
a little test program. And now I understand even less than before...
...
Running this with DMD 2.049, I observed the following:
- S1(int),
Am Samstag, den 18.09.2010, 10:08 -0400 schrieb Sean Kelly:
Ivo Kasiuk Wrote:
Hi,
to improve my understanding of the GC and when/how
allocators/deallocators and constructors/destructors get called, I wrote
a little test program. And now I understand even less than before...
...
An interesting case is when using C's malloc for C1 and using the scope
attribute for c1:
class C1 {
ubyte[1_000_000] buf;
new(size_t size) {
void* ptr = std.c.stdlib.malloc(size);
if (ptr is null)
throw new OutOfMemoryError(__FILE__, __LINE__);
writefln(C1.new(%d)
Ivo Kasiuk i.kas...@gmx.de wrote:
Ok, that makes sense. So the deallocators really should not get called
in this case. But why are the destructors not invoked when the GC
finalizes the objects?
For S1 and S2, this is a known bug - destructors of structs on the heap
don't get called.
As for
Exploring the example a bit further:
If C's malloc is used instead of GC.malloc then the deallocators also
are not called and the program runs out of memory. How are the objects
supposed to get finalized in this case - do I have to use the delete
keyword explicitly?
If you use C's
Ivo Kasiuk i.kas...@gmx.de wrote:
Exploring the example a bit further:
If C's malloc is used instead of GC.malloc then the deallocators also
are not called and the program runs out of memory. How are the objects
supposed to get finalized in this case - do I have to use the delete
keyword
LDC is a moving target because it's actively developed, and generally things
improve with time.
This is a recent change by the quite active Frits van Bommel:
http://www.dsource.org/projects/ldc/changeset/1486%3A9ed0695cb93c
This is a cleaned up version discussed in this thread:
import
bearophile wrote:
Frits van Bommel:
LDC actually still does a dynamic allocation there because it doesn't eliminate
dynamic allocations in loops.
I have compiled the loop in foo() with LDC:
[snip]
scope auto item = new AllocationItem(i);
[snip]
The asm of the core of the loop:
bearophile wrote:
Yes, for such tiny benchmarks I have seen several times 10-12 higher allocation
performance in Java compared to D1-DMD. But real programs don't use all their
time allocating and freeing memory...
Bye,
bearophile
For the compiler I'm working on now (in D), I wanted to check
Robert Fraser:
Of course, this only applies to programs which allocate and throw away a
lot of small objects. This is a style encouraged by Java and C#'s
programming models, much less so by, say, C++'s.
Right, there are many potential new D programmers coming from Java that may
want to use
Hello Jarrett,
On Tue, Jun 2, 2009 at 8:40 PM, Diwaker Gupta
diwa...@floatingsun.net wrote:
I've just started to play around with D, and I'm hoping someone can
clarify this. I wrote a very simple program that just allocates lots
of objects, in order to benchmark the garbage collector in D.
Robert Clipsham wrote:
After porting the D version to tango:
D: 6.282s (ldmd -O5 -inline -release -L-s -singleobj gctest.d)
C++: 4.435s (g++ -O5 gctest.d)
This is on a C2D 2.2Ghz, 2GB RAM, Linux x86-64. I don't have java
installed, so can't test that. Maybe if you're planning to use the GC a
Robert Clipsham wrote:
After reading TSalm's post, I reran the D version with the scope keyword
at line 16:
D (with scope): 1.098s
D: 6.282s
C++: 4.435s
It seems by using scope and tango you can easily compete with C++.
'scope' eliminates dynamic memory allocation. At this point you're
What's the difference between:
D 1: 40.20 DMD
D 2: 21.83 DMD
D 2: 18.80 DMD, struct + scope
and:
D 1: 8.47 DMD
D 2: 7.41 DMD + scope
...?
Robert Fraser:
What's the difference between:
D 1: 40.20 DMD
D 2: 21.83 DMD
That's the standard code.
and:
D 1: 8.47 DMD
D 2: 7.41 DMD + scope
They are both with scope, on D1 and D2.
Sorry for my small omission.
Bye,
bearophile
bearophile Wrote:
I have tried the new JavaVM on Win, that optionally performs escape analysis,
and the results are nice:
Timings, N=100_000_000, Windows, seconds:
D 1: 40.20 DMD
D 2: 21.83 DMD
D 2: 18.80 DMD, struct + scope
C++: 18.06
D 1: 8.47 DMD
D 2: 7.41 DMD +
Sam Hu wrote:
bearophile Wrote:
I have tried the new JavaVM on Win, that optionally performs escape analysis,
and the results are nice:
Timings, N=100_000_000, Windows, seconds:
D 1: 40.20 DMD
D 2: 21.83 DMD
D 2: 18.80 DMD, struct + scope
C++: 18.06
D 1: 8.47 DMD
D 2:
I've just started to play around with D, and I'm hoping someone can clarify
this. I wrote a very simple program that just allocates lots of objects, in
order to benchmark the garbage collector in D. For comparison, I wrote the
programs in C++, Java and D:
C++: http://gist.github.com/122708
Diwaker Gupta wrote:
I've just started to play around with D, and I'm hoping someone can clarify
this. I wrote a very simple program that just allocates lots of objects, in
order to benchmark the garbage collector in D. For comparison, I wrote the
programs in C++, Java and D:
C++:
wolftousen wrote:
I have a function defined as:
some_function(int[] array) { ... }; //this function does not ever modify
values of array
When I call this function (once every program cycle) from an object using an
array of type short:
//member variable in an object
short[] x =
On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Maybe it's because I just woke up, but I can't see how that code could
compile anyway, since you can't pass a short[] to a function expecting
an int[].
You missed the array literal.
Jarrett Billingsley wrote:
On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Maybe it's because I just woke up, but I can't see how that code could
compile anyway, since you can't pass a short[] to a function expecting
an int[].
You missed the array
Dan W:
1: Even though D has an automatic garbage collector, is one still
allowed to free the memory of a malloced array manually (using free
() ), to avoid pauses in the program?
Other people here will just answer your question. But remember that in D manual
memory management is done only in
On Tue, Dec 9, 2008 at 9:42 AM, Jarrett Billingsley
[EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 9:16 AM, Daniel White [EMAIL PROTECTED] wrote:
Thanks for that reply. I wonder if extending automatic garbage
collection for malloced memory would be a good idea...
That would be a bad idea
On Tue, Dec 9, 2008 at 11:08 AM, Daniel White [EMAIL PROTECTED] wrote:
That would be a bad idea. Then how would you do manual memory
management in the few cases that absolutely require it?
Two ways. Either:
a: being able to lock the variable so that the garbage collector
can't touch it
Daniel White wrote:
That would be a bad idea. Then how would you do manual memory
management in the few cases that absolutely require it?
Two ways. Either:
a: being able to lock the variable so that the garbage collector
can't touch it until you unlock it.
If you have a reference to the
arrays, AAs and new'ed stuff gets cleaned up by the GC.
2: One justification on the website for using automatic garbage
collection is how allocated memory will only be freed if system RAM
is tight. But surely that's silly, since one may want *lots* of
memory free for a completely different application
101 - 152 of 152 matches
Mail list logo
