Andrei Alexandrescu, el 3 de mayo a las 11:55 me escribiste:
If the array is a reference type, the array dies when the garbage
collector decides to run sometime after all live references to the array
have died, so RAII is not possible.
RAII can be implemented even with reference semantics.
Rainer Deyke wrote:
Robert Jacques wrote:
RAII is all about stack allocation over heap allocation (or so I
thought). Ah, wikipedia has set me straight. Anyways, now for the simple
answer: you can't create D1 arrays with RAII types, I think. (Anyone
tried scope Foo[] foo?) Anyways, in D2, if I
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
If the array is a reference type, the array dies when the garbage
collector decides to run sometime after all live references to the array
have died, so RAII is not possible.
RAII can be implemented even with reference semantics. The mechanics
On Fri, 01 May 2009 19:23:45 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Rainer Deyke wrote:
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
Speaking of which, I'm
Robert Jacques wrote:
On Fri, 01 May 2009 15:37:56 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
No they don't. To be clear, I'm talking about
On Fri, 01 May 2009 19:25:35 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Do you have a link to your article?
http://tinyurl.com/dac82a
Andrei
Should've seen that one coming. :)
Anyways, I'm not sure how you can call the technique lock-free,
Robert Jacques wrote:
On Fri, 01 May 2009 19:25:35 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Do you have a link to your article?
http://tinyurl.com/dac82a
Andrei
Should've seen that one coming. :)
Anyways, I'm not sure how you can call the
Benji Smith wrote:
Andrei Alexandrescu wrote:
Also something that wasn't discussed that much is the connection of
whatever design we devise, with the GC. I am mightily excited by the
possibility to operate without GC or with tight reference counting,
and I thought many around here would share
On Sat, 02 May 2009 02:34:57 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Fri, 01 May 2009 19:25:35 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Do you have a link to your article?
On Fri, 01 May 2009 21:14:54 -0400, Bill Baxter wbax...@gmail.com wrote:
On Fri, May 1, 2009 at 5:36 PM, bearophile bearophileh...@lycos.com
wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are slow in Python
Robert Jacques wrote:
No, repeated allocations are trivial to eliminate. I didn't even
bother to explain that in the article. The loop must only refill the
allocated object from the object that needs to be replaced.
putting the test in the pseudo code for this would've help my
understanding.
Robert Jacques wrote:
On Fri, 01 May 2009 15:37:56 -0400, Rainer Deyke rain...@eldwood.com
wrote:
All containers need to support copying.
No they don't.
There is no conceptual problem with a non-copyable struct. However, in
order to be a considered a container, the struct must at least
On Sat, 02 May 2009 03:35:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
No, repeated allocations are trivial to eliminate. I didn't even
bother to explain that in the article. The loop must only refill the
allocated object from the object that
Bill Baxter wrote:
On Fri, May 1, 2009 at 5:36 PM, bearophile bearophileh...@lycos.com wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are slow in Python so
you have to come up with clever transformations to
On Sat, 02 May 2009 03:39:27 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Fri, 01 May 2009 15:37:56 -0400, Rainer Deyke rain...@eldwood.com
wrote:
All containers need to support copying.
No they don't.
There is no conceptual problem with a non-copyable struct.
On 2009-05-01 13:44:58 -0400, Robert Jacques sandf...@jhu.edu said:
I think you might of misunderstood the concept of a unique/mobile type.
If you take a slice or a reference of an unique, you null the source.
Which makes using unique T logically invalid as a container.
Take note: I'm not
On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I guess at that point the would-be D user would be entitled to make me a
lavaliere out of my
Robert Jacques wrote:
On Sat, 02 May 2009 03:35:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
No, repeated allocations are trivial to eliminate. I didn't even
bother to explain that in the article. The loop must only refill the
allocated object
On Sat, 02 May 2009 18:08:30 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Sat, 02 May 2009 03:35:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
No, repeated allocations are trivial to eliminate. I
Bill Baxter wrote:
On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I guess at that point the would-be D user would be entitled to
make me a
Denis Koroskin wrote:
You can reuse memory even if it comprehends more complex patterns
than one single allocation.
Andrei
I *highly* doubt it is worth the trouble. Most likely, this container
won't be lock-free and scalable anymore. Performance will also
degrade dramatically.
How did you
On Sat, 02 May 2009 18:17:16 +0400, Denis Koroskin 2kor...@gmail.com wrote:
On Sat, 02 May 2009 18:08:30 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Sat, 02 May 2009 03:35:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
I do scientific computing. Generally, I find it breaks down into two
parts: things under 4x4, for which value types are probably better, and
everything else, for which value types are to be avoided like the
plague. I'll often work with 100's mb of data with algorithms
On 2009-05-02 10:18:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Yes, when you have an a=b anywhere you've got to pay attention and
make sure you didn't mean a=b.dup.
That is terrible. Anywhere == a portion of the code far, far away.
It's funny that you mention ==,
Bill Baxter:
Strange though, aren't you the guy always telling us how being able to express
your algorithm clearly is often more important than raw performance?
Nope. I have said many things :-) One of the things I have said is that most of
the code of most programs isn't performance-critical,
On Sat, 02 May 2009 06:23:46 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2009-05-01 13:44:58 -0400, Robert Jacques sandf...@jhu.edu said:
I think you might of misunderstood the concept of a unique/mobile type.
If you take a slice or a reference of an unique, you null the
On Sat, 02 May 2009 04:17:29 -0400, Don nos...@nospam.com wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 5:36 PM, bearophile bearophileh...@lycos.com
wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are
About the issue of matrices as reference or value semantics.
As a program I think references are more efficient, they are used everywhere in
many languages like Python/Numpy, Sage, Ruby, etc, and I don't like the idea of
putting ref everywhere. So I like references more. Also all objects in D
Andrei Alexandrescu:
Consider the progress we made when replacing char[]
with string. Why? Because with char[] long-distance dependencies crop up
easy and fast.
For big arrays people will put ref everywhere, so those bugs will not
decrease.
Bye,
bearophile
On Sat, 02 May 2009 10:58:08 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
I do scientific computing. Generally, I find it breaks down into two
parts: things under 4x4, for which value types are probably better, and
everything else, for which value
On Sat, 02 May 2009 10:18:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu
Matrix a, b, c; ... c = a; a += b;
Does the last operation mutate c as well?
I said assignments like a = b are rare and you
On Sat, 02 May 2009 10:23:13 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Denis Koroskin wrote:
You can reuse memory even if it comprehends more complex patterns
than one single allocation.
Andrei
I *highly* doubt it is worth the trouble. Most likely, this container
Don wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 5:36 PM, bearophile bearophileh...@lycos.com
wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are slow in Python so
you have to come up with clever
Robert Jacques wrote:
On Sat, 02 May 2009 03:39:27 -0400, Rainer Deyke rain...@eldwood.com
wrote:
You can have non-copyable value types, but they can't be containers.
No they don't. Iteration can often be destructive. If I iterate over a
stack or a queue, I'm left with an empty stack/queue.
Georg Wrede:
The more I think about it, the more I'm starting to believe that the
average desktop or laptop won't see two dozen cores in the immediate
future.
Too much late. My personal computer has already about 100 small cores in the
GPU, and using CUDA (and soon OpenCL) you are even able
On Sat, 02 May 2009 15:17:04 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Sat, 02 May 2009 03:39:27 -0400, Rainer Deyke rain...@eldwood.com
wrote:
You can have non-copyable value types, but they can't be containers.
No they don't. Iteration can often be
Robert Jacques wrote:
On Sat, 02 May 2009 10:18:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu
Matrix a, b, c; ... c = a; a += b;
Does the last operation mutate c as well?
I said assignments like a =
Robert Jacques wrote:
Also, in a value semantics world, refs are third class citizens, but in
a reference semantic world, value semantics get their own assignment
operator ( []= ), and by convention, their own property ( .dup )
The major problem is not assignment. That can be taken care of.
bearophile wrote:
Georg Wrede:
The more I think about it, the more I'm starting to believe that the
average desktop or laptop won't see two dozen cores in the immediate
future.
Too much late. My personal computer has already about 100 small cores in the
GPU, and using CUDA (and soon OpenCL)
On Sat, 02 May 2009 17:59:53 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Also, in a value semantics world, refs are third class citizens, but in
a reference semantic world, value semantics get their own assignment
operator ( []= ), and by
On Sat, 02 May 2009 17:45:16 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Sat, 02 May 2009 10:18:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu
Matrix
Robert Jacques wrote:
Although, I'm starting to see an interesting story: Here are containers.
They have value semantics and are simple to use/prototype with. When
you're done, you can move to ranges in the performance critical sections
in order to boost performance. And some things, like high
On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
Again, D array's are structs with reference semantics. This isn't a
pro/con either way.
The D1 dynamic array type does not have reference semantics, nor does it
have value semantics.
void
Robert Jacques wrote:
On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Given a value type 'T', you have the guarantee that no two variables of
type 'T' can alias each other. This guarantee is preserved when the
type 'T' is non-copyable.
An argument of type 'ref
On Sat, 02 May 2009 22:14:59 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Given a value type 'T', you have the guarantee that no two variables of
type 'T' can alias each other. This
Robert Jacques wrote:
RAII is all about stack allocation over heap allocation (or so I
thought). Ah, wikipedia has set me straight. Anyways, now for the simple
answer: you can't create D1 arrays with RAII types, I think. (Anyone
tried scope Foo[] foo?) Anyways, in D2, if I remember correctly
On 2009-04-30 15:57:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
As predicted by the range theory which predicates that a range will
never grow, only shrink, slices should always shrink. Growing is a
foreign operation for a slice. This is a big problem that goes beyond a
On 2009-04-30 20:52:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
(Last but not least, .NET has arrays and slices. D's slices that
actually have an array testis mesh real bad with .NET because in .NET
you can't have a disowned slice.)
I've been following the blog. I was
On Fri, 01 May 2009 06:26:19 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2009-04-30 15:57:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
As predicted by the range theory which predicates that a range will
never grow, only shrink, slices should always
On Fri, 01 May 2009 06:45:20 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2009-04-30 20:52:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
(Last but not least, .NET has arrays and slices. D's slices that
actually have an array testis mesh real bad with .NET
Robert Jacques wrote:
On Thu, 30 Apr 2009 23:18:13 -0400, Rainer Deyke rain...@eldwood.com
wrote:
- It uses an extra heap allocation per instance.
And during a deep copy, you're often making a lot of heap copies. (N vs
N+1 when N1)
In the case of dynamic arrays, N = 1 (or possibly 0 if
Robert Jacques wrote:
Lastly, what you're trying to fix is a bug in the implementation of
arrays (see my posts in this thread) and not a bug in the design.
I think your fix to the array-slice conflation is simply to make slices
arrays by adding extra information. This approach is reasonable,
On Fri, 01 May 2009 14:00:35 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Lastly, what you're trying to fix is a bug in the implementation of
arrays (see my posts in this thread) and not a bug in the design.
I think your fix to the array-slice
On Fri, 01 May 2009 14:03:44 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Thu, 30 Apr 2009 23:18:13 -0400, Rainer Deyke rain...@eldwood.com
wrote:
- It uses an extra heap allocation per instance.
And during a deep copy, you're often making a lot of heap
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
--
Rainer Deyke - rain...@eldwood.com
Robert Jacques wrote:
On Fri, 01 May 2009 15:07:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Yes. See java.util.concurrent for examples. In fact, all of the
algorithms I've read explicitly don't support copying, which is why
I'm asking.
Why would
On Fri, 01 May 2009 15:07:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Yes. See java.util.concurrent for examples. In fact, all of the
algorithms I've read explicitly don't support copying, which is why I'm
asking.
Why would the
issues
On Fri, 01 May 2009 18:09:09 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Fri, 01 May 2009 15:07:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Yes. See java.util.concurrent for examples. In fact, all of
Rainer Deyke wrote:
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
Speaking of which, I'm thinking of a field like scientific computing
(even of the simplest, most basic kind that we all
Robert Jacques wrote:
Do you have a link to
your article?
http://tinyurl.com/dac82a
Andrei
On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Rainer Deyke wrote:
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
Speaking of which, I'm thinking of
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are slow in Python so
you have to come up with clever transformations to turn your loop into
array ops. This is thankfully a problem that D array libs do not
have. If
On Fri, May 1, 2009 at 5:36 PM, bearophile bearophileh...@lycos.com wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
how do I make this loop faster becuase loops are slow in Python so
you have to come up with clever transformations to turn your loop into
Bill Baxter wrote:
On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I guess at that point the would-be D user would be entitled to make me a
lavaliere out of my Matrix library and move on.
Python, and therefore NumPy, are reference based.
In a
Andrei Alexandrescu wrote:
Also something that wasn't discussed that much is the connection of
whatever design we devise, with the GC. I am mightily excited by the
possibility to operate without GC or with tight reference counting, and
I thought many around here would share that excitement. If
On Fri, 01 May 2009 15:37:56 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
Precisely, so it's always passed by reference and doesn't need to
support copying.
All containers need to support copying.
No they don't. To be clear, I'm talking about copying the container,
Andrei Alexandrescu wrote:
Jason House wrote:
I'm a C++ refugee and value semantics make no sense to me. I always
declared classes (as part of function declaration) in C++ with a ...
Either T or const T. There were plenty of bugs where I messed up
and forgot the . D is nice in that it tries to
On 2009-04-29 23:01:39 -0400, Rainer Deyke rain...@eldwood.com said:
Andrei Alexandrescu wrote:
2. Value semantics with reference counting
I like this optimization and use it all the time in my own code, but I'm
not convinced that it should be the default. It's also problematic in
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
1. Value semantics (arrays are like int)
Don't forget:
+ Supports timely destruction of contents (i.e. RAII).
These are collections. RAII doesn't matter when you have a garbage
collector and the only resource you have is memory, unless you're
On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It has become increasingly clear we'll need to support arrays in
addition to slices.
No, Andrei it hasn't. A detailed paragraph (or more) explaining we you
think so should be included in the full
Michel Fortin wrote:
On 2009-04-29 23:01:39 -0400, Rainer Deyke rain...@eldwood.com said:
Andrei Alexandrescu wrote:
3. Reference semantics
I'm strongly opposed to this option. Either of the other options would
be acceptable.
Andrei mentioned a couple of reasons against 3, which are
Christopher Wright wrote:
Rainer Deyke wrote:
Don't forget:
+ Supports timely destruction of contents (i.e. RAII).
These are collections. RAII doesn't matter when you have a garbage
collector and the only resource you have is memory, unless you're quite
strapped for memory.
It also
Robert Jacques wrote:
On Thu, 30 Apr 2009 14:40:42 -0400, Rainer Deyke rain...@eldwood.com
wrote:
In addition, there's this: suppose you have a struct containing a
(mutable) array. When you make a copy of that struct, you will almost
always want to make a copy of the contained array.
Robert Jacques wrote:
On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It has become increasingly clear we'll need to support arrays in
addition to slices.
No, Andrei it hasn't. A detailed paragraph (or more) explaining we you
think so should be
On Thu, 30 Apr 2009 23:57:17 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It has become increasingly clear we'll need to support arrays in
addition to
Robert Jacques wrote:
On Thu, 30 Apr 2009 14:40:42 -0400, Rainer Deyke rain...@eldwood.com
wrote:
In addition, there's this: suppose you have a struct containing a
(mutable) array. When you make a copy of that struct, you will almost
always want to make a copy of the contained array.
On Thu, 30 Apr 2009 15:21:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Thu, 30 Apr 2009 14:40:42 -0400, Rainer Deyke rain...@eldwood.com
wrote:
In addition, there's this: suppose you have a struct containing a
(mutable) array. When you make a
On Thu, 30 Apr 2009 17:23:19 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Thu, 30 Apr 2009 14:40:42 -0400, Rainer Deyke rain...@eldwood.com
wrote:
In addition, there's this: suppose you have a struct containing a
(mutable) array. When you make a copy of that
Robert Jacques wrote:
Now, back on topic. I actually make heavy use of what amounts to structs
containing arrays and don't want a deep copy 90% of the time. In fact,
I haven't used any of the (my array-my array) deep copy functions and I
only do copying when I have to convert my arrays to D
Andrei Alexandrescu wrote:
A design that has one container type and several slice types that crawl
it in various ways is very compelling, and I think it will be a huge
selling point for D. It would be odd, not natural, to have arrays as a
singularly distinct container that is in fact its own
Rainer Deyke Wrote:
Michel Fortin wrote:
On 2009-04-29 23:01:39 -0400, Rainer Deyke rain...@eldwood.com said:
Andrei Alexandrescu wrote:
3. Reference semantics
I'm strongly opposed to this option. Either of the other options would
be acceptable.
Andrei mentioned a couple of
On Thu, 30 Apr 2009 15:57:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Wed, 29 Apr 2009 20:45:23 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
It has become increasingly clear we'll need to support arrays in
addition to
Joel C. Salomon wrote:
Andrei Alexandrescu wrote:
A design that has one container type and several slice types that crawl
it in various ways is very compelling, and I think it will be a huge
selling point for D. It would be odd, not natural, to have arrays as a
singularly distinct container
Robert Jacques wrote:
On Thu, 30 Apr 2009 15:57:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
People have complained about the incredibly bad, unsafe, and slow
behavior of appending. Even before the considerable recent slowdown of
~=, there were speed concerns. Worse than
Andrei Alexandrescu:
Does any of this make sense? :o)
Yes. I think problems aren't finished yet and more thinking is expected, but
you are getting somewhere (I can tell it also because I am starting to
understand. I am not bright. When even I understand it often means that the
design is
bearophile wrote:
Andrei Alexandrescu:
Does any of this make sense? :o)
Yes. I think problems aren't finished yet and more thinking is
expected, but you are getting somewhere (I can tell it also because I
am starting to understand. I am not bright.
Bright is only one :o).
When even I
On Thu, 30 Apr 2009 20:52:05 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Thu, 30 Apr 2009 15:57:17 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
People have complained about the incredibly bad, unsafe, and slow
behavior of
Andrei, how do you do shared, lock-free containers as value types?
Rainer Deyke wrote:
Christopher Wright wrote:
Rainer Deyke wrote:
Don't forget:
+ Supports timely destruction of contents (i.e. RAII).
These are collections. RAII doesn't matter when you have a garbage
collector and the only resource you have is memory, unless you're quite
strapped for
Robert Jacques wrote:
On Thu, 30 Apr 2009 17:23:19 -0400, Rainer Deyke rain...@eldwood.com
wrote:
It's possible to write a reference wrapper around a value type. It's
also possible to write a value wrapper around a reference type.
However, the former is both easier and more efficient than
Andrei Alexandrescu Wrote:
Joel C. Salomon wrote:
Andrei Alexandrescu wrote:
A design that has one container type and several slice types that crawl
it in various ways is very compelling, and I think it will be a huge
selling point for D. It would be odd, not natural, to have arrays as a
On Thu, 30 Apr 2009 23:18:13 -0400, Rainer Deyke rain...@eldwood.com
wrote:
Robert Jacques wrote:
On Thu, 30 Apr 2009 17:23:19 -0400, Rainer Deyke rain...@eldwood.com
wrote:
It's possible to write a reference wrapper around a value type. It's
also possible to write a value wrapper around a
Hello,
I'm defining two ranges that go vertically over a range of ranges.
Consider for example an int[][]. That's a range that has a range as its
element type.
FrontTransversal goes transversally over the range of ranges and returns
the front of each element in turn:
int[][] x = new
Andrei Alexandrescu wrote:
Hello,
I'm defining two ranges that go vertically over a range of ranges.
Consider for example an int[][]. That's a range that has a range as its
element type.
FrontTransversal goes transversally over the range of ranges and returns
the front of each element in
Andrei Alexandrescu wrote:
A lot of interesting stuff.
POLS (Principle of Least Surprise) says they should be reference types.
That's what C, C++ (T[] doesn't look like it's using STL), C#, Java,
Lua, Python, etc., etc. programmers will expect. Jumping out from
behind a bush a surprising
Andrei ,
many thanks, ( not only because you are taking the time to explain ),
I think I have to say “Thanks Andrei” because your answer was very
gentle, ... ignoring all my grammar and (more important) logical
mistakes... let me remain with a : You are listening and this is in my
world :
Andrei Alexandrescu Wrote:
BLS wrote:
Question is, how this fits into a collection/container package.
..So frankly, I don't worry about naming conventions. I am more
concerned about ranges within a let's say dynamic d e queue.
Lock free ADTs are a final proof of product , no ?
Jason House wrote:
I'm a C++ refugee and value semantics make no sense to me. I always
declared classes (as part of function declaration) in C++ with a ...
Either T or const T. There were plenty of bugs where I messed up
and forgot the . D is nice in that it tries to simplify that. You
yourself
Andrei Alexandrescu wrote:
1. Value semantics (arrays are like int)
Don't forget:
+ Supports timely destruction of contents (i.e. RAII).
2. Value semantics with reference counting
I like this optimization and use it all the time in my own code, but I'm
not convinced that it should be the
99 matches
Mail list logo
