What is your definition of a dangling pointer?
A pointer pointing to freed memory, which presumably '&a[0]'
should be because it reallocates.
It seems that the '~=' operator "knows" that there's a reference
to 'a's old memory and it keeps it around instead of freeing it.
I just don't understa
On Wednesday, 3 January 2018 at 22:22:06 UTC, tipdbmp wrote:
x doesn't seem to be a dangling pointer, how come?
What is your definition of a dangling pointer?
In the shown example we have a reference to a piece of memory
containing 'x', so this memory is not freed, it's used by the
program.
char * get_dangling_ptr() {
char[] a;
a.reserve(15);
a ~= 'x';
char *x = &a[0];
auto a_initial_ptr = a.ptr;
foreach (_; 0 .. 30) {
a ~= 'y';
//a.assumeSafeAppend() ~= 'y';
}
assert(a.ptr != a_initial_ptr, "a should've reallocated");
// trying
On 12/31/17 7:50 AM, Steven Schveighoffer wrote:
Note, you can use a "sink" version of toString as well, and avoid the gc:
void toString(void delegate(const(char)[]) sink) @nogc
{
// use formatValue to push into the sink
}
I guess I'm missing some parameters here, g
opBinary(). scoped!
> won't work here.
>
> Is there a better to write vector3f class while avoiding GC?
Yeah, it doesn't make sense that a type of x, y, z should be a class.
I would stay with a struct here.
Sorry I am a bit disappointed. It seems writeln itself will check if
On Sunday, 31 December 2017 at 07:16:46 UTC, Tim Hsu wrote:
I came from C++ looking forward to D. Some languages require
programmers to use GC all the time. However, A lot of time we
don't really need GC especially when the time of destruction is
deterministic in compile time.
[...]
work here.
>
> Is there a better to write vector3f class while avoiding GC?
Yeah, it doesn't make sense that a type of x, y, z should be a
class. I would stay with a struct here.
Ali
Sorry I am a bit disappointed. It seems writeln itself will check
if the struct to be printed has toString. If not, it use default
struct printer.
ollowing
into Vector3f:
string toString() {
import std.string : format;
return format("%s,%s,%s", x, y, z);
}
> class version of Vector3f. Require new operator in opBinary(). scoped!
> won't work here.
>
> Is there a better to write vector3f class
I came from C++ looking forward to D. Some languages require
programmers to use GC all the time. However, A lot of time we
don't really need GC especially when the time of destruction is
deterministic in compile time.
I found that struct in D is allocate on stack by default. And we
ca
7;s why C# has the while dispose/IDisposable thing, and why
> > D code should either be using destroy to deal with freeing resources
> > for a class or using structs on the stack for resources that need to
> > be freed. Or alternate memory strategies can be used via
> > std.experim
on the stack for resources that need to
> be freed. Or alternate memory strategies can be used via
> std.experimental.allocator. The GC works great for lots of stuff but
> not for system resources. Honestly, in some ways, we'd be better off
> if D didn't even have finaliz
D's. It's why C# has the while dispose/IDisposable thing,
and why D code should either be using destroy to deal with freeing resources
for a class or using structs on the stack for resources that need to be
freed. Or alternate memory strategies can be used via
std.experimental.alloc
On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
I started to look into D very recently. I would like to know
the following, if you guys are so nice to help me:
1. What is the performance of D's GC, what trade-offs where
done in design , and if a in-deep prim
On Thursday, December 21, 2017 12:00:17 Mike Franklin via Digitalmars-d-
learn wrote:
> I'm not a big user of the standard library, but I believe most
> features of the standard library require the GC.
Actually, relatively little in Phobos explicitly uses the GC. There are some
On 23/12/2017 11:06 AM, Chris Katko wrote:
I'm having a strange stuttering issue in my game prototype. I use GC
allocations wildly for the heck of it at the moment--with eventual plans
to remove them.
However, I'm not positive it's the GC that's the problem, and if so, I
I'm having a strange stuttering issue in my game prototype. I use
GC allocations wildly for the heck of it at the moment--with
eventual plans to remove them.
However, I'm not positive it's the GC that's the problem, and if
so, I want to know exact lengths of time and fr
On Friday, 22 December 2017 at 00:09:31 UTC, Mike Franklin wrote:
What condition(s) would cause a destructor for an object that
is managed by the GC to potentially not be called?
Good question. It's true that barring an Error, they should be
called by the GC at runtime termination.
On Friday, 22 December 2017 at 23:34:55 UTC, Mengu wrote:
i really wonder how Objective-C and Swift is pulling this off.
It isn't a fundamental problem, D just can't express it in the
existing language (heck, even D, as defined, could do it, the
implementation just isn't there.)
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe
wrote:
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted doe
See also how dplug is implemented
https://forum.dlang.org/post/hbmbztydvyfwemfne...@forum.dlang.org
through by the GC
even though the only remaining array slice has a shorter
length. Whatever the reason was, it left me with the very
unpleasant prospect of silently accumulating file descriptor
leaks.
Last I checked, the GC doesn't understand arrays. It only
understands "segment of m
that the same non-guarantee exists in other GC'd
languages, such as Java or C#.
-Steve
Except for that in C# you have the IDisposable interface, which
can actually be used to prevent this kind of stuff and generally
used to clean up non-GC memory.
On Friday, 22 December 2017 at 00:09:31 UTC, Mike Franklin wrote:
What condition(s) would cause a destructor for an object that
is managed by the GC to potentially not be called?
Here:
===
import std.stdio;
class Clazz {
~this() {
writeln("Class dest");
they will be called.
I understand that we can't deterministically predict when a
destructor will be called, but if we can't deterministically
predict if a destructor will be called, that seems asinine.
What condition(s) would cause a destructor for an object that is
managed by
On Thursday, 21 December 2017 at 18:48:38 UTC, H. S. Teoh wrote:
Alas, RefCounted doesn't work well with inheritance...
Oh? What's the issue?
Implicit casts don't work so you can't pass a RefCounted!Class as
RefCounted!Interface except in simple cases using alias this
tricks.
On 12/20/17 9:57 PM, Mike Franklin wrote:
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify with:
"The garbage collector
On Thu, Dec 21, 2017 at 06:45:27PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
> > When the scoped destruction of structs isn't an option, RefCounted!T
> > seems to be a less evil alternative than an unreliable class dtor.
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted doesn't work well with inheritance...
Though, what you could do is make
rformance, and scope no longer helps me there. At first I
thought, no problem, the GC would handle this for me. Right?
Wrong. Even calling GC.collect directly did not guarantee the DB handle
was closed at the right time. This may have been a bug in my code that
left dangling references to it, o
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:
[...]
[...]
[...]
The root of the problem is that in D, class destruction and
finalization are conflated. It would be much more accurate to
refer to ~this in
On Thursday, 21 December 2017 at 14:26:55 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker
wrote:
That's what I've taken to doing manually, by implementing a
`terminate` function in my classes that I either call directly
or via a ref-counted templated stru
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
That's what I've taken to doing manually, by implementing a
`terminate` function in my classes that I either call directly
or via a ref-counted templated struct called Terminator.
I feel like I'm rambling but..
The problem with
On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
I started to look into D very recently. I would like to know
the following, if you guys are so nice to help me:
1. What is the performance of D's GC, what trade-offs where
done in design , and if a in-deep prim
On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
I started to look into D very recently. I would like to know
the following, if you guys are so nice to help me:
1. What is the performance of D's GC, what trade-offs where
done in design , and if a in-deep prim
On 21/12/2017 10:49 AM, Dan Partelly wrote:
I started to look into D very recently. I would like to know the
following, if you guys are so nice to help me:
1. What is the performance of D's GC, what trade-offs where done in
design , and if a in-deep primer on efficient usage and gotch
I started to look into D very recently. I would like to know the
following, if you guys are so nice to help me:
1. What is the performance of D's GC, what trade-offs where done
in design , and if a in-deep primer on efficient usage and
gotchas of the current implementation exists.
On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:
On Thursday, 21 December 2017 at 02:57:00 UTC, Mike Franklin
Unfortunately, that doesn't really shed much light on this
oddity. So, specifically, under what circumstances are
destructors not called?
When the GC is un
On Thursday, 21 December 2017 at 02:57:00 UTC, Mike Franklin
wrote:
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify wit
"Don't expect class destructors to be called at all by the GC"
I was a bit shocked to read that here:
https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
The document tries to clarify with:
"The garbage collector is not guaranteed to run the destructors
On Monday, 18 December 2017 at 07:03:14 UTC, Andrew Benton wrote:
[snip]
Looking at dmd's gc profile, it looks like only
std.array.Appender!string has allocated enough to be the culprit.
End program memory was 110MB and the Appender!string had
allocated 127MB totaly with Appender!
I'm looking for a memory leak in my use of vibe.d JSON objects.
The gc profiler built into the runtime only shows allocation
count and allocation bytes, so I can make guesses around what
might have leaked, but I can't be sure where or when, or exactly
what leaked.
I'm sure s
On Thursday, 16 November 2017 at 17:39:02 UTC, Petar Kirov
[ZombineDev] wrote:
https://github.com/ldc-developers/ldc/blob/master/gen/passes/GarbageCollect2Stack.cpp
Does this include GC allocations that don't fit on stack?
On Thursday, 16 November 2017 at 17:29:56 UTC, Nordlöw wrote:
Are there any plans on a compiler pass that finds scoped
GC-allocations and makes their destructors deterministic
similar to D's struct scope behaviour?
https://github.com/ldc-developers/ldc/blob/master/gen/p
Are there any plans on a compiler pass that finds scoped
GC-allocations and makes their destructors deterministic similar
to D's struct scope behaviour?
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
t:
ptr: 7FD9B63CD000, capacity: 255, length: 250
ptr: 7FD9B63CD000, capacity: 255, length: 251
> I compiled it with 'dmd test.d -profile=gc'
>
> After running it, the profile report was :-
>
> bytes allocated, allocations, type, function, file:line
>
writeln(array.length, " elements ", array);
}
I compiled it with 'dmd test.d -profile=gc'
After running it, the profile report was :-
bytes allocated, allocations, type, function, file:line
2000 1 int[] D main test.d:5
On Monday, 4 September 2017 at 14:42:45 UTC, Azi Hassan wrote:
On Monday, 4 September 2017 at 05:45:18 UTC, Vino.B wrote:
In order to resolve the issue "Using closure causes GC
allocation" it was stated that we need to use delegates
Alternatively you can drop the functional style
On Monday, 4 September 2017 at 05:45:18 UTC, Vino.B wrote:
In order to resolve the issue "Using closure causes GC
allocation" it was stated that we need to use delegates
Alternatively you can drop the functional style and use a foreach
loop that doesn't require delegates,
er to resolve the issue "Using closure causes GC
allocation" it was stated that we need to use delegates, can
you please help me on how to as i have not gone that much far
in D programming.
import std.stdio: File,writeln;
import std.datetime.systime: Clock, days, SysTime;
import std
tring, string)[]`
instead of `string[][]`), or let the compiler infer it via
auto (`auto cleanFiles(...`).
Hi,
Thank you very much, was able to resolve the second code issue
by changing the return type of the function.
Hi,
In order to resolve the issue "Using closure causes GC
allo
On Saturday, 2 September 2017 at 20:10:58 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 18:59:30 UTC, Vino.B wrote:
[...]
Cannot reproduce under Linux with dmd 2.076.0 (with commented
out Windows-only check). I'll try to see what happens on
Windows once I have a VM setup.
[
x27;t happen at runtime and no GC call is
necessary). Since you don't actually use the array, get rid
of it:
[...]
Hi,
Thank you for your help and the DMD version that i am using
is DMD 2.076.0 and yes I am on windows.
Please post a compilable, minimal example including how that
of `[a.name]`. You request a new
array: the memory for this has to be allocated (the reason
why the compiler says "may" is because sometimes, e.g. if the
array literal itself contains only literals, the allocations
needn't happen at runtime and no GC call is necessary). S
allocated (the reason why
the compiler says "may" is because sometimes, e.g. if the
array literal itself contains only literals, the allocations
needn't happen at runtime and no GC call is necessary). Since
you don't actually use the array, get rid of it:
[...]
Hi,
is because sometimes, e.g. if the array
literal itself contains only literals, the allocations needn't
happen at runtime and no GC call is necessary). Since you don't
actually use the array, get rid of it:
[...]
Hi,
Thank you for your help and the DMD version that i am using is
On Saturday, 2 September 2017 at 17:43:08 UTC, Vino.B wrote:
Hi All,
Request your help on how to solve the issue in the below
code as when i execute the program with -vgc it state as below:
NewTD.d(21): vgc: using closure causes GC allocation
NewTD.d(25): vgc: array literal may cause GC
Hi All,
Request your help on how to solve the issue in the below code
as when i execute the program with -vgc it state as below:
NewTD.d(21): vgc: using closure causes GC allocation
NewTD.d(25): vgc: array literal may cause GC allocation
void logClean (string[] Lglst, int LogAge
line tools I open-sourced haven't any problems
with GC. They are only one type of app, perhaps better suited to
GC than other apps, but still, it is a reasonable data point.
I've done rather extensive benchmarking against similar tools
written in native languages, mostly C. The D to
On Tuesday, 29 August 2017 at 00:52:11 UTC, Cecil Ward wrote:
I don't know when the GC actually gets a chance to run.
Another alternative that I *think* (maybe someone who knows a bit
more about the gc can chime in?) would work is if you manually
stopped the gc then ran collections
a panacea, but it's also not the boogyeman some people
make it out to be. You can let the GC do it's thing most of the
time and not worry about it. For the times when you do need to
worry about it, there are tools available to mitigate its impact.
I don't know when the GC actu
On 08/28/2017 06:25 PM, Ali Çehreli wrote:
I don't like the current format of the page
Apparently, I was looking for this one:
https://dlang.org/blog/the-gc-series/
Ali
I don't like the current format of the page (all articles are expanded
as opposed to being an index page) but there are currently four D blog
articles on GC and memory management:
https://dlang.org/blog/category/gc/
Ali
ting stuff myself.
>
> I don't know when the GC actually gets a chance to run.
Normally, it's only run when you call new. When you call new, if it thinks
that it needs to do a collection to free up some space, then it will.
Otherwise, it won't normally ever run, because it's
D's GC is stop the world (aka all threads) and does not run on its own
(requires being asked to collect).
It is only given the opportunity to collect when you allocate (new/more)
memory. It can decide not to, or to do so at any point making it very
unpredictable.
This is why we keep s
I am vacillating - considering breaking a lifetime's C habits and
letting the D garbage collector make life wonderful by just
cleaning up after me and ruining my future C disciple by not
deleting stuff myself.
I don't know when the GC actually gets a chance to run.
I am wondering i
On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:
I would like to learn more about GC in D. [...]
It would be great if you could point me out to articles on this
subject.
The primary locations to get information are the language
specification [1] and the druntime documentation [2].
I
On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:
I would like to learn more about GC in D. For example can
anyone explain why do we need memset(0) here:
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there
On 30/07/2017 10:12 AM, piotrekg2 wrote:
I would like to learn more about GC in D. For example can anyone explain
why do we need memset(0) here:
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 ,
doesn't it assume a certain type of GC? What if there is a need to
c
I would like to learn more about GC in D. For example can anyone
explain why do we need memset(0) here:
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future?
It wou
On 07/15/2017 03:05 PM, tetyys wrote:
On Friday, 14 July 2017 at 17:24:05 UTC, Suliman wrote:
GC on 32-bit machine show a lot of bugs.
such as..?
D's GC is conservative i.e. it cannot assume an integer is not a
pointer. There are ways around this such as marking the memory block as
On Friday, 14 July 2017 at 17:24:05 UTC, Suliman wrote:
GC on 32-bit machine show a lot of bugs.
such as..?
On Friday, 14 July 2017 at 14:50:04 UTC, bauss wrote:
On Friday, 14 July 2017 at 13:16:17 UTC, Suliman wrote:
It's look that GC in D is really suxx. There is already second
toy-project where I am getting stuck on Windows with D for
last 3 month.
I'm using 32-bit build, becau
On Friday, 14 July 2017 at 13:16:17 UTC, Suliman wrote:
It's look that GC in D is really suxx. There is already second
toy-project where I am getting stuck on Windows with D for last
3 month.
I'm using 32-bit build, because I can't understand which libs I
should use to get
It's look that GC in D is really suxx. There is already second
toy-project where I am getting stuck on Windows with D for last 3
month.
I'm using 32-bit build, because I can't understand which libs I
should use to get OpenSSL 64 bit work with dlang-request.
32-bit version co
They are for static data an thread-local storage.
On 04/22/2017 08:56 AM, Kagamin wrote:
.rdata is fine, but afaik you have only strings there, the rest - .data,
.bss, .tls will suffer the same issue.
I don't know anything about the various object file sections. :/
On Thursday, 20 April 2017 at 20:26:06 UTC, Nick Sabalausky
(Abscissa) wrote:
(even if it's from a C lib)
Same for D: .rdata is fine, but afaik you have only strings
there, the rest - .data, .bss, .tls will suffer the same issue.
On 04/20/2017 09:00 AM, Kagamin wrote:
https://issues.dlang.org/show_bug.cgi?id=15723
Hmm, so apparently embedded data (even if it's from a C lib) can also be
a source of false pointers. Thanks, good to know.
https://issues.dlang.org/show_bug.cgi?id=15723
t to
NO_SCAN? (I assume not "always", as that would be silly.) If
"sometimes", what are the conditions?
A couple specific examples:
3. Are there any situations where a (for example) int[] or
long[] that is stored on the GC heap could lead to false
pointers?
4. Same que
quot;sometimes", what are the conditions?
A couple specific examples:
3. Are there any situations where a (for example) int[] or long[] that
is stored on the GC heap could lead to false pointers?
4. Same question as #3, but if it's an array of structs, and the struct
type contains no members that are statically-typed as pointers.
On Saturday, 11 February 2017 at 03:21:29 UTC, mashomee wrote:
Hi, everyone.
I have a thread running in Dll. But it always halts because of
access violation exception when GC begins collecting.
[...]
It's great that you're found a workaround. If you weren't doing
som
problem solved now.
Just not use gc_setProxy.
Hi, everyone.
I have a thread running in Dll. But it always halts because of
access violation exception when GC begins collecting.
This is the thread stack frame in vs2013.
testSendSms.exe!_D4core6thread6Thread9isRunningMFNbNdZb() + 0x1
bytes D
testSendSms.exe
rather to
prevent use-after-free bugs.
No, the main point of GC is to prevent leaks in the case where
you have circular references.
Precise GCs don't leak, by definition. If the object is reachable
then it isn't a leak.
Now, you might claim that objects that provably won't be
e.g. a csv parser with some complex data structure creation
+ manipulation.
I have some real world code here[0] that uses it. Not only is
there less allocations and uses the GC but also it ends up
being significantly faster!
[0]
https://gist.github.com/rikkimax/42c3dfa6500155c5e441cbb1437142e
I have some real world code here[0] that uses it. Not only is there less
allocations and uses the GC but also it ends up being significantly faster!
[0]
https://gist.github.com/rikkimax/42c3dfa6500155c5e441cbb1437142ea#file-reports-d-L124
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:
- Automatic but conservative. Can leak at any time. You have to
implement manual management (managed heaps) to avoid leaks.
Leaks are hard to find as any heap value may be causing it.
By "managed heap" I just meant the GC hea
All GCs are prone to leak, including precise ones. The point of
garbage collection is not to prevent leaks, but rather to
prevent use-after-free bugs.
Of course I can have leaks in a GC environment, but having
non-deterministic leaks is another thing, and I'd rather make
sure to dele
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:
- Automatic but conservative. Can leak at any time.
All GCs are prone to leak, including precise ones. The point of
garbage collection is not to prevent leaks, but rather to prevent
use-after-free bugs.
Granted, the D 32 bit GC is
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:
I'm surprised that D was able to come this far with this.
It's used mostly for server software. Things are moving to 64
bit, so this will be less of an issue.
On Saturday, 4 February 2017 at 11:09:21 UTC, thedeemon wrote:
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
I'm wondering what
are the implications of the fact that current GC is a
Boehm-style conservative
GC rather than a precise one, I've never worked with a
conse
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
I'm wondering what
are the implications of the fact that current GC is a
Boehm-style conservative
GC rather than a precise one, I've never worked with a
conservative GC before.
Are there any disallowed memory operations? C
sider something else
until D's memory management story gets better. This is sad
because the language otherwise looks quite good, and I'd love
to try assertions, contracts, scope guards, macros etc.
you can use less auto GC. use the RC to replace the GC.
https://github.com/huntlabs/SmartRef
On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote:
Leaks are likely in 32-bit processes and unlikely in 64-bit
processes. See e.g.
https://issues.dlang.org/show_bug.cgi?id=15723
This looks pretty bad. I think I'll consider something else until
D's memory management story gets better.
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
Are there any disallowed memory operations?
Currently can't touch GC from destructor during collection.
Another concern is interoperability with C-allocated memory: GC
knows nothing about C heap.
How often does it leak?
On Wednesday, 1 February 2017 at 09:50:42 UTC, osa1 wrote:
Thanks for the answer. Could you elaborate on the lacklustre
part? It's fine if I have to do manual memory management, but I
don't want any leaks. Ideally I'd have a precise GC + RAII
style resource management when nee
701 - 800 of 1697 matches
Mail list logo
