On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++ library that abstracted features of
the OS. My goal was to make it possible
On 27/05/2010 11:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++ library that abstracted features of
the OS. My goal was to make it possible
On Fri, 28 May 2010 06:24:26 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 27/05/2010 11:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I
On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg d...@me.com wrote:
On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++ library that abstracted features of
the OS. My goal was to make it possible to dynamically load a module
that abstracted
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a C++ library that abstracted features of
the OS. My goal was to make it possible to dynamically load a module
that abstracted things like setting the IP address of a network
interface. My modules used std::string instead
On 2010-05-23 23.36, Andrei Alexandrescu wrote:
I've thought for a very long time about the class vs. struct choice in a
container, and I came to a startling conclusion: it (almost) doesn't
matter. Could be either, and the tradeoffs involved are nonessential.
Here they are:
1. Using a class
On Sat, 22 May 2010 16:58:12 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/19/2010 03:07 PM, Steven Schveighoffer wrote:
Ellery Newcomer Wrote:
Are the collections supposed to not have isEmpty members?
No. Use length == 0. O(1) length is always supported for all
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I
On Fri, 21 May 2010 14:00:42 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/20/2010 05:34 AM, Steven Schveighoffer wrote:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code,
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
length is allowed to return NO_LENGTH_SUPPORT if O(1) length isn't
possible,
Do you agree that's an awkwardness?
but all dcollections define length.
I was hoping we're on the verge of agreeing to yank all interfaces and
let the
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
I am not familiar with tries,
Missed that upon the first read. I suggest you look at tries and the
following other structures as good examples that it's futile to fit
collections into hierarchies.
http://en.wikipedia.org/wiki/Trie
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
length is allowed to return NO_LENGTH_SUPPORT if O(1) length isn't
possible,
Do you agree that's an awkwardness?
Yes, at that point it's an
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
length is allowed to return NO_LENGTH_SUPPORT if O(1) length isn't
possible,
Do you agree
On 05/24/2010 10:39 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:21:20 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
I am not familiar with tries,
Missed that upon the first read. I suggest you look at tries and
On Sun, 23 May 2010 17:36:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I've thought for a very long time about the class vs. struct choice in a
container, and I came to a startling conclusion: it (almost) doesn't
matter. Could be either, and the tradeoffs involved are
On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
[snip]
I understand these points, but I'm
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
On 05/24/2010 10:58 AM, Steven Schveighoffer wrote:
On Sun, 23 May 2010 17:36:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I've thought for a very long time about the class vs. struct choice in
a container, and I came to a startling conclusion: it (almost) doesn't
matter.
On Mon, 24 May 2010 11:51:39 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:39 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:21:20 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
On 05/24/2010 11:14 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On Mon, 24 May 2010 11:45:51 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:01 AM, Steven Schveighoffer wrote:
On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 12:06:18 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven
On Mon, 24 May 2010 12:18:02 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:58 AM, Steven Schveighoffer wrote:
On Sun, 23 May 2010 17:36:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I've thought for a very long time about the class
On Mon, 24 May 2010 13:11:27 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Steven Schveighoffer schvei...@yahoo.com wrote:
And if 3rd party X _needs_ to use interfaces, and 3rd party Y _needs_
to use interfaces, and your code depends on X and Y, and interfaces
aren't defined by
On 05/24/2010 12:11 PM, bearophile wrote:
Steven Schveighoffer:
Is it unreasonable to expect to be able
to iterate the keys in a trie? (I don't really know, I've never worked
with them)
On tries you can iterate on all keys or on a sorted range of the keys.
There's one more way of iteration
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 12:11 PM, bearophile wrote:
Steven Schveighoffer:
Is it unreasonable to expect to be able
to iterate the keys in a trie? (I don't really know, I've never worked
with them)
On tries
On Thu, 20 May 2010 02:11:58 -0400, Bernard Helyer b.hel...@gmail.com
wrote:
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 11:14 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On 05/24/2010 06:27 PM, Andrei Alexandrescu wrote:
struct List { int v; List * next; }
While I do agree with that design for a list, that is no reference type.
I thought we wanted reference types.
Steven Schveighoffer:
Look at D's arrays. Is appending with D's arrays the fastest it possibly
could be? Hell no, but it's good enough for most situations, and safe.
Append in D dynamic arrays is awful, it's slow and requires complex code (and
currently there are not explanations about how
And the appending is hard to use too, see the ridiculously complex to use
messy capacity, reserve and and assumeSafeAppend. So overall it's a good
example of what I will never want to copy.
Bye,
bearophile
On Mon, 24 May 2010 15:32:01 -0400, bearophile bearophileh...@lycos.com
wrote:
And the appending is hard to use too, see the ridiculously complex to
use messy capacity, reserve and and assumeSafeAppend. So overall it's
a good example of what I will never want to copy.
That part is
On Mon, 24 May 2010 15:29:23 -0400, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
Look at D's arrays. Is appending with D's arrays the fastest it
possibly
could be? Hell no, but it's good enough for most situations, and safe.
Append in D dynamic arrays is awful, it's
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 12:11 PM, bearophile wrote:
Steven Schveighoffer:
Is it unreasonable to expect to be able
to iterate the keys in a trie? (I don't
Steven Schveighoffer:
complex code?
a ~= b;
Seems pretty not complex.
I meant on the implementation side. Arrays are used all the time, and they are
basic blocks to be used everywhere so a programmer probably must understand how
they work inside.
That part is still pretty new. What do
On 05/24/2010 01:49 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
A pointer to the end element would be required for both appending and
back().
This further erodes my confidence. Size needs to be maintained _and_ a
On 05/24/2010 02:01 PM, Pelle wrote:
On 05/24/2010 06:27 PM, Andrei Alexandrescu wrote:
struct List { int v; List * next; }
While I do agree with that design for a list, that is no reference type.
List* is.
My point was that the pressure for a really simple hand-rolled SLL is
huge. A
On 05/24/2010 02:29 PM, bearophile wrote:
Steven Schveighoffer:
Look at D's arrays. Is appending with D's arrays the fastest it possibly
could be? Hell no, but it's good enough for most situations, and safe.
Append in D dynamic arrays is awful, it's slow and requires complex code (and
On Mon, 24 May 2010 15:58:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 12:11 PM, bearophile wrote:
Steven
On 05/24/2010 03:18 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 15:58:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Andrei Alexandrescu:
When was the last time you measured? I thought the speed has largely
improved since Steve integrated his work.
I have timed it after that integration. I have seen a performance improvement,
but it's small. I can perform some syntactic benchmarks.
Later,
bearophile
On Mon, 24 May 2010 16:07:22 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 01:49 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
A pointer to the end element would be required for
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Sorry. Yes, by-key iteration should be possible.
OK, so we should be able to iterate keys. And the keys are not stored in
the trie structure itself. So how does one iterate the keys of the
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Sorry. Yes, by-key iteration should be possible.
OK, so we should be able to iterate keys. And the keys are not stored in
the trie structure
On 05/24/2010 04:38 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 17:35:11 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On Mon, 24 May 2010 17:47:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 04:38 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 17:35:11 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
Steven Schveighoffer schvei...@yahoo.com wrote:
On the flip side, if containers did not implement interfaces, having to
do this:
class WrappedSet!(alias Impl, V) : Set!V
{
private Impl!V impl;
int functionToSatisfySet() { return impl.functionToSatisfySet(); }
...
}
seems to me
On Mon, 24 May 2010 11:01:06 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
It's done all the time in Java and .NET. For example, A GUI listbox
widget exposes its elements as an array of elements, which implement the
List interface. You don't ever see the implementation or need
On 2010-05-22 16:01:37 -0400, Walter Bright newshou...@digitalmars.com said:
Michel Fortin wrote:
What's the point of having extra indirection here?
Good question. I think the answer is:
1. When do you ever want to copy a collection? I almost never do,
because copying one is an inherently
I've thought for a very long time about the class vs. struct choice in a
container, and I came to a startling conclusion: it (almost) doesn't
matter. Could be either, and the tradeoffs involved are nonessential.
Here they are:
1. Using a class makes implementing members easier because there's
On 2010-05-23 17:36:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I've thought for a very long time about the class vs. struct choice in
a container, and I came to a startling conclusion: it (almost) doesn't
matter. Could be either, and the tradeoffs involved are
Fantastic work Steve,
Pretty good design IMHO, not sure why .. but somehow the collection
battle reminds me to
Steve Vai vs Ry Cooder
vbg
Bjoern
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
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:
Pelle:
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.
You are wrong, it works correctly with ref:
import std.stdio: writeln;
void inc_all(ref int[] array)
Pelle:
Yes, it works, but it doesn't gain anything from it, which is what I
said. :)
Then what you have said was useless.
Bye,
bearophile
On 2010-05-21 22:55:16 -0400, Walter Bright newshou...@digitalmars.com said:
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: impedance matching,
On 2010-05-22 07:56:31 -0400, Michel Fortin michel.for...@michelf.com said:
@explicitdup struct Array { }
void testVal(Array array);
void testRef(ref Array array);
unittest {
Array array;
testVal(array); // error, cannot
BCS n...@anon.com wrote:
Cool. Now how do I write code so that it will always iterate the
collection with the bigger O() lookup time (O(n) before O(log2(n))
before O(log16(n)) before O(1))? :D
Add a function.
auto foo( R1, R2 )( R1 r1, R2 r2 ) if ( R1.complexity( 10_000 )
On 05/22/2010 01:28 PM, bearophile wrote:
Pelle:
Yes, it works, but it doesn't gain anything from it, which is what I
said. :)
Then what you have said was useless.
Bye,
bearophile
How so? Passing by reference is slower, and sometimes completely
meaningless. Therefore, having a rule that
On 05/19/2010 03:07 PM, Steven Schveighoffer wrote:
Ellery Newcomer Wrote:
Are the collections supposed to not have isEmpty members?
No. Use length == 0. O(1) length is always supported for all
collections.
One thing before I forget: I think any good collection abstraction must
be
Andrei Alexandrescu:
Keeping the length cached in a singly-linked list is a costly mistake.
It works against splicing (an important list primitive) and most of the
time you don't need it so why waste time updating it.
... LinkedList(T, bool WithLength=True) {
static if(WithLength) {
//
Andrei Alexandrescu Wrote:
One thing before I forget: I think any good collection abstraction must
be concretized back to the classic collection instances. Singly-linked
lists definitely can't be left off the list! It would be an epic
failure. Imagine the papers! New York Times: D has
On 05/22/2010 09:07 PM, Sean Kelly wrote:
Andrei Alexandrescu Wrote:
One thing before I forget: I think any good collection abstraction must
be concretized back to the classic collection instances. Singly-linked
lists definitely can't be left off the list! It would be an epic
failure. Imagine
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the container
interfaces are unable to express iteration is a corollary of the
design's problem and an climactic
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the container
interfaces are unable to express
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@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
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@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
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Is there some other reason to use structs besides copy construction?
-Steve
memory management n shit. with a
On 05/21/2010 09:14 AM, Steven Schveighoffer wrote:
Second, since reference types are the right thing to do, classes are much
easier to deal with. I know AA's are reference types that are structs, but the
code needed to perform this feat is not trivial. The AA has only one member, a
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
schvei...@yahoo.com wrote:
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Is there some other reason to use
On 05/19/2010 07:21 PM, bearophile wrote:
Andrei Alexandrescu:
Destroy me :o).
You ideas are surely interesting, but I don't think there's a simple
way to change his code according to your ideas. People can use the
dcollections in the following weeks and months, and when you have
implemented
On 05/21/2010 11:55 AM, Ellery Newcomer wrote:
On 05/21/2010 09:14 AM, Steven Schveighoffer wrote:
Second, since reference types are the right thing to do, classes are
much easier to deal with. I know AA's are reference types that are
structs, but the code needed to perform this feat is not
On 05/19/2010 07:57 PM, Bill Baxter wrote:
On Wed, May 19, 2010 at 4:01 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
My vision, in very brief, is to foster a federation of independent
containers abiding to identical names for similar functionality. Then a few
concept checks (a
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the
container interfaces are unable to express iteration is a corollary
of the design's problem and an climactic disharmony.
My vision, in very brief, is to
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
superdan Wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Is there some other reason to use structs besides
On 05/19/2010 09:59 PM, Robert Jacques wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the container
interfaces are unable to express iteration is a corollary of the
On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven
Schveighofferschvei...@yahoo.com said:
I understand these points, but I'm already using interfaces to
copy data between containers. I don't have to, I could have used
generic code,
On 05/20/2010 06:17 AM, Michel Fortin wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com
said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one
On 05/20/2010 09:14 AM, Pelle wrote:
On 05/20/2010 03:22 PM, Steven Schveighoffer wrote:
One thing I just thought of -- in dcollections, similar types can be
compared to one another. For example, you can check to see if a
HashSet is equal to a TreeSet. But that would not be possible without
On 05/20/2010 09:41 AM, Michel Fortin wrote:
On 2010-05-20 08:30:59 -0400, bearophile bearophileh...@lycos.com said:
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.
Right. But the purpose of a good compiler is to kill those,
devirtualizing. LLVM devs
On 05/20/2010 02:47 PM, bearophile wrote:
Michel Fortin:
Devirtualization is only possible in certain cases: when the
function knows exactly which type it'll get.
You are wrong, in most cases there are ways to de-virtualize, even
when the runtime type isn't exactly known, but sometimes to do
On Fri, May 21, 2010 at 10:50 AM, superdan su...@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
Andrei Alexandrescu wrote:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add and purge ...
}
I agree with Michael Fortin that the | is questionable.
Andrei Alexandrescu wrote:
On 05/19/2010 09:59 PM, Robert Jacques wrote:
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it needlessly expands the radius of comprehension
needed to understand and use the library. (See Tangled up in tools
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: impedance matching,
defined as the work necessary to get one library module to work with another
Hello superdan,
dun tell me it dun work. i dun explain shit again. it works coz a
struct cant be null. but a struct can be a ref if it only haz one
pointer inside. methinks the builtin hash iz dat way.
void foo(container!shit poo)
{
if(!poo) poo = new container!shit; // fuck dat shit
Hello Vladimir,
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
schvei...@yahoo.com wrote:
interfaces
Does that imply that the most important methods are virtual?
If so, say good-bye to inlining, and hello to an additional level of
dereferencing.
From a technical standpoint
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with warnings as it overrides opEquals, but
doesn't mark it as such.
On 20/05/10 18:11, Bernard Helyer wrote:
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with warnings as it overrides opEquals, but
On 20/05/10 18:16, Bernard Helyer wrote:
On 20/05/10 18:11, Bernard Helyer wrote:
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it needlessly expands the radius of comprehension
needed to understand and
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.
Right. But the purpose of a good compiler is to kill those, devirtualizing.
LLVM devs are working on this too. See:
http://llvm.org/bugs/show_bug.cgi?id=6054
http://llvm.org/bugs/show_bug.cgi?id=3100
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is
On 05/20/2010 03:22 PM, Steven Schveighoffer wrote:
One thing I just thought of -- in dcollections, similar types can be compared
to one another. For example, you can check to see if a HashSet is equal to a
TreeSet. But that would not be possible without interfaces.
-Steve
I'm sorry, but
On 2010-05-20 09:22:27 -0400, Steven Schveighoffer schvei...@yahoo.com said:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I
On 2010-05-20 08:30:59 -0400, bearophile bearophileh...@lycos.com said:
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.
Right. But the purpose of a good compiler is to kill those,
devirtualizing. LLVM devs are working on this too. See:
Steven Schveighoffer:
You get a much higher speedup when things can be inlined than virtual vs.
non-virtual.
In current D compilers virtual functions prevent inlining. This can give some
performance loss.
Bye,
bearophile
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it
1 - 100 of 125 matches
Mail list logo
