On Wednesday, 21 December 2011 at 16:39:13 UTC, Andrei
Alexandrescu wrote:
(Please don't overquote. It took me a million years to scroll
all the way down on my phone. Thanks.)
This is an alluring proposition but it's a lot more difficult
than one might think. The problem is the entire contai
On Wednesday, 21 December 2011 at 07:30:45 UTC, Jonathan M Davis
wrote:
And if they're classes and not managed by the GC nor in a
struct which manages their lifetime, how are they going to be
freed? Does the user have to explicitly free them themselves?
How is that better than using a ref-count
On 12/21/11 1:07 AM, foobar wrote:
The containers should allow for (disregard the specifics of the syntax):
Container a = new(SharedMemAllocator) LinkedList();
Container b = new(MallocAllocator) LinkedList();
Container c = new(GC) LinkedList();
When adding an item to the above containers the re
On Wed, 21 Dec 2011 14:56:28 +0200, Froglegs wrote:
On Wednesday, 21 December 2011 at 12:50:44 UTC, so wrote:
On Wed, 21 Dec 2011 07:37:33 +0200, Andrei Alexandrescu
wrote:
a great mathematician
Name please?
I believe he is referring to
http://en.wikipedia.org/wiki/Alexander_Stepanov
On Wednesday, 21 December 2011 at 12:50:44 UTC, so wrote:
On Wed, 21 Dec 2011 07:37:33 +0200, Andrei Alexandrescu
wrote:
a great mathematician
Name please?
I believe he is referring to
http://en.wikipedia.org/wiki/Alexander_Stepanov
On Wed, 21 Dec 2011 07:37:33 +0200, Andrei Alexandrescu
wrote:
a great mathematician
Name please?
On 2011-12-21 08:53, Jonathan M Davis wrote:
On Wednesday, December 21, 2011 08:44:10 Jacob Carlborg wrote:
I thought that one of the problems with the GC and memory was that you
can't rely on when/if the destructors are called. With "dispose" it
would give the developer a reliable method to cle
On Wednesday, December 21, 2011 08:44:10 Jacob Carlborg wrote:
> I thought that one of the problems with the GC and memory was that you
> can't rely on when/if the destructors are called. With "dispose" it
> would give the developer a reliable method to cleanup resources,
> assuming "scope" or "del
On 2011-12-21 06:07, Jonathan M Davis wrote:
On Monday, December 19, 2011 08:54:00 Jacob Carlborg wrote:
The Tango runtime has added a new method in Object, "dispose". This
method is called when "scope" is used or "delete" is explicitly called.
I don't know if that would help.
That sounds a lo
On Wednesday, December 21, 2011 08:07:23 foobar wrote:
> I disagree with the above conclusion. you conflate two issues
> that are orthogonal:
> a. value vs. ref semantics which is already seemed to be decided
> in favor of the latter and hence classes. b. memory and lifetime
> management
>
> The c
On Wednesday, 21 December 2011 at 05:08:27 UTC, Jonathan M Davis
wrote:
On Monday, December 19, 2011 08:54:00 Jacob Carlborg wrote:
The Tango runtime has added a new method in Object, "dispose".
This
method is called when "scope" is used or "delete" is
explicitly called.
I don't know if that w
On Wednesday, 21 December 2011 at 04:45:48 UTC, Jonathan M Davis
wrote:
On Tuesday, December 20, 2011 22:15:43 Caligo wrote:
[snip]
2. Are the new containers going to be multi-threaded? i.e.,
will I be
able to insert elements into a container from multiple threads?
No. That would introduce
On 12/20/11 10:15 PM, Caligo wrote:
Two questions:
1. If you guys, the D experts, are having such a difficult time with
this, what happens to the rest of us when we need to implement data
structures that are not offered by Phobos?
Good containers are hard to define. It took the C++ community t
On Monday, December 19, 2011 08:54:00 Jacob Carlborg wrote:
> The Tango runtime has added a new method in Object, "dispose". This
> method is called when "scope" is used or "delete" is explicitly called.
> I don't know if that would help.
That sounds a lot like using clear, though clear doesn't fr
On Tuesday, December 20, 2011 22:15:43 Caligo wrote:
> On Sun, Dec 18, 2011 at 10:12 PM, Jonathan M Davis
wrote:
> > So, I'm beginning to think that we're going to have to go the struct
> > route.
> >
> > - Jonathan M Davis
>
> Two questions:
>
> 1. If you guys, the D experts, are having such a
On Sun, Dec 18, 2011 at 10:12 PM, Jonathan M Davis wrote:
> So, I'm beginning to think that we're going to have to go the struct route.
>
> - Jonathan M Davis
>
Two questions:
1. If you guys, the D experts, are having such a difficult time with this,
what happens to the rest of us when we need t
On Saturday, 17 December 2011 at 23:31:47 UTC, Andrei
Alexandrescu wrote:
On 12/13/11 9:08 PM, Jonathan M Davis wrote:
Is the plan for std.container still to have all of its
containers be final
classes (classes so that they're reference types and final so
that their
functions are inlinable)? Or
I don't really think ref counted struct vs class is fair,
because in reality most containers don't need ref counting. I
can't think of one instance in C++ where I stuck a container
directly in a shared_ptr or anything similar.
Also as far I as I can tell making it a class would bloat it wit
Jonathan M Davis writes:
> On Saturday, December 17, 2011 17:31:46 Andrei Alexandrescu wrote:
>> On 12/13/11 9:08 PM, Jonathan M Davis wrote:
>> > Is the plan for std.container still to have all of its containers be
>> > final classes (classes so that they're reference types and final so
>> > tha
On Sun, 18 Dec 2011 01:15:40 -0500, Andrei Alexandrescu
wrote:
On 12/17/11 7:52 PM, Jonathan M Davis wrote:
The only reason that I can think of to use a reference-counted struct
instead
of a class is becuse then it's easier to avoid the GC heap entirely.
Almost
all of a container's memor
On 2011-12-19 05:12, Jonathan M Davis wrote:
On Sunday, December 18, 2011 02:46:01 Andrei Alexandrescu wrote:
If this is a new notion, it might take a while for all of its aspects to
sink in. I'm not saying that to be smug - reference counting vs. other
methods of collecting garbage is definitel
On Sunday, December 18, 2011 02:46:01 Andrei Alexandrescu wrote:
> If this is a new notion, it might take a while for all of its aspects to
> sink in. I'm not saying that to be smug - reference counting vs. other
> methods of collecting garbage is definitely a difficult topic on today's
> architect
On 12/18/11 1:42 AM, Jonathan M Davis wrote:
On Sunday, December 18, 2011 00:15:40 Andrei Alexandrescu wrote:
On 12/17/11 7:52 PM, Jonathan M Davis wrote:
The only reason that I can think of to use a reference-counted struct
instead of a class is becuse then it's easier to avoid the GC heap
ent
On Sunday, December 18, 2011 00:15:40 Andrei Alexandrescu wrote:
> On 12/17/11 7:52 PM, Jonathan M Davis wrote:
> > The only reason that I can think of to use a reference-counted struct
> > instead of a class is becuse then it's easier to avoid the GC heap
> > entirely. Almost all of a container's
On 12/17/11 7:52 PM, Jonathan M Davis wrote:
The only reason that I can think of to use a reference-counted struct instead
of a class is becuse then it's easier to avoid the GC heap entirely. Almost
all of a container's memory is going to end up on the heap regardless, because
the elements almos
On Saturday, December 17, 2011 22:57:46 Caligo wrote:
> On Tue, Dec 13, 2011 at 9:08 PM, Jonathan M Davis
wrote:
> > Is the plan for std.container still to have all of its containers be
> > final classes (classes so that they're reference types and final so
> > that their functions are inlinable)?
On Tue, Dec 13, 2011 at 9:08 PM, Jonathan M Davis wrote:
> Is the plan for std.container still to have all of its containers be final
> classes (classes so that they're reference types and final so that their
> functions are inlinable)? Or has that changed? I believe that Andrei said
> something r
On Saturday, December 17, 2011 17:31:46 Andrei Alexandrescu wrote:
> On 12/13/11 9:08 PM, Jonathan M Davis wrote:
> > Is the plan for std.container still to have all of its containers be
> > final classes (classes so that they're reference types and final so
> > that their functions are inlinable)?
On Saturday, 17 December 2011 at 23:31:47 UTC, Andrei
Alexandrescu wrote:
Safety is also an issue. I was hoping I'd provide safety as a
policy, e.g. one may choose for a given container whether they
want safe or not (and presumably fast). I think it's best to
postpone that policy and focus for
On 17/12/11 11:31 PM, Andrei Alexandrescu wrote:
The most important thing I noticed is that people expect standard
containers to have sophisticated memory management. Many ask not about
containers as much as "containers with custom allocators". Second,
containers tend to be large memory users by
On 18/12/11 12:06 AM, Jesse Phillips wrote:
But as to whether this should be what is implemented in the standard
library, I don't know. You make mention of custom allocators and such. Is
this interest going to be of benefit, or is it just something people are
use to having from C++? If it makes s
On Sat, 17 Dec 2011 17:31:46 -0600, Andrei Alexandrescu wrote:
> The second decision is classes vs. structs. Walter correctly pointed out
> that the obvious choice for defining a reference type in D - whether the
> type is momonorphic or polymorphic - is making it a class. If containers
> aren't c
On 12/13/11 9:08 PM, Jonathan M Davis wrote:
Is the plan for std.container still to have all of its containers be final
classes (classes so that they're reference types and final so that their
functions are inlinable)? Or has that changed? I believe that Andrei said
something recently about discu
Is the plan for std.container still to have all of its containers be final
classes (classes so that they're reference types and final so that their
functions are inlinable)? Or has that changed? I believe that Andrei said
something recently about discussing reference counting and containers with
34 matches
Mail list logo
