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
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
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
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
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
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
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 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 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
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
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.
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
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
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
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
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
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/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 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/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 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
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.
Factory please. Static opCall has always been nothing but trouble
in my experience.
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 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
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
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
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
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.
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
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
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
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
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
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
Am 26.10.2011, 16:00 Uhr, schrieb Steven Schveighoffer
schvei...@yahoo.com:
On Mon, 24 Oct 2011 22:50:33 -0400, Marco Leise marco.le...@gmx.de
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
On Mon, 24 Oct 2011 22:50:33 -0400, Marco Leise marco.le...@gmx.de 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 timon.g...@gmx.ch
wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly
On Tue, 25 Oct 2011 01:00:51 -0400, Andrew Wiley
wiley.andre...@gmail.com wrote:
On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise marco.le...@gmx.de 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
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 wiley.andre...@gmail.com wrote:
On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise marco.le...@gmx.de wrote:
Am 14.09.2011, 18:57
Am 14.09.2011, 18:57 Uhr, schrieb Steven Schveighoffer
schvei...@yahoo.com:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr timon.g...@gmx.ch 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
On Mon, Oct 24, 2011 at 9:50 PM, Marco Leise marco.le...@gmx.de 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 timon.g...@gmx.ch wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as
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
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
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr timon.g...@gmx.ch 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
On Wednesday, September 14, 2011 09:57 Steven Schveighoffer wrote:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr timon.g...@gmx.ch 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
On Wed, 14 Sep 2011 13:12:30 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, September 14, 2011 09:57 Steven Schveighoffer wrote:
On Wed, 14 Sep 2011 12:50:25 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
On 09/14/2011 04:08 PM, Robert McGinley wrote:
Hey all,
Mostly as an
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 request
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
