There's this oddity of built-in hash tables: a reference to a non-empty
hash table can be copied and then both references refer to the same hash
table object. However, if the hash table is null, copying the reference
won't track the same object later on.
Fast-forward to general collections. If
Hey all,
Mostly as an exercise I'm considering writing an ArrayList, AVL tree, and
possible other standard data structures in D. I have two questions.
1.) If completed should I send these around for review and inclusion or do they
not belong in phobos?
2.) If I'm working on including these in ph
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
1. Factory function:
This is my preference for zero arg at least because the opCall
thing is commonly misunderstood and confused with C++ default
construction and we don't need to encourage that.
static MyCollectio
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:25:12 UTC, Adam D. Ruppe wrote:
That syntax is the same as constructors... if that's what you
want it to look like, we ought to actually use a constructor
for all but the zero-argument ones which I'd use a static named
function for (perhaps .make or perhaps .ma
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's some experience in various libraries with both
approaches. Which would you prefer?
Well, I think we should recognize that they're the same thing but
with different names. I don't have a strong preference for
eithe
On Saturday, 28 November 2015 at 06:59:35 UTC, bitwise wrote:
Classes/real-ref-types dont act as you're describing
They do, actually.
class Collection(E) { ... }
Collection!E a; // null reference
auto b = new Collection!E(); // reference to empty collection
The only outlier is the associativ
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's some experience in various libraries with both
approaches. Which would you prefer?
Another thing: wouldn't providing a custom allocator require a
separate primitive? I am assuming that the allocator type won't
be
Factory please. Static opCall has always been nothing but trouble
in my experience.
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On 11/27/2015 09:14 PM, Andrei Alexandrescu wrote:
There's this oddity of built-in hash tables: a reference to a non-empty
hash table can be copied and then both references refer to the same hash
table object. However, if the hash table is null, copying the reference
won't track the same object l
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
1. Factory function:
2. The opCall trick:
1. Factory
Shouldn't opCall be used when you want something to (only) behave
as a function? E.g. functors.
On 11/28/15 1:59 AM, bitwise wrote:
Classes/real-ref-types dont act as you're describing, so why should
these fake struct wrapper ref things act this way? This will likely
achieve the exact opposite of what you're aiming for, by making
something that's supposed to act like a reference type have
On 11/28/15 2:26 AM, Jakob Ovrum wrote:
Another thing: wouldn't providing a custom allocator require a separate
primitive?
All collections will work with IAllocator. -- Andrei
On Saturday, 28 November 2015 at 06:26:03 UTC, Jakob Ovrum wrote:
On Friday, 27 November 2015 at 20:25:12 UTC, Adam D. Ruppe
wrote:
That syntax is the same as constructors... if that's what you
want it to look like, we ought to actually use a constructor
for all but the zero-argument ones which
On Saturday, 28 November 2015 at 18:38:37 UTC, Kagamin wrote:
Well... doesn't work: http://dpaste.dzfl.pl/2c69cc3584b8
I don't understand... of course you can't call what is returned
by makeEmpty.
On Saturday, 28 November 2015 at 18:43:33 UTC, Adam D. Ruppe
wrote:
On Saturday, 28 November 2015 at 18:38:37 UTC, Kagamin wrote:
Well... doesn't work: http://dpaste.dzfl.pl/2c69cc3584b8
I don't understand... of course you can't call what is returned
by makeEmpty.
Recently someone complaine
On Saturday, 28 November 2015 at 12:20:36 UTC, Timon Gehr wrote:
3. (Non-internal) factory function:
auto c1 = myCollection(1,2,3);
auto c2 = myCollection!int();
auto c3 = c2; // refers to the same collection as c2
Yeah. In general, I prefer that approach. It's what we currently
do with RedBl
On Saturday, 28 November 2015 at 13:41:10 UTC, Andrei
Alexandrescu wrote:
On 11/28/15 2:26 AM, Jakob Ovrum wrote:
Another thing: wouldn't providing a custom allocator require a
separate
primitive?
All collections will work with IAllocator. -- Andrei
Yes, I assumed as much. So how would this
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On 11/29/15 5:06 AM, Atila Neves wrote:
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references refer to
the same hash table object. However, if the hash tabl
On Sunday, 29 November 2015 at 15:06:49 UTC, Andrei Alexandrescu
wrote:
Thanks all. I'll go with the factory function. -- Andrei
As Timon suggested, I'd encourage you to go for a free factory
function named after the container like RedBlackTree does with
redBlackTree rather than having a stat
On 11/27/15 3:14 PM, Andrei Alexandrescu wrote:
There's this oddity of built-in hash tables: a reference to a non-empty
hash table can be copied and then both references refer to the same hash
table object. However, if the hash table is null, copying the reference
won't track the same object late
On Monday, 30 November 2015 at 16:06:43 UTC, Steven Schveighoffer
wrote:
MyCollection!(int) c1;
auto c2 = c1;
c1 ~= 1;
assert(c2.contains(1)); // pass? fail?
BTW, I third Jonathan's and Timon's suggestion -- go with an
external factory function. Use IFTI to its fullest!
-Steve
That should
On 11/30/15 11:21 AM, Tobias Pankrath wrote:
On Monday, 30 November 2015 at 16:06:43 UTC, Steven Schveighoffer wrote:
MyCollection!(int) c1;
auto c2 = c1;
c1 ~= 1;
assert(c2.contains(1)); // pass? fail?
BTW, I third Jonathan's and Timon's suggestion -- go with an external
factory function. Use
On Saturday, 28 November 2015 at 13:39:35 UTC, Andrei
Alexandrescu wrote:
On 11/28/15 1:59 AM, bitwise wrote:
Classes/real-ref-types dont act as you're describing, so why
should
these fake struct wrapper ref things act this way? This will
likely
achieve the exact opposite of what you're aimi
On 11/30/2015 12:56 PM, bitwise wrote:
On Saturday, 28 November 2015 at 13:39:35 UTC, Andrei Alexandrescu wrote:
On 11/28/15 1:59 AM, bitwise wrote:
Classes/real-ref-types dont act as you're describing, so why should
these fake struct wrapper ref things act this way? This will likely
achieve t
On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu
wrote:
* The one matter with the value/RefCounted approach is that
RefCounted cannot be made @safe.
That's just as true for internal refcounting.
On 12/1/15 4:55 AM, Marc Schütz wrote:
On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote:
* The one matter with the value/RefCounted approach is that RefCounted
cannot be made @safe.
That's just as true for internal refcounting.
I don't think that's the case. The way I w
On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu
wrote:
On 12/1/15 4:55 AM, Marc Schütz wrote:
On Monday, 30 November 2015 at 18:18:38 UTC, Andrei
Alexandrescu wrote:
* The one matter with the value/RefCounted approach is that
RefCounted
cannot be made @safe.
That's just as t
On 12/01/2015 09:35 AM, Marc Schütz wrote:
On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu wrote:
On 12/1/15 4:55 AM, Marc Schütz wrote:
On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote:
* The one matter with the value/RefCounted approach is that RefCount
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu
wrote:
Ah, the good old assignment to reference. We need to prevent
that from happening in safe code. Got any fresh ideas? -- Andrei
Disable owner when borrowing 'mutably', and not when borrowing
'constly'.
On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote:
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei
Alexandrescu wrote:
Ah, the good old assignment to reference. We need to prevent
that from happening in safe code. Got any fresh ideas? --
Andrei
Disable owner when borrowing 'm
On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote:
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei
Alexandrescu wrote:
Ah, the good old assignment to reference. We need to prevent
that from happening in safe code. Got any fresh ideas? --
Andrei
Disable owner when borrowing 'm
On 12/02/2015 01:45 AM, deadalnix wrote:
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
Ah, the good old assignment to reference. We need to prevent that from
happening in safe code. Got any fresh ideas? -- Andrei
Disable owner when borrowing 'mutably', and not when bo
On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei
Alexandrescu wrote:
On 12/02/2015 01:45 AM, deadalnix wrote:
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei
Alexandrescu wrote:
Ah, the good old assignment to reference. We need to prevent
that from
happening in safe code. Got any fres
On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei
Alexandrescu wrote:
On 12/02/2015 01:45 AM, deadalnix wrote:
On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei
Alexandrescu wrote:
Ah, the good old assignment to reference. We need to prevent
that from
happening in safe code. Got any fres
Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer
:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as an exercise I'm considering writing an ArrayList, AVL tree,
and possible other standard data structures in D.
On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise wrote:
> Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer <
> schvei...@yahoo.com>:
>
>
> On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr wrote:
>>
>> On 09/14/2011 04:08 PM, Robert McGinley wrote:
>>>
Hey all,
Mostly as an exercise I
I really REALLY miss a doubly-linked list. That's all i can think of
right now, which is missing from D's containers :-)
On Tue, Oct 25, 2011 at 9:00 AM, Andrew Wiley wrote:
>
>
> On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise wrote:
>>
>> Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer
>>
On Mon, 24 Oct 2011 22:50:33 -0400, Marco Leise wrote:
Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer
:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr
wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as an exercise I'm considering writing an ArrayList, AVL
On Tue, 25 Oct 2011 01:00:51 -0400, Andrew Wiley
wrote:
On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise wrote:
Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer <
schvei...@yahoo.com>:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr
wrote:
On 09/14/2011 04:08 PM, Robert McGinley
You could use a tree for that, but my understanding is that a heap is
much
more efficient?
Yes. I have a feeling dcollections will use heap from phobos (to avoid
duplication) for a full priority queue.
-Steve
I tried a Fibonacci tree. It didn't beat the good old array based priority
q
Am 26.10.2011, 16:00 Uhr, schrieb Steven Schveighoffer
:
On Mon, 24 Oct 2011 22:50:33 -0400, Marco Leise
wrote:
Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer
:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr
wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
On Wednesday, September 14, 2011 10:08:28 Robert McGinley wrote:
> Hey all,
> Mostly as an exercise I'm considering writing an ArrayList, AVL tree, and
> possible other standard data structures in D. I have two questions. 1.) If
> completed should I send these around for review and inclusion or do
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as an exercise I'm considering writing an ArrayList, AVL tree, and
possible other standard data structures in D. I have two questions.
1.) If completed should I send these around for review and inclusion or do they
not belong in ph
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as an exercise I'm considering writing an ArrayList, AVL tree,
and possible other standard data structures in D. I have two questions.
1.) If completed should I send these ar
On Wednesday, September 14, 2011 09:57 Steven Schveighoffer wrote:
> On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr wrote:
> > On 09/14/2011 04:08 PM, Robert McGinley wrote:
> >> Hey all,
> >> Mostly as an exercise I'm considering writing an ArrayList, AVL tree,
> >> and possible other standard da
On Wed, 14 Sep 2011 13:12:30 -0400, Jonathan M Davis
wrote:
On Wednesday, September 14, 2011 09:57 Steven Schveighoffer wrote:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr
wrote:
> On 09/14/2011 04:08 PM, Robert McGinley wrote:
>> Hey all,
>> Mostly as an exercise I'm considering writin
On Wednesday, September 14, 2011 10:23 Steven Schveighoffer wrote:
> Regardless, the best way to get your code reviewed is by creating a github
> fork. At least then it's easy to try out.
Indeed. Such a fork is pretty much necessary to get the code into Phobos
anyway.
> IMO, I think a pull reque
Thanks everybody. I'll have to plan things out more (my time wise more then
anything) and I'll check with the NG before I move on anything.
Rob
On Sep 14, 2011, at 1:55 PM, Jonathan M Davis wrote:
> On Wednesday, September 14, 2011 10:23 Steven Schveighoffer wrote:
>> Regardless, the best way to
54 matches
Mail list logo