www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: dcollections 1.0 and 2.0a beta released

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
superdan Wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 superdan Wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 Is there some other reason to use structs besides copy construction?
 -Steve



 memory management n shit. with a struct u can use refcounting n malloc n
realloc n
 shit. still stays a reference type. nothing gets fucked up.






 freedom for memory allocation schemes.
 
 how do u set up yer custom allocator to free memory? u cant tell when its ok.
 copying refs iz under da radar. dats my point.



It frees an element's memory when the element is removed from the container. 
The container itself is managed by the GC.


 

 den there's all that null ref shit. with a class u have

 void foo(container!shit poo)
 {
     poo.addElement(Shit(diarrhea));
 }

 dat works with struct but don't work with motherfucking classes. u need to
write.

 void foo(container!shit poo)
 {
     if (!poo) poo = new container!shit; // fuck dat shit
     poo.addElement(Shit(diarrhea));
 }

 u feel me?






 wut? it don't work? whaddaya mean it dun work? is you crazy? what dun work?
maybe
 therez sum misundercommunication.



void foo(int[int] x)
{
   x[5] = 5;
}

void main()
{
   int[int] x;
   foo(x);
   assert(x[5] == 5); // fails
}

-Steve
May 21 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:

 superdan Wrote:


 =3D=3D Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 superdan Wrote:

 =3D=3D Quote from Steven Schveighoffer (schveiguy yahoo.com)'s artic=













 Is there some other reason to use structs besides copy constructio=
















 -Steve



 memory management n shit. with a struct u can use refcounting n mall=













 shit. still stays a reference type. nothing gets fucked up.













 friend. =A0The custom allocator ability in dcollections should provide p=







 freedom for memory allocation schemes.

 how do u set up yer custom allocator to free memory? u cant tell when it=







 copying refs iz under da radar. dats my point.



 It frees an element's memory when the element is removed from the contain=




 den there's all that null ref shit. with a class u have

 void foo(container!shit poo)
 {
 =A0 =A0 poo.addElement(Shit(diarrhea));
 }

 dat works with struct but don't work with motherfucking classes. u n=













 void foo(container!shit poo)
 {
 =A0 =A0 if (!poo) poo =3D new container!shit; // fuck dat shit
 =A0 =A0 poo.addElement(Shit(diarrhea));
 }

 u feel me?






 wut? it don't work? whaddaya mean it dun work? is you crazy? what dun wo=







 therez sum misundercommunication.



 void foo(int[int] x)
 {
 =A0 x[5] =3D 5;
 }

 void main()
 {
 =A0 int[int] x;
 =A0 foo(x);
 =A0 assert(x[5] =3D=3D 5); // fails
 }



And with arrays at least it's even more insidious, because sometimes
it will seem to work, and sometimes it won't.
void foo(int[] x) {
    x ~=3D 10;
}
Caller's .length will never get updated by that, but it won't crash so
it may take a while to find the bug.

Very easy bug to get caught by in D.  I'm pretty sure that one's
zapped me three or four times at least.  Probably because I started
thinking I wasn't going to modify the length of an array in a
particular function, then later I decide to (or in some function that
function calls).

--bb
May 21 2010
parent reply BCS <none anon.com> writes:
Hello Bill,


 On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:
 

 void foo(int[int] x)
 {
 x[5] = 5;
 }
 void main()
 {
 int[int] x;
 foo(x);
 assert(x[5] == 5); // fails
 }



 it will seem to work, and sometimes it won't.
 void foo(int[] x) {
 x ~= 10;
 }
 Caller's .length will never get updated by that, but it won't crash so
 it may take a while to find the bug.



Maybe the style rule should be: dynamic arrays and AA's should be passed 
as const or ref.  

-- 
... <IXOYE><
May 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 Maybe the style rule should be: dynamic arrays and AA's should be passed 
 as const or ref.  



Something like that must be enforced by the compiler, or the design of
arrays/AAs must be changed.

Bye,
bearophile
May 22 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/22/2010 12:20 PM, bearophile wrote:

 BCS:

 Maybe the style rule should be: dynamic arrays and AA's should be passed
 as const or ref.



 Something like that must be enforced by the compiler, or the design of
arrays/AAs must be changed.

 Bye,
 bearophile



It's not a very good rule anyway:

void inc_all(int[] xs) {
     foreach (ref x; xs) {
         x += 1;
     }
}

Wouldn't gain anything from ref, and wouldn't work with const.
May 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Pelle:


 It's not a very good rule anyway:
 
 void inc_all(int[] xs) {
      foreach (ref x; xs) {
          x += 1;
      }
 }
 
 Wouldn't gain anything from ref, and wouldn't work with const.



You are wrong, it works correctly with ref:

import std.stdio: writeln;

void inc_all(ref int[] array) {
    foreach (ref x; array)
         x++;
}

void main() {
    auto a = new int[10];
    a.inc_all();
    writeln(a);
}


It prints 1 1 1 1 1 1 1 1 1 1

Bye,
bearophile
May 22 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/22/2010 01:00 PM, bearophile wrote:

 Pelle:

 Wouldn't gain anything from ref, and wouldn't work with const.



 You are wrong, it works correctly with ref:



Yes, it works, but it doesn't gain anything from it, which is what I 
said. :)
May 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Pelle:

 Yes, it works, but it doesn't gain anything from it, which is what I 
 said. :)



Then what you have said was useless.

Bye,
bearophile
May 22 2010
next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 05/22/2010 01:28 PM, bearophile wrote:

 Pelle:

 Yes, it works, but it doesn't gain anything from it, which is what I
 said. :)



 Then what you have said was useless.

 Bye,
 bearophile



How so? Passing by reference is slower, and sometimes completely 
meaningless. Therefore, having a rule that requires passing by ref is 
not a good.

Also:

int[] get_xs() { return new int[](100); }

void main() {
     get_xs.inc_all;

     get_xs.inc_all_by_ref; // Error: get_xs() is not an lvalue
}
May 22 2010
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 05/22/2010 06:28 AM, bearophile wrote:

 Pelle:

 Yes, it works, but it doesn't gain anything from it, which is what I
 said. :)



 Then what you have said was useless.



No it isn't. The point Pelle was making is that there are three use 
cases for parameter passed arrays:

1. read-only (corresponds to const)
2. read/write + resizing/reallocation (corresponds to ref)
3. read/write, no resizing (corresponds to no modifier)

With (1) and (2), if I see those modifiers in the signature, I can 
deduce the use of the array.

With (3), I can't really tell from the signature if the programmer meant 
that use case or forgot something, but the case is valuable enough that 
it should be enforceable.

With associative arrays, case (3) is rare (is it even possible?) to the 
point that it can drop out of consideration.
May 22 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'll now slowly answer the great replies I got in this thread, in 
chronological order. Since I read them all before replying, I might 
sometimes refer to future posts. Hopefully that won't be too confusing.

Andrei
May 21 2010
parent reply BLS <windevguy hotmail.de> writes:
On 21/05/2010 19:15, Andrei Alexandrescu wrote:

 I'll now slowly answer the great replies I got in this thread, in
 chronological order. Since I read them all before replying, I might
 sometimes refer to future posts. Hopefully that won't be too confusing.

 Andrei



Following the dcollection thread, it seems that your argument is that 
Interfaces in a non hierarchical collection library are useless.
Or : Hierarchical collection libs are nonsense and ergo interfaces are 
obsolete.

ok Some collection types belong to the same family. So they should be 
loosely coupled. How to do that without having Interfaces ?
Next  f.i. forwardranges belongs to a certain family of collections. and 
Ranges are (or should be) Interfaces.
You see me very confused.

Bjoern
given
struct node
class col : IFWRange
node Node;
// No ?
May 21 2010
parent BCS <none anon.com> writes:
Hello BLS,



 ok Some collection types belong to the same family. So they should be
 loosely coupled. How to do that without having Interfaces ?



How about this: Make a flat family of collections. Name the methods so that 
across the lib, the same name does the same kind of thing and different names 
do different kinds of things. Then define a flat family of whatever interfaces 
are useful and have each class derive from all the interfaces they happen 
to implement (but don't go out of your way to make anything fit).

-- 
... <IXOYE><
May 21 2010
prev sibling parent reply superdan <super dan.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 superdan Wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 superdan Wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article

 Is there some other reason to use structs besides copy construction?
 -Steve



 memory management n shit. with a struct u can use refcounting n malloc n













 shit. still stays a reference type. nothing gets fucked up.






 freedom for memory allocation schemes.

 how do u set up yer custom allocator to free memory? u cant tell when its ok.
 copying refs iz under da radar. dats my point.







 den there's all that null ref shit. with a class u have

 void foo(container!shit poo)
 {
     poo.addElement(Shit(diarrhea));
 }

 dat works with struct but don't work with motherfucking classes. u need to













 void foo(container!shit poo)
 {
     if (!poo) poo = new container!shit; // fuck dat shit
     poo.addElement(Shit(diarrhea));
 }

 u feel me?






 wut? it don't work? whaddaya mean it dun work? is you crazy? what dun work?
maybe
 therez sum misundercommunication.



 {
    x[5] = 5;
 }
 void main()
 {
    int[int] x;
    foo(x);
    assert(x[5] == 5); // fails
 }
 -Steve



wrote a long post but it got lost. shit. bottom line dats a bug in dmd or
phobos.
May 21 2010
parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, May 21, 2010 at 10:50 AM, superdan <super dan.org> wrote:


 void foo(int[int] x)
 {
 =A0 =A0x[5] =3D 5;
 }
 void main()
 {
 =A0 =A0int[int] x;
 =A0 =A0foo(x);
 =A0 =A0assert(x[5] =3D=3D 5); // fails
 }
 -Steve



 wrote a long post but it got lost. shit. bottom line dats a bug in dmd or=




Unfortunately it works exactly as designed.

--bb
May 21 2010