I read Andrei's chapter on arrays and there's one thing that concerns me. When
a slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influence
program testing and can it be exploited to attack a buggy system?
H
Bartosz Milewski wrote:
I read Andrei's chapter on arrays and there's one thing that concerns me. When
a slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influence
program testing and can it be exploited to
"Walter Bright" wrote in message
news:hdqea8$2mt...@digitalmars.com...
> Bartosz Milewski wrote:
>> I read Andrei's chapter on arrays and there's one thing that concerns
>> me. When a slice is extended, the decision to re-allocate, and
>> therefore to cut its connection to other slices, is
>> non
Bartosz Milewski wrote:
I read Andrei's chapter on arrays and there's one thing that concerns
me. When a slice is extended, the decision to re-allocate, and
therefore to cut its connection to other slices, is
non-deterministic.
It is not non-deterministic. Try it - you'll get the same results e
Nick Sabalausky wrote:
Deterministic? Only in the same sense that "resize or realloc upon
appending" is deterministic.
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for testing and debugg
Tim Matthews, el 16 de noviembre a las 15:05 me escribiste:
> Isn't the new kind of arrays created to fix this already? See T[new].
T[new] is gone.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG
On Mon, 16 Nov 2009 09:24:13 +0300, Walter Bright
wrote:
Nick Sabalausky wrote:
Deterministic? Only in the same sense that "resize or realloc upon
appending" is deterministic.
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same r
Denis Koroskin wrote:
It is *non*-deterministic. The decision to reallocate depends (or will
depend) on LRU and it may be cleared by another thread (e.g. another
thread may reset it manually or via a GC cycle run).
The LRU is thread local.
Walter Bright wrote:
Safe? Fuck no.
It's safe as in memory safe. This is as opposed to undefined-behavior,
which is not memory safe. A buffer overflow is an example of
undefined-behavior.
Even if it's memory safe, it could cause a bug. Look at Bartosz example
again; if the memory block get
grauzone wrote:
Even if it's memory safe, it could cause a bug. Look at Bartosz example
again; if the memory block gets copied really depends from the input
data length.
Yes, it could cause a bug. But it isn't undefined-behavior, it isn't
memory corruption, and it isn't non-deterministic.
Bartosz Milewski Wrote:
> I read Andrei's chapter on arrays and there's one thing that concerns me.
I tried to voice the same concern earlier, but my voice is not loud yet. ;)
> When a slice is extended, the decision to re-allocate, and therefore to cut
> its connection to other slices, is non-d
Walter Bright wrote:
> It's deterministic in the sense that if you run the program again with
> the same inputs, you will get the same result. This is a highly useful
> attribute for testing and debugging.
On the same platform, with the same compiler, compiler settings, and
standard library implem
Ali Cehreli wrote:
Bartosz Milewski Wrote:
I read Andrei's chapter on arrays and there's one thing that concerns me.
I tried to voice the same concern earlier, but my voice is not loud yet. ;)
When a slice is extended, the decision to re-allocate, and therefore to cut
its connection to othe
Rainer Deyke wrote:
Walter Bright wrote:
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for testing and debugging.
On the same platform, with the same compiler, compiler settings, and
standa
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> I read Andrei's chapter on arrays and there's one thing that concerns me.
> When a
slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influ
"Walter Bright" wrote in message
news:hdr6mm$1bf...@digitalmars.com...
> Rainer Deyke wrote:
>> Walter Bright wrote:
>>> It's deterministic in the sense that if you run the program again with
>>> the same inputs, you will get the same result. This is a highly useful
>>> attribute for testing and
Nick Sabalausky wrote:
Even if it is technically determinate if you run it on the same machine with
the same inputs, that still does nothing to address Bartosz's claim that
it's a potential security hole - Apps don't always get run on the same
machine with the same inputs.
It's not a security
Hello Walter,
Nick Sabalausky wrote:
Deterministic? Only in the same sense that "resize or realloc upon
appending" is deterministic.
It's deterministic in the sense that if you run the program again with
the same inputs, you will get the same result. This is a highly useful
attribute for tes
BCS wrote:
would you agree that it is not something the programer can predict in
advance?
He can, but it is not reasonable to expect him to. But it's still
deterministic.
Walter Bright Wrote:
> Denis Koroskin wrote:
> > It is *non*-deterministic. The decision to reallocate depends (or will
> > depend) on LRU and it may be cleared by another thread (e.g. another
> > thread may reset it manually or via a GC cycle run).
>
> The LRU is thread local.
It will then pr
Denis Koroskin Wrote:
> Walter Bright Wrote:
>
> > Denis Koroskin wrote:
> > > It is *non*-deterministic. The decision to reallocate depends (or will
> > > depend) on LRU and it may be cleared by another thread (e.g. another
> > > thread may reset it manually or via a GC cycle run).
> >
> > Th
Sean Kelly wrote:
Denis Koroskin Wrote:
Walter Bright Wrote:
Denis Koroskin wrote:
It is *non*-deterministic. The decision to reallocate depends
(or will depend) on LRU and it may be cleared by another thread
(e.g. another thread may reset it manually or via a GC cycle
run).
The LRU is thre
dsimcha Wrote:
>
> The one thing that I think has been missing from this discussion is, what
> would be
> the alternative if we didn't have this "non-deterministic" reallocation? How
> else
> could you **efficiently** implement dynamic arrays?
In the long run (D3), I proposed using the "uniqu
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> dsimcha Wrote:
> >
> > The one thing that I think has been missing from this discussion is, what
> > would be
> > the alternative if we didn't have this "non-deterministic" reallocation?
> > How else
> > could you **efficie
Walter Bright Wrote:
> BCS wrote:
> > would you agree that it is not something the programer can predict in
> > advance?
>
> He can, but it is not reasonable to expect him to. But it's still
> deterministic.
I've been following this discussion about determinism and I think it addresses
the pr
On Tue, Nov 17, 2009 at 4:38 PM, Bartosz Milewski
wrote:
> Walter Bright Wrote:
>
>> BCS wrote:
>> > would you agree that it is not something the programer can predict in
>> > advance?
>>
>> He can, but it is not reasonable to expect him to. But it's still
>> deterministic.
>
> I've been following
dsimcha wrote:
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
dsimcha Wrote:
The one thing that I think has been missing from this discussion is, what would
be
the alternative if we didn't have this "non-deterministic" reallocation? How
else
could you **efficiently**
Bartosz Milewski wrote:
Walter Bright Wrote:
BCS wrote:
would you agree that it is not something the programer can predict in
advance?
He can, but it is not reasonable to expect him to. But it's still
deterministic.
I've been following this discussion about determinism and I think it addres
Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
> >3. If you **really** care about performance, you should only append when you
> >don't know the length in advance. If you know the length, you should always
> >pre-allocate.
>
> We will have collections and all those good thing
Leandro Lucarella wrote:
Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
3. If you **really** care about performance, you should only append when you
don't know the length in advance. If you know the length, you should always
pre-allocate.
We will have collections and all t
Andrei Alexandrescu Wrote:
> My concern is the semantics of the language. As it is defined right now, a
> conforming implementation is free to use a quantum random number generator to
> decide whether to re-allocate or not. Is it likely? I don't think so; but the
> non-determinism is part of th
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
My concern is the semantics of the language. As it is defined right
now, a conforming implementation is free to use a quantum random
number generator to decide whether to re-allocate or not. Is it
likely? I don't think so; but the non-determini
Andrei Alexandrescu Wrote:
> Leandro Lucarella wrote:
> > Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
> >>> 3. If you **really** care about performance, you should only append when
> >>> you
> >>> don't know the length in advance. If you know the length, you should
> >>>
Andrei Alexandrescu Wrote:
> One thing that Bartosz didn't mention is that "this unique" is different
> than "the other unique", which I think reveals the half-bakedness of the
> proposal. "The other unique" that was intensively discussed before is
> transitive, meaning that the root reference
Andrei Alexandrescu, el 18 de noviembre a las 07:22 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
> >>>3. If you **really** care about performance, you should only append when
> >>>you
> >>>don't know the length in advance. If you
On Wed, 18 Nov 2009 13:21:49 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
>>> 3. If you **really** care about performance, you should only
append when you
>>> don't know the length
On Wed, 18 Nov 2009 14:03:11 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
One thing that Bartosz didn't mention is that "this unique" is different
than "the other unique", which I think reveals the half-bakedness of the
proposal. "The other unique" that was intensively discuss
On Thu, 19 Nov 2009 14:56:40 +0300, Steven Schveighoffer
wrote:
On Wed, 18 Nov 2009 13:21:49 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
>>> 3. If you **really** care about perf
On Thu, 19 Nov 2009 07:32:03 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
Slices are ranges. And ranges are *shrink-only*. Are you going to append
to your data structure? Use an Array instead. Slices are not suitable
for that purpose!
Arrays are ranges too. Just because the range int
Bartosz Milewski írta:
dsimcha Wrote:
The one thing that I think has been missing from this discussion is, what would
be
the alternative if we didn't have this "non-deterministic" reallocation? How
else
could you **efficiently** implement dynamic arrays?
In the long run (D3), I proposed us
On Thu, 19 Nov 2009 18:33:22 +0300, gzp wrote:
Bartosz Milewski írta:
dsimcha Wrote:
The one thing that I think has been missing from this discussion is,
what would be
the alternative if we didn't have this "non-deterministic"
reallocation? How else
could you **efficiently** implement d
Denis Koroskin wrote:
Same here. FWIW, I strongly believe demise of T[new] was a step in a
wrong direction, and I feel highly frustrated about it. It was one of
the most anticipated features that was asked for *years*! And it's gone
when it was so close to be implemented...
The only more or l
grauzone wrote:
Denis Koroskin wrote:
Same here. FWIW, I strongly believe demise of T[new] was a step in a
wrong direction, and I feel highly frustrated about it. It was one of
the most anticipated features that was asked for *years*! And it's
gone when it was so close to be implemented...
T
Steven Schveighoffer Wrote:
> > In fact, even after reading 4.1.9 I don't know what to expect in some
> > cases. Here's an example:
> >
> > int[] a = [0];
> > auto b = a;
> > a ~= 1;
> > b ~= 2;
> > What is a[1]?
> >
> > Is this considered "stomping" and requiring a re-allocation?
>
> a[1] woul
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> Steven Schveighoffer Wrote:
> > > In fact, even after reading 4.1.9 I don't know what to expect in some
> > > cases. Here's an example:
> > >
> > > int[] a = [0];
> > > auto b = a;
> > > a ~= 1;
> > > b ~= 2;
> > > What is a[1
Steven Schveighoffer Wrote:
> I wonder what your expert opinion is: Is something like unique possible
> without introducing all the other type modifiers (like 'lent', etc.)? If
> not, what are the minimum type modifiers you'd need to get unique to
> work? I really like the unique concept,
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
> Face it, D is a close to the metal language. Any attempt to define the spec
> at a
> purely abstract level without reference to any implementation details, and
> without
> leaving certain details implementation defined is absurd. I think
Leandro Lucarella wrote:
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
Face it, D is a close to the metal language. Any attempt to define the spec at
a
purely abstract level without reference to any implementation details, and
without
leaving certain details implementation defined is
Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
> Leandro Lucarella wrote:
> >dsimcha, el 19 de noviembre a las 23:21 me escribiste:
> >>Face it, D is a close to the metal language. Any attempt to define the
> >>spec at a
> >>purely abstract level without reference to any imple
On Fri, 20 Nov 2009 04:13:42 +0300, Andrei Alexandrescu
wrote:
Leandro Lucarella wrote:
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
Face it, D is a close to the metal language. Any attempt to define
the spec at a
purely abstract level without reference to any implementation det
Denis Koroskin wrote:
On Fri, 20 Nov 2009 04:13:42 +0300, Andrei Alexandrescu
wrote:
Leandro Lucarella wrote:
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
Face it, D is a close to the metal language. Any attempt to define
the spec at a
purely abstract level without reference to a
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
Leandro Lucarella wrote:
dsimcha, el 19 de noviembre a las 23:21 me escribiste:
Face it, D is a close to the metal language. Any attempt to define the spec at
a
purely abstract level without reference
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Leandro Lucarella wrote:
> > Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
> >> Leandro Lucarella wrote:
> >>> dsimcha, el 19 de noviembre a las 23:21 me escribiste:
> Face it, D is a close to th
Andrei Alexandrescu Wrote:
> I think one aspect that tends to be forgotten is that built-in arrays
> are the lowest abstraction - really just one small step above pointers.
> Efficiency lost there is lost forever. That's why I consider the current
> design adequate and the proposed designs less
dsimcha, el 20 de noviembre a las 03:35 me escribiste:
> 2. We state in the documentation that ~= on slices is a convenience that
> isn't
> terribly efficient and recommend that people that care more about performance
> than
> simplicity use the library type for their serious array building, esp
Andrei Alexandrescu, el 19 de noviembre a las 18:25 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
> >>Leandro Lucarella wrote:
> >>>dsimcha, el 19 de noviembre a las 23:21 me escribiste:
> Face it, D is a close to the metal langu
> int[] a = [0];
> auto b = a;
> a ~= 1;
> b ~= 2;
> What is a[1]?
>
> Is this considered "stomping" and requiring a re-allocation?
Can this question be answered without the recourse to implementation, and the
MRU cache in particular?
I thought about an abstract definition of "stomping".Somethi
Bartosz Milewski Wrote:
> > int[] a = [0];
> > auto b = a;
> > a ~= 1;
> > b ~= 2;
> > What is a[1]?
> >
> > Is this considered "stomping" and requiring a re-allocation?
>
> Can this question be answered without the recourse to implementation, and the
> MRU cache in particular?
>
> I thought a
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> > int[] a = [0];
> > auto b = a;
> > a ~= 1;
> > b ~= 2;
> > What is a[1]?
> >
> > Is this considered "stomping" and requiring a re-allocation?
> Can this question be answered without the recourse to implementation, and the
MR
dsimcha Wrote:
> Furthermore, the purpose of language design is to create a usable language
> first
> and foremost, and then figure out how to specify it formally and abstractly,
> not
> to create a perfectly bulletproof specification first and foremost and then
> hope
> that results in a usabl
Ali Cehreli Wrote:
> Neither 'a' nor 'b' own the elements; in that sense, if one is a slice then
> the other is a slice... In D, slices have "discretionary sharing semantics."
> Any slice may leave the sharing contract as it sees unfit.
So is your answer different from that of dsimcha? I'm sitt
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> Ali Cehreli Wrote:
> > Neither 'a' nor 'b' own the elements; in that sense, if one is a slice then
the other is a slice... In D, slices have "discretionary sharing semantics." Any
slice may leave the sharing contract as it see
dsimcha Wrote:
> == Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> > > int[] a = [0];
> > > auto b = a;
> > > a ~= 1;
> > > b ~= 2;
> > > What is a[1]?
> > >
> > > Is this considered "stomping" and requiring a re-allocation?
> > Can this question be answered without the reco
== Quote from Ali Cehreli (acehr...@yahoo.com)'s article
> dsimcha Wrote:
> > == Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> > > > int[] a = [0];
> > > > auto b = a;
> > > > a ~= 1;
> > > > b ~= 2;
> > > > What is a[1]?
> > > >
> > > > Is this considered "stomping" and req
Bartosz Milewski wrote:
Ali Cehreli Wrote:
Neither 'a' nor 'b' own the elements; in that sense, if one is a
slice then the other is a slice... In D, slices have "discretionary
sharing semantics." Any slice may leave the sharing contract as it
sees unfit.
So is your answer different from that
Andrei Alexandrescu Wrote:
> I'm not sure I figure what the issue is, and I'd appreciate a rehash of
> the few other issues brought up. (I thought they had been responded to.)
Some of the points are in my message from Sat, 05:19 pm. Especially this point:
Can a conforming implementation simply
On 2009-11-22 19:58:37 -0500, Andrei Alexandrescu
said:
It's very simple, really. Appending to an array never results in
overwriting elements of an existing array. Appending may terminate a
sharing relationship. This is simple, easy to understand, and requires
no understanding of the optimiz
On Thu, 19 Nov 2009 17:58:15 -0500, Bartosz Milewski
wrote:
Steven Schveighoffer Wrote:
> In fact, even after reading 4.1.9 I don't know what to expect in some
> cases. Here's an example:
>
> int[] a = [0];
> auto b = a;
> a ~= 1;
> b ~= 2;
> What is a[1]?
>
> Is this considered "stomping"
On Sun, 22 Nov 2009 21:19:15 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
I'm not sure I figure what the issue is, and I'd appreciate a rehash of
the few other issues brought up. (I thought they had been responded to.)
Some of the points are in my message from Sat, 05:19 pm.
On Sat, 21 Nov 2009 17:19:08 -0500, Bartosz Milewski
wrote:
int[] a = [0];
auto b = a;
a ~= 1;
b ~= 2;
What is a[1]?
Is this considered "stomping" and requiring a re-allocation?
Can this question be answered without the recourse to implementation,
and the MRU cache in particular?
I tho
Steven Schveighoffer, el 23 de noviembre a las 07:34 me escribiste:
> >Notice that you are using particular implementation detail (MRU
> >cache) to explain the semantics of D arrays. There is a very
> >important distinction between language specification and compiler
> >implementation. Andrei alrea
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
I'm not sure I figure what the issue is, and I'd appreciate a
rehash of the few other issues brought up. (I thought they had been
responded to.)
Some of the points are in my message from Sat, 05:19 pm. Especially
this point: Can a conforming
Andrei Alexandrescu Wrote:
> > Some of the points are in my message from Sat, 05:19 pm. Especially
> > this point: Can a conforming implementation simply re-allocate on
> > every expansion? You make it sound like that would violate some
> > performance guarantees but there are no specifics.
>
>
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
Some of the points are in my message from Sat, 05:19 pm. Especially
this point: Can a conforming implementation simply re-allocate on
every expansion? You make it sound like that would violate some
performance guarantees but there are no speci
On Mon, 23 Nov 2009 11:10:48 -0500, Leandro Lucarella
wrote:
Steven Schveighoffer, el 23 de noviembre a las 07:34 me escribiste:
>Notice that you are using particular implementation detail (MRU
>cache) to explain the semantics of D arrays. There is a very
>important distinction between languag
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Bartosz Milewski wrote:
> > Andrei Alexandrescu Wrote:
> >
> >
> >>> Some of the points are in my message from Sat, 05:19 pm. Especially
> >>> this point: Can a conforming implementation simply re-allocate on
> >>> every
On Mon, 23 Nov 2009 16:33:42 -0500, dsimcha wrote:
But one of my biggest gripes about the current appending implementation,
far more
important from a practical perspective than any theoretical safety
guarantees, is
that it doesn't scale to multiple threads. I've experienced this in a
real
On Mon, Nov 23, 2009 at 2:09 PM, Steven Schveighoffer
wrote:
> On Mon, 23 Nov 2009 16:33:42 -0500, dsimcha wrote:
>
>> But one of my biggest gripes about the current appending implementation,
>> far more
>> important from a practical perspective than any theoretical safety
>> guarantees, is
>> th
Bill Baxter wrote:
On Mon, Nov 23, 2009 at 2:09 PM, Steven Schveighoffer
wrote:
On Mon, 23 Nov 2009 16:33:42 -0500, dsimcha wrote:
But one of my biggest gripes about the current appending implementation,
far more
important from a practical perspective than any theoretical safety
guarantees,
Steven Schveighoffer, el 23 de noviembre a las 15:18 me escribiste:
> On Mon, 23 Nov 2009 11:10:48 -0500, Leandro Lucarella
> wrote:
>
> >Steven Schveighoffer, el 23 de noviembre a las 07:34 me escribiste:
> >>>Notice that you are using particular implementation detail (MRU
> >>>cache) to explain
Andrei Alexandrescu Wrote:
> sharing for ~=. Also I am not ruling out the possibility that we can
> guarantee a ~= that never keeps sharing with existing arrays. (One idea
> I discussed with Walter was encoding uniqueness of arrays in a bit
> stored with the array limits.)
I've been thinking th
On Mon, 23 Nov 2009 18:34:48 -0500, Leandro Lucarella
wrote:
Steven Schveighoffer, el 23 de noviembre a las 15:18 me escribiste:
On Mon, 23 Nov 2009 11:10:48 -0500, Leandro Lucarella
wrote:
>
>The thing is, with realloc() is less likely that you forget that the
data
>can be copied because
Steven Schveighoffer wrote:
[snip]
Andrei has mentioned that he thinks we can store the allocated length in
the GC block, which I think would also work. You also wouldn't need an
MRU cache in that case, but he says it's in *addition* to the MRU cache,
so I'm not sure what he means.
[snip]
Re
On Tue, 24 Nov 2009 11:01:10 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
[snip]
Andrei has mentioned that he thinks we can store the allocated length
in the GC block, which I think would also work. You also wouldn't need
an MRU cache in that case, but he says it's in *a
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:01:10 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
[snip]
Andrei has mentioned that he thinks we can store the allocated length
in the GC block, which I think would also work. You also wouldn't
need an MRU cache in that ca
On Tue, 24 Nov 2009 11:26:11 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:01:10 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
[snip]
Andrei has mentioned that he thinks we can store the allocated length
in the GC block, which I t
On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer
wrote:
The cache is a thread-local map from pointers to size_t. Using it does
not require any locking I think.
When reallocating, do you not also need to update the allocated length
in the heap, even if the allocation fits into th
On Tue, Nov 24, 2009 at 8:26 AM, Andrei Alexandrescu
wrote:
> Steven Schveighoffer wrote:
>>
>> On Tue, 24 Nov 2009 11:01:10 -0500, Andrei Alexandrescu
>> wrote:
>>
>>> Steven Schveighoffer wrote:
>>> [snip]
Andrei has mentioned that he thinks we can store the allocated length in
t
Bill Baxter wrote:
On Tue, Nov 24, 2009 at 8:26 AM, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:01:10 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
[snip]
Andrei has mentioned that he thinks we can store the allocated length in
the GC block
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer
wrote:
The cache is a thread-local map from pointers to size_t. Using it
does not require any locking I think.
When reallocating, do you not also need to update the allocated length
in the heap, even if t
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Steven Schveighoffer wrote:
> > On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer
> > wrote:
> >
> >
> >>> The cache is a thread-local map from pointers to size_t. Using it
> >>> does not require any locking I thi
On Tue, 24 Nov 2009 12:46:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer
wrote:
The cache is a thread-local map from pointers to size_t. Using it
does not require any locking I think.
When reallocating, do you
On Tue, 24 Nov 2009 12:46:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer
wrote:
The cache is a thread-local map from pointers to size_t. Using it
does not require any locking I think.
When reallocating, do you
On Tue, 24 Nov 2009 12:46:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
Lookup should be atomic without locking (I think, simply an integer
load right?), but you'd have to lock to actually do an append.
I don't think we solve the lock problem without having multiple
he
It's hard to argue whether something is or isn't bug prone and how severe the
bugs could be. An experienced programmer knows all the gotchas so he or she
will never introduce such bugs. A more bug-prone person will be afraid to speak
up in public so as not to appear stupid or be bullied away. It
On Tue, 24 Nov 2009 15:00:11 -0500, Bartosz Milewski
wrote:
It's hard to argue whether something is or isn't bug prone and how
severe the bugs could be. An experienced programmer knows all the
gotchas so he or she will never introduce such bugs. A more bug-prone
person will be afraid to
Steven Schveighoffer Wrote:
> > Imagine you're reviewing this code written by a relative newbee:
> >
> > char[] quote(char[] word) {
> > word.length += 2;
> > word[length-1] = '"';
> > for(int i = word.length-2; i > 0; --i)
> > word[i] = word[i - 1];
> > word[0] = '"';
> > return word
On Tue, 24 Nov 2009 16:52:52 -0500, Bartosz Milewski
wrote:
Steven Schveighoffer Wrote:
> Imagine you're reviewing this code written by a relative newbee:
>
> char[] quote(char[] word) {
> word.length += 2;
> word[length-1] = '"';
> for(int i = word.length-2; i > 0; --i)
> word[i]
Steven Schveighoffer Wrote:
> On Tue, 24 Nov 2009 16:52:52 -0500, Bartosz Milewski
> wrote:
>
> > Steven Schveighoffer Wrote:
> >> > Imagine you're reviewing this code written by a relative newbee:
> >> >
> >> > char[] quote(char[] word) {
> >> > word.length += 2;
> >> > word[length-1] = '
On Tue, 24 Nov 2009 17:35:43 -0500, Bartosz Milewski
wrote:
Steven Schveighoffer Wrote:
On Tue, 24 Nov 2009 16:52:52 -0500, Bartosz Milewski
wrote:
> Steven Schveighoffer Wrote:
>> > Imagine you're reviewing this code written by a relative newbee:
>> >
>> > char[] quote(char[] word) {
>>
1 - 100 of 121 matches
Mail list logo
