On Mon, 29 Nov 2010 09:13:17 -0500
"Steven Schveighoffer" wrote:
> A class is a reference type. Every operation on a class instance operates
> on all aliases to that class, only assignment to another class instance of
> the same type decouples it.
>
> Consider these two statements:
>
> "a
On 29/11/2010 14:13, Steven Schveighoffer wrote:
On Fri, 26 Nov 2010 14:50:27 -0500, Bruno Medeiros
wrote:
On 09/11/2010 12:42, Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
wrote:
Well, if you can come up with a good definition for what "increasing
the siz
On Fri, 26 Nov 2010 14:50:27 -0500, Bruno Medeiros
wrote:
On 09/11/2010 12:42, Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
wrote:
Well, if you can come up with a good definition for what "increasing
the size of a class" would do, then maybe it should be
On 26/11/2010 21:30, Kagamin wrote:
Bruno Medeiros Wrote:
Making the array reallocate _every_ time that it's resized (to a greater
length) is actually not that unreasonable. Would it be highly
inneficient? Only if you write bad code. TDPL agrees with you, I quote:
Challenge: make D slower tha
On 26/11/2010 19:16, Andrei Alexandrescu wrote:
"
One easy way out would be to always reallocate a upon appending to it
[...]
Although that behavior is easiest to implement, it
has serious efficiency problems. For example, oftentimes arrays are
iteratively grown in a loop:
int[] a;
foreach (i; 0
On 26/11/2010 22:12, spir wrote:
On Fri, 26 Nov 2010 21:59:37 +
Bruno Medeiros wrote:
You could still do exponential capacity growth by manipulating the
length property, but yeah, that would create a host of complexity and
other issues (see my reply to Pelle). Yeah, my reasoning was really
them reference types,
and I would not feel this is inaccurate.
ARRGHH, actually this is not entirely true, I forgot about something:
null vs. empty arrays.
Indeed on assignment (and parameter passing) dynamic arrays work just
like reference types. The reallocation operations also don'
On Fri, 26 Nov 2010 21:59:37 +
Bruno Medeiros wrote:
> You could still do exponential capacity growth by manipulating the
> length property, but yeah, that would create a host of complexity and
> other issues (see my reply to Pelle). Yeah, my reasoning was really
> broken. :'(
What is th
On 26/11/2010 19:16, Andrei Alexandrescu wrote:
On 11/26/10 12:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can s
Bruno Medeiros Wrote:
> Making the array reallocate _every_ time that it's resized (to a greater
> length) is actually not that unreasonable. Would it be highly
> inneficient? Only if you write bad code. TDPL agrees with you, I quote:
Challenge: make D slower than C#.
On 26/11/2010 19:36, Pelle Månsson wrote:
On 11/26/2010 07:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can still
On Fri, 26 Nov 2010 19:50:27 +
Bruno Medeiros wrote:
> On 09/11/2010 12:42, Steven Schveighoffer wrote:
> > On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
> > wrote:
> >
> >> Well, if you can come up with a good definition for what "increasing
> >> the size of a class" would do, then may
On 09/11/2010 12:42, Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
wrote:
Well, if you can come up with a good definition for what "increasing
the size of a class" would do, then maybe it should be added.
It really doesn't matter. Arrays are their own type, th
On Fri, 26 Nov 2010 18:22:46 +
Bruno Medeiros wrote:
> Making the array reallocate _every_ time that it's resized (to a greater
> length) is actually not that unreasonable. Would it be highly
> inneficient? Only if you write bad code. TDPL agrees with you, I quote:
>
> "
> One easy way out
On 11/26/10 12:22 PM, Bruno Medeiros wrote:
On 09/11/2010 01:43, Jonathan M Davis wrote:
On Monday, November 08, 2010 16:50:46 so wrote:
D arrays very powerful but you first need to understand what is going
on.
You should check the book.
An inconsistency is the copy of static arrays at assignme
On 11/26/2010 07:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can still write
efficient code, and nearly as easily.
On 09/11/2010 01:43, Jonathan M Davis wrote:
On Monday, November 08, 2010 16:50:46 so wrote:
D arrays very powerful but you first need to understand what is going on.
You should check the book.
An inconsistency is the copy of static arrays at assignment, but necessary
one.
One thing i don't like
On Friday 12 November 2010 17:55:31 Rainer Deyke wrote:
> On 11/8/2010 17:43, Jonathan M Davis wrote:
> > D references are more like Java references.
>
> That's true for class references. D also supports pass-by-reference
> through the 'ref' keyword, which works like C++ references.
True. But ge
On 11/8/2010 17:43, Jonathan M Davis wrote:
> D references are more like Java references.
That's true for class references. D also supports pass-by-reference
through the 'ref' keyword, which works like C++ references.
--
Rainer Deyke - rain...@eldwood.com
On Tue, 09 Nov 2010 15:13:55 -0500, Pillsy wrote:
Steven Schveighoffer Wrote:
On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy wrote:
[...]
> Ah! This is a lot of what was confusing me about arrays; I still
thought
> they had this behavior. The fact that they don't makes me a good deal
> more
> > I see your point. You argue that the behavior is consistent. My point is
> > that this consistency can lead to bugs. I may forget the ref. But I'll
> > keep in mind to never forget the ref if it is needed.
> >
> > Jens
>
> Well, in the case of classes, I don't think it would be very common.
>
Jens Mueller Wrote:
> I see your point. You argue that the behavior is consistent. My point is
> that this consistency can lead to bugs. I may forget the ref. But I'll
> keep in mind to never forget the ref if it is needed.
>
> Jens
Well, in the case of classes, I don't think it would be very co
On Tue, 09 Nov 2010 15:13:55 -0500
Pillsy wrote:
> There's a difference between appending and appending in place. The problem
> with not appending in place (and arrays not having the possibility of a
> reserve that's larger than the actual amount, of course) is one of
> efficiency. Having
>
>
On 11/09/2010 09:36 AM, spir wrote:
On Mon, 8 Nov 2010 17:08:32 -0800
Jonathan M Davis wrote:
As Jesse says, they _are_ passed by reference. The struct itself _is_ the
reference.
(Well, that is a sensible redefinition of "reference"; but it is simply _not_
what the word means in any other c
Steven Schveighoffer Wrote:
> On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy wrote:
[...]
> > Ah! This is a lot of what was confusing me about arrays; I still thought
> > they had this behavior. The fact that they don't makes me a good deal
> > more comfortable with them, though I still don't lik
On Tue, 09 Nov 2010 07:42:13 -0500
"Steven Schveighoffer" wrote:
> I think of an array as a hybrid between a reference and a value type. The
> data is passed by reference, the length is passed by value. This mean
> changing the length only affects the local copy, but changing the data
> a
Steven Schveighoffer Wrote:
> It depends on your definition of reference type. I agree with Daniel. If
> you want to get into academic definitions, yes, 'technically' an array is
> a reference, but it's confusing to someone who's not interested in
> exploring the theoretical parts of compu
On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy wrote:
Steven Schveighoffer Wrote:
On Mon, 08 Nov 2010 18:29:27 -0500, Ali Çehreli
wrote:
[...]
> I must be remembering an old behavior. I think appending could
> affect the original if it had enough capacity.
Before the array append changes
Steven Schveighoffer Wrote:
> On Mon, 08 Nov 2010 18:29:27 -0500, Ali Ãehreli wrote:
[...]
> > I must be remembering an old behavior. I think appending could
> > affect the original if it had enough capacity.
> Before the array append changes were introduced (somewhere around
> 2.040 I think?),
On Mon, 08 Nov 2010 18:29:27 -0500, Ali Çehreli wrote:
Steven Schveighoffer wrote:
> No, it doesn't. If you are appending to data that was passed in, you
are
> not changing the *original data* passed in. You are only appending
to it.
I must be remembering an old behavior. I think appe
> > > I don't really have any good use-case examples. Maybe an initialization
> > > function? Developed your own number object (big int) and were thinking
> > > in terms of it being a refrence you thought
> > >
> > > a = a + BigInt(7);
> > >
> > > would result in a being resigned in the calling f
Steven Schveighoffer:
> I think of an array as a hybrid between a reference and a value type. The
> data is passed by reference, the length is passed by value. This mean
> changing the length only affects the local copy, but changing the data
> affects all arrays that point to that data.
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
wrote:
Well, if you can come up with a good definition for what "increasing the
size of a class" would do, then maybe it should be added.
It really doesn't matter. Arrays are their own type, the have their own
semantics. It does help to
On Tuesday 09 November 2010 02:43:57 Jens Mueller wrote:
> > > What's the general use of a = new A() in the above code? Where is it
> > > useful?
> > >
> > > Jens
> >
> > I don't really have any good use-case examples. Maybe an initialization
> > function? Developed your own number object (big in
> > What's the general use of a = new A() in the above code? Where is it
> > useful?
> >
> > Jens
>
> I don't really have any good use-case examples. Maybe an initialization
> function? Developed your own number object (big int) and were thinking in
> terms of it being a refrence you thought
>
On Tue, 9 Nov 2010 02:14:17 +0100
Daniel Gibson wrote:
> On Tue, Nov 9, 2010 at 1:24 AM, Jesse Phillips
> wrote:
> >
> > The array-struct is the reference, so it is what gets compared. That means
> > both the internal pointer and length must be the same. Just because the
> > reference is more
On Mon, 8 Nov 2010 17:08:32 -0800
Jonathan M Davis wrote:
> As Jesse says, they _are_ passed by reference. The struct itself _is_ the
> reference.
(Well, that is a sensible redefinition of "reference"; but it is simply _not_
what the word means in any other context.)
It is true that the inne
Daniel Gibson Wrote:
> On Tue, Nov 9, 2010 at 1:24 AM, Jesse Phillips
> wrote:
> >
> > The array-struct is the reference, so it is what gets compared. That means
> > both the internal pointer and length must be the same. Just because the
> > reference is more than an address does not make it an
Oh yeh you are right, i said reallocation. Should have said assignment.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
I didn't mean that one, check page 112 on
http://erdani.com/d/thermopylae.pdf
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On Monday, November 08, 2010 16:50:46 so wrote:
> D arrays very powerful but you first need to understand what is going on.
> You should check the book.
> An inconsistency is the copy of static arrays at assignment, but necessary
> one.
> One thing i don't like about D arrays is an undefined case i
On Tue, Nov 9, 2010 at 1:24 AM, Jesse Phillips
wrote:
>
> The array-struct is the reference, so it is what gets compared. That means
> both the internal pointer and length must be the same. Just because the
> reference is more than an address does not make it any less a reference.
>
Unlike in C
On Monday, November 08, 2010 13:54:28 spir wrote:
> On Mon, 08 Nov 2010 15:32:56 -0500
>
> Jesse Phillips wrote:
> > But they are past by reference. You can modify the data all you want, but
> > cannot reassign the reference itself.
>
> No, they are _not_ passed by reference. Stop saying that, t
On 11/8/10 4:50 PM, so wrote:
D arrays very powerful but you first need to understand what is going
on. You should check the book.
Or a mildly outdated but accurate preview of the relevant chapter:
http://erdani.com/d/thermopylae.pdf
Andrei
D arrays very powerful but you first need to understand what is going on.
You should check the book.
An inconsistency is the copy of static arrays at assignment, but necessary
one.
One thing i don't like about D arrays is an undefined case in dynamic
array reallocation.
--
Using Opera's rev
On Monday, November 08, 2010 16:11:46 so wrote:
> > I like that explanation. Jonathan is saying the same, I think. I'll
> > guess my misunderstanding is mainly caused by figuring out that a
> > reassign is happening and that a reassign to a reference changes the
> > reference. In C++ you cannot cha
spir Wrote:
> No, they are _not_ passed by reference. Stop saying that, this is precisely
> what causes confusion. This is reference semantics:
void main() {
auto a = new int[1];
auto b = a;
a[0] = 5;
assert(a == b);
assert(a[0] == b[0]);
assert(a is b);
writefln("%x == %x",
I like that explanation. Jonathan is saying the same, I think. I'll
guess my misunderstanding is mainly caused by figuring out that a
reassign is happening and that a reassign to a reference changes the
reference. In C++ you cannot change a reference (I hope I'm right
here.). When using a std::vec
Jens Mueller Wrote:
> I like that explanation. Jonathan is saying the same, I think.
Yes, same thing.
> In C++ you cannot change a reference (I hope I'm right
> here.). When using a std::vector one does not need to think about this.
Don't know too much about C++ references, but as mentioned som
Steven Schveighoffer wrote:
> No, it doesn't. If you are appending to data that was passed in, you are
> not changing the *original data* passed in. You are only appending
to it.
I must be remembering an old behavior. I think appending could affect
the original if it had enough capacity.
A
Kagamin wrote:
> Jens Mueller Wrote:
>
> > I find this behavior rather strange. Arrays are neither passed by value
> > (copying the whole array) nor by reference. I see reasons for doing it
> > like this, e.g. doing array = array[1..$] inside should not affect the
> > outside.
> > But I wonder whe
Jesse Phillips wrote:
> Jens Mueller Wrote:
>
> > Hi,
> >
> > I do not understand what's going on behind the scene with this code. Or
> > better said I have some idea but maybe I do not see the whole point.
> >
> > void foo(int[] array) {
> > array.length += 1000; // may copy the array
> >
On Mon, 08 Nov 2010 15:32:56 -0500
Jesse Phillips wrote:
> But they are past by reference. You can modify the data all you want, but
> cannot reassign the reference itself.
No, they are _not_ passed by reference. Stop saying that, this is precisely
what causes confusion. This is reference sema
Walter Bright schrieb:
Daniel Gibson wrote:
Daniel Gibson schrieb:
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natu
Daniel Gibson wrote:
Daniel Gibson schrieb:
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate.
It a
Jonathan M Davis:
> Daniel Gibson:
> > So maybe yet another solution would be to *really* pass dynamic arrays by
> > reference (like the doc pretends it's already done)?
>
> That would be a devastating change.
That's a solution that I have proposed lot of time ago, I did receive no
answers :-)
Jens Mueller Wrote:
> Hi,
>
> I do not understand what's going on behind the scene with this code. Or
> better said I have some idea but maybe I do not see the whole point.
>
> void foo(int[] array) {
> array.length += 1000; // may copy the array
> array[0] = 1;
> }
>
> auto a = new
On Monday 08 November 2010 12:07:39 spir wrote:
> On Mon, 08 Nov 2010 20:30:33 +0100
>
> Daniel Gibson wrote:
> > The documentation[1] says: "For dynamic array and object parameters,
> > which are passed by reference, in/out/ref apply only to the reference
> > and not the contents." So, by readin
Jens Mueller Wrote:
> I find this behavior rather strange. Arrays are neither passed by value
> (copying the whole array) nor by reference. I see reasons for doing it
> like this, e.g. doing array = array[1..$] inside should not affect the
> outside.
> But I wonder whether these semantics are well
On Mon, 08 Nov 2010 20:30:33 +0100
Daniel Gibson wrote:
> The documentation[1] says: "For dynamic array and object parameters, which
> are
> passed by reference, in/out/ref apply only to the reference and not the
> contents."
> So, by reading the documentation one would assume that dynamic arr
On Monday, November 08, 2010 11:30:33 Daniel Gibson wrote:
> >> So IMHO a compiler warning would be appropriate in that case.
> >>
> >> (It would be even better to have more consistent array handling
> >> throughout the different kinds of arrays, as I wrote in another branch
> >> of this thread,
On Monday, November 08, 2010 11:22:36 Ali Çehreli wrote:
> Steven Schveighoffer wrote:
> > On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
> >
> >> If you pass a dynamic array to a function and chance it's size within
> >> the function, you have undefined behaviour - you never know if it wil
On Mon, 08 Nov 2010 14:22:36 -0500, Ali Çehreli wrote:
Steven Schveighoffer wrote:
> On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
>> If you pass a dynamic array to a function and chance it's size within
>> the function, you have undefined behaviour - you never know if it
will
>> aff
Jonathan M Davis schrieb:
On Monday, November 08, 2010 10:35:38 Daniel Gibson wrote:
bearophile schrieb:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner
of D. I have had two or three bugs in my code because of that.
Steven Schveighoffer wrote:
> On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
>> If you pass a dynamic array to a function and chance it's size within
>> the function, you have undefined behaviour - you never know if it will
>> affect the original array (from the calling function) or not.
>
> No
On Mon, 08 Nov 2010 19:04:40 +0100
Daniel Gibson wrote:
> IMHO passing arrays to functions are really inconsistent in D2 anyway:
> static arrays are passed by value but dynamic arrays are passed by reference,
> but then again, as this thread shows, not really..
It may be better to have 2 kinds o
On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
wrote:
bearophile schrieb:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone
corner of D. I have had two or three bugs in my code because of that.
If you pass a dynam
On Monday, November 08, 2010 10:35:38 Daniel Gibson wrote:
> bearophile schrieb:
> > Jens Mueller:
> >> I find this behavior rather strange.
> >
> > I don't know if it's strange, but surely it is a little bug-prone corner
> > of D. I have had two or three bugs in my code because of that.
>
> If y
Daniel Gibson schrieb:
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate.
It also segues nicely into
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate. It
also segues nicely into hopeful future support
bearophile schrieb:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner of D.
I have had two or three bugs in my code because of that.
If you pass a dynamic array to a function and chance it's size within the
functio
On Monday, November 08, 2010 09:40:47 bearophile wrote:
> Jens Mueller:
> > I find this behavior rather strange.
>
> I don't know if it's strange, but surely it is a little bug-prone corner of
> D. I have had two or three bugs in my code because of that.
I don't know. I find it to be pretty strai
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2 (while
in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate. It
also segues nicely into hopeful future support for the CPU's vector
in
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2 (while
in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate. It also
segues nicely into hopeful future support for the CPU's vector instructions.
Vladimir Panteleev schrieb:
On Mon, 08 Nov 2010 19:30:03 +0200, Jens Mueller
wrote:
I find this behavior rather strange. Arrays are neither passed by value
(copying the whole array) nor by reference. I see reasons for doing it
like this, e.g. doing array = array[1..$] inside should not affect
On Mon, 08 Nov 2010 19:30:03 +0200, Jens Mueller
wrote:
I find this behavior rather strange. Arrays are neither passed by value
(copying the whole array) nor by reference. I see reasons for doing it
like this, e.g. doing array = array[1..$] inside should not affect the
outside.
Compare to t
Jens Mueller:
> I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner of D.
I have had two or three bugs in my code because of that.
> Arrays are neither passed by value
> (copying the whole array) nor by reference.
They are passed by "f
On Mon, 08 Nov 2010 20:30:03 +0300, Jens Mueller
wrote:
Hi,
I do not understand what's going on behind the scene with this code. Or
better said I have some idea but maybe I do not see the whole point.
void foo(int[] array) {
array.length += 1000; // may copy the array
array[
Hi,
I do not understand what's going on behind the scene with this code. Or
better said I have some idea but maybe I do not see the whole point.
void foo(int[] array) {
array.length += 1000; // may copy the array
array[0] = 1;
}
auto a = new int[1];
foo(a);
assert(a[0] == 1); //
79 matches
Mail list logo
