On Tuesday, 29 September 2020 at 10:57:07 UTC, novice3 wrote:
Naive newbie question:
Can we have (in theory) in D lang memory management like V lang?
I don't know V so can't be sure, but doing it the same way as in
the examples sounds possible.
The first two calls are easy
On Tuesday, 29 September 2020 at 16:03:39 UTC, IGotD- wrote:
That little simple example shows that you don't necessarily
need to know things in advance in order to have static
lifetimes. However, there are examples where there is no
possibility for the compiler to infer when the object goes out
On Tuesday, 29 September 2020 at 10:57:07 UTC, novice3 wrote:
Naive newbie question:
Can we have (in theory) in D lang memory management like V lang?
Quote:
https://github.com/vlang/v/blob/master/doc/docs.md#memory-management
"V doesn't use garbage collection or reference cou
On Tuesday, 29 September 2020 at 15:47:09 UTC, Ali Çehreli wrote:
I am not a language expert but I can't imagine how the compiler
knows whether an event will happen at runtime. Imagine a server
program allocates memory for a client. Let's say, that memory
will be deallocated when the client l
On 9/29/20 3:57 AM, novice3 wrote:> Naive newbie question:
>
> Can we have (in theory) in D lang memory management like V lang?
>
> Quote:
> https://github.com/vlang/v/blob/master/doc/docs.md#memory-management
>
> "V doesn't use garbage collection or referen
Naive newbie question:
Can we have (in theory) in D lang memory management like V lang?
Quote:
https://github.com/vlang/v/blob/master/doc/docs.md#memory-management
"V doesn't use garbage collection or reference counting. The
compiler cleans everything up during compilation.
On Monday, 17 June 2019 at 20:26:28 UTC, H. S. Teoh wrote:
On Mon, Jun 17, 2019 at 07:53:52PM +, Thomas via
Digitalmars-d-learn wrote: [...]
[...]
If x were a heap-allocated object, then your concerns would be
true: it would be allocated once every iteration (and also add
to the garbage
On Mon, Jun 17, 2019 at 07:53:52PM +, Thomas via Digitalmars-d-learn wrote:
[...]
> int main()
> {
> foreach(i;0 .. 1)
> {
> int x;
> // do something with x
> }
> return 0;
> }
>
> Do I understand it right that the variable x will be created 1
> times an
First, thank you for your fast reply!
On Monday, 17 June 2019 at 20:00:34 UTC, Adam D. Ruppe wrote:
No, the compiler will generate code to reuse the same thing
each loop.
Does this code also work on complex types like structs ?
On Monday, 17 June 2019 at 19:53:52 UTC, Thomas wrote:
Do I understand it right that the variable x will be created
1 times and destroyed at the end of the scope in each loop
? Or will it be 1 overwritten by creation ?
No, the compiler will generate code to reuse the same thing each
l
Hello!
First my background: C++ and Java ages ago. Since then only
PLSQL. Now learning D just for fun and personal education on time
to time and very pleased about it :-)
Now I have to ask a question here, because I could not find a
corresponding answer for it. Or I am unable to find it :-)
On Monday, 29 April 2019 at 14:38:54 UTC, 9il wrote:
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
[...]
Hello Ferhat,
You can use RCArray!T or Slice!(RCI!T) [1, 2] as common thread
safe @nogc types for D and C++ code.
See also integration C++ example [3] and C++ heade
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not faci
On Monday, 29 April 2019 at 00:53:34 UTC, Paul Backus wrote:
On Sunday, 28 April 2019 at 23:10:24 UTC, Ferhat Kurtulmuş
wrote:
You are right. I am rewriting the things using mallocs, and
will use core.stdc.stdlib.free on d side. I am not sure if I
can use core.stdc.stdlib.free to destroy arrays
On Sunday, 28 April 2019 at 23:10:24 UTC, Ferhat Kurtulmuş wrote:
You are right. I am rewriting the things using mallocs, and
will use core.stdc.stdlib.free on d side. I am not sure if I
can use core.stdc.stdlib.free to destroy arrays allocated with
new op.
core.stdc.stdlib.free is (as the na
On Sunday, 28 April 2019 at 03:54:17 UTC, Paul Backus wrote:
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to le
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not faci
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to learn if I am leaking
memory like crazy, although I am not facing crashes so far. Is GC
of D handling things for me? Here is an exa
On Saturday, 16 March 2019 at 15:53:26 UTC, Johan Engelen wrote:
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope
finishes? Or does it remain in some p
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimize
On Sat, Mar 16, 2019 at 01:21:02PM +0100, spir via Digitalmars-d-learn wrote:
> On 16/03/2019 11:19, Dennis via Digitalmars-d-learn wrote:
[...]
> > In any case, for better memory efficiency I'd consider looking at
> > reducing dynamic allocations such as new or malloc. Memory on the
> > stack is b
On 16/03/2019 11:19, Dennis via Digitalmars-d-learn wrote:
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as in
{int a = 10;}
it disappears complete from the memory when the scope finishes? Or does it
remain in some part of
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimize
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimize
On Saturday, 16 March 2019 at 03:47:43 UTC, Murilo wrote:
Does anyone know if when I create a variable inside a scope as
in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimize
Does anyone know if when I create a variable inside a scope as in
{int a = 10;}
it disappears complete from the memory when the scope finishes?
Or does it remain in some part of the memory? I am thinking of
using scopes to make optimized programs that consume less memory.
On Saturday, 30 September 2017 at 07:41:21 UTC, Igor wrote:
On Friday, 29 September 2017 at 22:13:01 UTC, Jon Degenhardt
wrote:
Have there been any investigations into using region-based
memory management (aka memory arenas) in D, possibly in
conjunction with GC allocated memory?
Sounds like
On Friday, 29 September 2017 at 22:13:01 UTC, Jon Degenhardt
wrote:
Have there been any investigations into using region-based
memory management (aka memory arenas) in D, possibly in
conjunction with GC allocated memory? This would be a very
speculative idea, but it'd be interesting to kn
Have there been any investigations into using region-based memory
management (aka memory arenas) in D, possibly in conjunction with
GC allocated memory? This would be a very speculative idea, but
it'd be interesting to know if there have been looks at this area.
My own interest is re
On Wednesday, 8 March 2017 at 06:42:40 UTC, ag0aep6g wrote:
[...]
Yes and yes. GCAllocator.allocate calls core.memory.GC.malloc
with does pretty much the same thing as the builtin `new`.
Nitpicking: `new` is typed (i.e. allocation+construction),
`malloc` and `allocate` are not (only allocati
On 03/08/2017 02:15 AM, XavierAP wrote:
I see the default allocator is the same GC heap used by 'new'. Just for
my learning curiosity, does this mean that if I theAllocator.make()
something and then forget to dispose() it, it will be garbage collected
the same once no longer referenced? And so ar
ental.allocator; it looks
really powerful and general, more than I need. I see the
potential but I don't really have the knowledge to tweak memory
management, and the details of the "building blocks" are well
beyond me.
But even if I don't go there, I guess it's a good
On Tuesday, 7 March 2017 at 20:15:37 UTC, XavierAP wrote:
On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use
allocators. You can use "make" and "dispose" from
std.experimental.allocator the same way as New/Delete.
Thanks!
On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use
allocators. You can use "make" and "dispose" from
std.experimental.allocator the same way as New/Delete.
Thanks! looking into it.
Does std.experimental.allocator have a le
On Tuesday, 7 March 2017 at 17:37:43 UTC, XavierAP wrote:
On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote:
There's nothing like that of C++.
Don't you think New/Delete from dlib.core.memory fills the
bill? for C++ style manual dynamic memory management? It looks
quite
On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote:
There's nothing like that of C++.
Don't you think New/Delete from dlib.core.memory fills the bill?
for C++ style manual dynamic memory management? It looks quite
nice to me, being no more than a simple malloc wrapper with
c
On Sunday, 5 March 2017 at 20:54:06 UTC, XavierAP wrote:
What I want to learn (not debate) is the currently available
types, idioms etc. whenever one wants deterministic memory
management.
There's nothing like that of C++. Currently you have Unique,
RefCounted, scoped and individual p
On Monday, 6 March 2017 at 08:26:53 UTC, Eugene Wissner wrote:
The memory management in D is becoming a mess.
I am aware this is a hot topic, hence the opening joke. But I
just want to learn what toolboxes are currently available, not
really discuss how adequate they are, or how often GC is
On Sunday, 5 March 2017 at 20:54:06 UTC, XavierAP wrote:
I was going to name this thread "SEX!!" but then I thought
"best memory management" would get me more reads ;) Anyway now
that I have your attention...
What I want to learn (not debate) is the currently availabl
I was going to name this thread "SEX!!" but then I thought "best
memory management" would get me more reads ;) Anyway now that I
have your attention...
What I want to learn (not debate) is the currently available
types, idioms etc. whenever one wants deterministic memory
m
bably a good idea.
Having a self managed reference to the heap can be good too if
manual memory management is wanted. Or of course let the GC
manage it ( i love it for prototyping code and also as a D
beginner it is beneficial that i just dont need to care about
memory management).
Could som
On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
from what i got Classes are always reference types and structs
are value types in D. i am wondering why that is. for me the
main difference between classes and structs is not how they are
allocated, but that one has inhertiance, and the ot
On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
from what i got Classes are always reference types and structs
are value types in D. i am wondering why that is. for me the
main difference between classes and structs is not how they are
allocated, but that one has inhertiance, and the ot
On Friday, 2 September 2016 at 08:59:38 UTC, Andrea Fontana wrote:
On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
i haven't read it fully yet, but i think this DIP contains
some or all of my concerns
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Check this:
https://dlang.
On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
i haven't read it fully yet, but i think this DIP contains some
or all of my concerns
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Check this:
https://dlang.org/phobos/std_experimental_allocator.html
i haven't read it fully yet, but i think this DIP contains some
or all of my concerns
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
d idea.
Having a self managed reference to the heap can be good too if
manual memory management is wanted. Or of course let the GC
manage it ( i love it for prototyping code and also as a D
beginner it is beneficial that i just dont need to care about
memory management).
Could somebody explai
On Wednesday, 1 June 2016 at 08:53:01 UTC, Rene Zwanenburg wrote:
I was wondering: what's the preferred method for deterministic
memory management?
You can annotate your functions as @nogc. The compiler will
disallow any potential GC use, including calling other
functions that are not
I was wondering: what's the preferred method for deterministic
memory management?
You may be interested in RefCounted. It only works for structs,
not classes, but it's still useful.
- Classes/Structs have constructors and destructors. I am
unconfident with my knowledge as to how
On Wednesday, 1 June 2016 at 07:59:50 UTC, Anthony Monterrosa
wrote:
I've recently been trying to convince a friend of mine that D
has at least the functionality of C++, and have been learning
the language over C++ for a few months. Memory management is
pretty important to him, and a su
On 01/06/2016 7:59 PM, Anthony Monterrosa wrote:
I've recently been trying to convince a friend of mine that D has at
least the functionality of C++, and have been learning the language over
C++ for a few months. Memory management is pretty important to him, and
a subject I'm honest
I've recently been trying to convince a friend of mine that D has
at least the functionality of C++, and have been learning the
language over C++ for a few months. Memory management is pretty
important to him, and a subject I'm honestly curious about as
well. I was wondering:
https://dlang.org/phobos/std_container.html and corresponding
code in phobos. Though recently allocators were introduced and
containers are going to be written with support for allocators.
Hi,
I am looking for example of types where memory management is
manual, and the type supports operator overloading, etc. Grateful
if someone could point me to sample example code.
Thanks and Regards
Dibyendu
I don't think you've read h5py source in enough detail :)
You're right - I haven't done more than browsed it.
It's based HEAVILY on duck typing.
There is a question here about what to do in D. On the one hand,
the flexibility of being able to open a foreign HDF5 file where
you don't know
On Wednesday, 14 January 2015 at 16:27:17 UTC, Laeeth Isharc
wrote:
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T :
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T : Group);
auto method1(T)(T obj, args) if (isContainer!T) { ... }
auto
On Wednesday, 14 January 2015 at 14:54:09 UTC, Laeeth Isharc
wrote:
In the hierarchy example above (c++ hdf hierarchy link), by
using UFCS to implement the shared methods (which are achieved
by multiple inheritance in the c++ counterpart) did you mean
something like this?
// id.d
struct ID
In the hierarchy example above (c++ hdf hierarchy link), by
using UFCS to implement the shared methods (which are achieved
by multiple inheritance in the c++ counterpart) did you mean
something like this?
// id.d
struct ID { int id; ... }
// location.d
struct Location { ID _id; alias _id t
On Tue, 13 Jan 2015 18:35:15 +
aldanor via Digitalmars-d-learn
wrote:
> I guess two of my gripes with UFCS is (a) you really have to use
> public imports in the modules where the target types are defined
> so you bring all the symbols in whether you want it or not (b)
> you lose access to
On Tuesday, 13 January 2015 at 17:08:38 UTC, Laeeth Isharc wrote:
>> I see, thanks! :) I've started liking structs more and
>> more recently as well and been pondering on how to convert
>> a class-based code that looks like this (only the base
>> class has any data):
> it's hard to tell by brie
On Tue, 13 Jan 2015 17:08:37 +
Laeeth Isharc via Digitalmars-d-learn
wrote:
> I just finished reading aldanor's blog, so I know he is slightly
> allergic to naked functions and prefers classes ;)
that's due to absense of modules in C/C++. and namespaces aren't of big
help here too. and, of c
>> I see, thanks! :) I've started liking structs more and more
>> recently as well and been pondering on how to convert a
>> class-based code that looks like this (only the base class
>> has any data):
> it's hard to tell by brief description. but having multiple
> inheritance
> immediately rin
On Tue, 13 Jan 2015 16:08:15 +
aldanor via Digitalmars-d-learn
wrote:
> On Tuesday, 13 January 2015 at 08:33:57 UTC, ketmar via
> Digitalmars-d-learn wrote:
> > On Mon, 12 Jan 2015 22:07:13 +
> > aldanor via Digitalmars-d-learn
> >
> > wrote:
> >
> >> I see, thanks! :) I've started lik
On Tuesday, 13 January 2015 at 08:33:57 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 22:07:13 +
aldanor via Digitalmars-d-learn
wrote:
I see, thanks! :) I've started liking structs more and more
recently as well and been pondering on how to convert a
class-based code t
On Mon, 12 Jan 2015 22:07:13 +
aldanor via Digitalmars-d-learn
wrote:
> I see, thanks! :) I've started liking structs more and more
> recently as well and been pondering on how to convert a
> class-based code that looks like this (only the base class has
> any data):
p.s. can't you convert
On Mon, 12 Jan 2015 22:07:13 +
aldanor via Digitalmars-d-learn
wrote:
> I see, thanks! :) I've started liking structs more and more
> recently as well and been pondering on how to convert a
> class-based code that looks like this (only the base class has
> any data):
it's hard to tell by b
On Mon, 12 Jan 2015 23:06:16 +
jmh530 via Digitalmars-d-learn
wrote:
> I had seen some stuff on alias thing, but I hadn't bothered to
> try to understand it until now. If I'm understanding the first
> example http://dlang.org/class.html#AliasThis";>here,
> alias this let's you refer to x in s
I had seen some stuff on alias thing, but I hadn't bothered to
try to understand it until now. If I'm understanding the first
example http://dlang.org/class.html#AliasThis";>here,
alias this let's you refer to x in s by writing either s.x (as
normally) or just s. That didn't seem that interesting,
I am concerned about
performance of D vs. C++, so I wanted to learn a little bit
more about manual memory management, in case I might ever need
it (not for any particular application).
There is a good article on the D Wiki that covers this topic with
several different patterns and working exa
On Monday, 12 January 2015 at 21:54:51 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 21:37:27 +
aldanor via Digitalmars-d-learn
wrote:
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
Digitalmars-d-learn wrote:
> it even has `RefCounted!`, but it doesn't play well
On Mon, 12 Jan 2015 21:37:27 +
aldanor via Digitalmars-d-learn
wrote:
> On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
> Digitalmars-d-learn wrote:
> > it even has `RefCounted!`, but it doesn't play well with
> > classes yet
> > (AFAIR).
> I wonder if it's possible to somehow make a
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
Digitalmars-d-learn wrote:
it even has `RefCounted!`, but it doesn't play well with
classes yet
(AFAIR).
I wonder if it's possible to somehow make a version of refcounted
that would work with classes (even if limited/restricted in some
cer
On Mon, 12 Jan 2015 20:14:19 +
jmh530 via Digitalmars-d-learn
wrote:
> Thanks for the reply, I wasn't familiar with scoped. I was aware
> that structs are on the stack and classes are on the heap in D,
> but I didn't know it was possible to put a class on the stack.
> Might be interesting
Thanks for the reply, I wasn't familiar with scoped. I was aware
that structs are on the stack and classes are on the heap in D,
but I didn't know it was possible to put a class on the stack.
Might be interesting to see how this is implemented.
After looking up some more C++, I think what I wa
On Mon, 12 Jan 2015 19:29:53 +
jmh530 via Digitalmars-d-learn
wrote:
the proper answer is too long to write (it will be more an article that
a forum answer ;-), so i'll just give you some directions:
import std.typecons;
{
auto b = scoped!B(); // `auto` is important here!
...
ed to learn a little bit more
about manual memory management, in case I might ever need it (not
for any particular application).
The D Language book Section 6.3.4-5 covers the topic. I basically
copied below and made some small changes.
import core.stdc.stdlib;
import std.stdio;
class B
On Friday, 28 February 2014 at 14:47:31 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be
deprecated. :P
And destroy doesn't finalize the data. :/ See:
http://forum.dlang.org/thread/bug-1225...@https.d.pur
On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be
deprecated. :P
And destroy doesn't finalize the data. :/ See:
http://forum.dlang.org/thread/bug-1225...@https.d.puremagic.com%2Fissues%2F
and
http://forum.dlang.org/thread/bu
On Friday, 28 February 2014 at 13:38:59 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with
delete it should also work with the current GC, or? Someone
should figure out why and how delete works this way.
On Friday, 28 February 2014 at 13:16:40 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that
with arrays I can not rely on that the struct DTors are called.
Yep, this bug has immediately got my vote :) It
On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with
delete it should also work with the current GC, or? Someone
should figure out why and how delete works this way. :)
Well, delete is deprecated so it can do any kind of arc
On Friday, 28 February 2014 at 12:54:32 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime
does not follow the spec. Curious. The current implementation
is not aware of strcut-destructors on the heap
On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that
with arrays I can not rely on that the struct DTors are called.
Yep, this bug has immediately got my vote :) It does require
someone knowledgable of GC to fix in forseeabl
On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime
does not follow the spec. Curious. The current implementation
is not aware of strcut-destructors on the heap, i.e. the
GC.BlkAttr.FINALIZE flag is not set for structs (
On Friday, 28 February 2014 at 10:40:17 UTC, Dicebot wrote:
On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger
wrote:
Sadly, this is incorrect as well. Because if such an object is
collected by the gc, but the gc decides not to run the
destructor, the buffer will never be free'd.
I t
On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger wrote:
Sadly, this is incorrect as well. Because if such an object is
collected by the gc, but the gc decides not to run the
destructor, the buffer will never be free'd.
I think you misiterpret the spec. If object is collected,
destr
I asked something similar some days ago. Maybe this provides some
information tat is helpful to you:
http://forum.dlang.org/thread/mekdjoyejtfpafpcd...@forum.dlang.org
On Thu, 27 Feb 2014 16:46:15 -0500, Simon Bürger
wrote:
I know the suggested way in D is to not deallocate the buffer at all,
but rely on the gc to collect it eventually. But it still puzzles me
that it seems to be impossible to do. Anybody have an idea how I could
make it work?
Unfort
On Thursday, 27 February 2014 at 22:15:41 UTC, Steven
Schveighoffer wrote:
On Thu, 27 Feb 2014 16:46:15 -0500, Simon Bürger [...]
More and more, I think a thread-local flag of "I'm in the GC
collection cycle" would be hugely advantageous -- if it doesn't
already exist...
I don't think it does
On Thursday, 27 February 2014 at 22:04:50 UTC, Namespace wrote:
A struct is a value type. So it is passed by value and is
placed on the stack.
{
S s;
}
S DTor is called at the end of the scope. So you can rely on
RAII as long as you use structs.
On the stack yes. But not on the heap:
A struct is a value type. So it is passed by value and is placed
on the stack.
{
S s;
}
S DTor is called at the end of the scope. So you can rely on RAII
as long as you use structs.
I am trying to implement a structure with value semantics which
uses an internal buffer. The first approach looks like this:
struct S
{
byte[] buf;
this(int size) { buf = new byte[size]; }
this(this) { buf = buf.dup; }
~this(this) { delete buf; }
}
T
Please post on[0] regarding better memory management. As
currently work is being done on rewriting the GC (which really
was needed).
[0] http://forum.dlang.org/post/lao9fn$1d70$1...@digitalmars.com
y awful for such an elegant language. Every area but memory
management is beautiful and can do what you like, but trying to
avoid the GC is downright painful and forces you to ditch much of
the safety D provides. Given that it is designed to be a systems
programming language & in such applicatio
On Sunday, 1 December 2013 at 02:29:42 UTC, bioinfornatics wrote:
On Saturday, 30 November 2013 at 08:35:23 UTC, Frustrated wrote:
I need to pass around some objects(specifically int[]) that
may be used by several other objects at the same time. While I
could clone these and free them when the
On Saturday, 30 November 2013 at 08:35:23 UTC, Frustrated wrote:
I need to pass around some objects(specifically int[]) that may
be used by several other objects at the same time. While I
could clone these and free them when the parent object is done
this wastes memory for no real reason except
On Saturday, 30 November 2013 at 12:51:46 UTC, Rene Zwanenburg
wrote:
On Saturday, 30 November 2013 at 08:35:23 UTC, Frustrated wrote:
I need to pass around some objects(specifically int[]) that
may be used by several other objects at the same time. While I
could clone these and free them when
On Saturday, 30 November 2013 at 08:35:23 UTC, Frustrated wrote:
I need to pass around some objects(specifically int[]) that may
be used by several other objects at the same time. While I
could clone these and free them when the parent object is done
this wastes memory for no real reason except
Frustrated:
I need to pass around some objects(specifically int[]) that may
be used by several other objects at the same time. While I
could clone these and free them when the parent object is done
this wastes memory for no real reason except ease of use.
Since many objects may contain a ptr
1 - 100 of 108 matches
Mail list logo
