View mode: basic / threaded / horizontal-split · Log in · Help
May 21, 2010
Re: dcollections 1.0 and 2.0a beta released
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.
> > This is not necessary with purely memory-based constructs -- the GC is your
> friend.  The custom allocator ability in dcollections should provide plenty of
> 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?
> > It doesn't work.
> 
> 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
Re: dcollections 1.0 and 2.0a beta released
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
<schveiguy@yahoo.com> wrote:
> 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.
>> > This is not necessary with purely memory-based constructs -- the GC is your
>> friend.  The custom allocator ability in dcollections should provide plenty of
>> 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?
>> > It doesn't work.
>>
>> 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
> }

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 ~= 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
Re: dcollections 1.0 and 2.0a beta released
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
Re: dcollections 1.0 and 2.0a beta released
== 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
realloc n
> > > > shit. still stays a reference type. nothing gets fucked up.
> > > This is not necessary with purely memory-based constructs -- the GC is your
> > friend.  The custom allocator ability in dcollections should provide plenty of
> > 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?
> > > It doesn't work.
> >
> > 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

wrote a long post but it got lost. shit. bottom line dats a bug in dmd or phobos.
May 21, 2010
Re: dcollections 1.0 and 2.0a beta released
On Fri, May 21, 2010 at 10:50 AM, superdan <super@dan.org> wrote:

>> void foo(int[int] x)
>> {
>>    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.

Unfortunately it works exactly as designed.

--bb
May 22, 2010
Re: dcollections 1.0 and 2.0a beta released
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 22, 2010
Re: dcollections 1.0 and 2.0a beta released
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
>> }
> 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 ~= 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 22, 2010
Re: dcollections 1.0 and 2.0a beta released
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 22, 2010
Re: dcollections 1.0 and 2.0a beta released
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
Re: dcollections 1.0 and 2.0a beta released
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home