On Sun, 04 Apr 2010 09:28:44 -0400, Michel Fortin
wrote:
On 2010-04-03 23:21:48 -0400, Andrei Alexandrescu
said:
On 04/02/2010 03:53 PM, Walter Bright wrote:
dsimcha wrote:
I almost never do this with any data structure other
than an array because, even if it works for now, I consider
On 2010-04-04 09:45:36 -0400, dsimcha said:
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
Question: if the container's memory isn't garbage-collected, how do you
implement iterators, eh, ranges so that they are still memory-safe?
The way I'm picturing this being implement
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> Question: if the container's memory isn't garbage-collected, how do you
> implement iterators, eh, ranges so that they are still memory-safe?
The way I'm picturing this being implemented is that a GC'd class instance
exists
at th
On 2010-04-03 23:21:48 -0400, Andrei Alexandrescu
said:
On 04/02/2010 03:53 PM, Walter Bright wrote:
dsimcha wrote:
I almost never do this with any data structure other
than an array because, even if it works for now, I consider it a horrible
violation of encapsulation because you're relying
On 04/02/2010 03:53 PM, Walter Bright wrote:
dsimcha wrote:
I almost never do this with any data structure other
than an array because, even if it works for now, I consider it a horrible
violation of encapsulation because you're relying on the details of
how the data
structure manipulates memory
Steve Teale wrote:
On Sat, 03 Apr 2010 06:24:20 +, Steve Teale wrote:
On Fri, 02 Apr 2010 23:01:48 -0700, Walter Bright wrote:
Since it is single-threaded, it should crash in the same place in
the
same way every time. This means you can put an assert on the crashing
data (even without g
Steve Teale wrote:
On Sat, 03 Apr 2010 06:24:20 +, Steve Teale wrote:
On Fri, 02 Apr 2010 23:01:48 -0700, Walter Bright wrote:
Since it is single-threaded, it should crash in the same place in
the
same way every time. This means you can put an assert on the crashing
data (even without g
On Sat, 03 Apr 2010 06:24:20 +, Steve Teale wrote:
> On Fri, 02 Apr 2010 23:01:48 -0700, Walter Bright wrote:
>
>>> > Since it is single-threaded, it should crash in the same place in
>>> > the
>> same way every time. This means you can put an assert on the crashing
>> data (even without gdb
On Fri, 02 Apr 2010 23:01:48 -0700, Walter Bright wrote:
>> > Since it is single-threaded, it should crash in the same place in the
> same way every time. This means you can put an assert on the crashing
> data (even without gdb it can be found by inserting printf's), and
> slowly work it backwar
Jordi wrote:
Walter Bright wrote:
Jordi wrote:
I am having exactly the same situation.
Any chance you can reduce it to a small test case?
Actually i am trying to add an "autotest" mode to my project to be able
to test and benchmark different compiler versions, compilation options
and even
Walter Bright wrote:
Jordi wrote:
I am having exactly the same situation.
Any chance you can reduce it to a small test case?
Actually i am trying to add an "autotest" mode to my project to be able
to test and benchmark different compiler versions, compilation options
and even GC implementa
Jordi wrote:
I am having exactly the same situation.
Any chance you can reduce it to a small test case?
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
Has anyone else still been noticing difficult to reproduce memory corruption
issues in the presence of associative
dsimcha wrote:
I almost never do this with any data structure other
than an array because, even if it works for now, I consider it a horrible
violation of encapsulation because you're relying on the details of how the data
structure manipulates memory. This is also why, when I designed RandAA I
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> dsimcha wrote:
> > == Quote from Walter Bright (newshou...@digitalmars.com)'s article
> >> dsimcha wrote:
> >>> Has anyone else still been noticing difficult to reproduce memory
> >>> corruption
> >>> issues in the presence of as
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
Has anyone else still been noticing difficult to reproduce memory corruption
issues in the presence of associative arrays with 2.042? They seem to happen
very infrequently and non-deterministically
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> dsimcha wrote:
> > Has anyone else still been noticing difficult to reproduce memory corruption
> > issues in the presence of associative arrays with 2.042? They seem to
> > happen
> > very infrequently and non-deterministically
On Fri, 02 Apr 2010 13:15:36 -0400, dsimcha wrote:
Has anyone else still been noticing difficult to reproduce memory
corruption
issues in the presence of associative arrays with 2.042? They seem to
happen
very infrequently and non-deterministically. I can only reproduce them
in the
conte
On Fri, 02 Apr 2010 13:15:36 -0400, dsimcha wrote:
Has anyone else still been noticing difficult to reproduce memory
corruption
issues in the presence of associative arrays with 2.042? They seem to
happen
very infrequently and non-deterministically. I can only reproduce them
in the
conte
dsimcha wrote:
Has anyone else still been noticing difficult to reproduce memory corruption
issues in the presence of associative arrays with 2.042? They seem to happen
very infrequently and non-deterministically. I can only reproduce them in the
context of a large program. However, they don't
Has anyone else still been noticing difficult to reproduce memory corruption
issues in the presence of associative arrays with 2.042? They seem to happen
very infrequently and non-deterministically. I can only reproduce them in the
context of a large program. However, they don't occur in 2.040 (
21 matches
Mail list logo
