On 2010-05-28 14:12, Steven Schveighoffer wrote:
On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg wrote:
On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
wrote:
On 24/05/2010 16:45, Andrei Alexandrescu wrote:
In the past I have built a
On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg wrote:
On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
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
On Fri, 28 May 2010 06:24:26 -0400, Bruno Medeiros
wrote:
On 27/05/2010 11:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
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.
On 27/05/2010 11:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
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
th
On 2010-05-27 12:32, Steven Schveighoffer wrote:
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
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
th
On Wed, 19 May 2010 17:18:04 -0400, Steven Schveighoffer
wrote:
Andrej Mitrovic Wrote:
Well as long as you're here can I submit an error here? :)
I get an error while building the D2 branch:
Error: ArrayMultiset.obj : No such file or directory
Crud, I admit that I assumed anything that
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
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 things like setting the IP address
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 of
On Mon, 24 May 2010 11:01:06 -0400, Steven Schveighoffer
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 it.
> Granted J
Steven Schveighoffer 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 like a lot more crufty
On Mon, 24 May 2010 17:47:18 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 04:38 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 17:35:11 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
w
On 05/24/2010 04:38 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 17:35:11 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
wrote:
Sorry. Yes, by-key iteration should be possible.
OK, so we
On Mon, 24 May 2010 17:35:11 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
wrote:
Sorry. Yes, by-key iteration should be possible.
OK, so we should be able to iterate keys. And the keys are n
On 05/24/2010 04:08 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
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
On Mon, 24 May 2010 16:27:46 -0400, Andrei Alexandrescu
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
container without reconstructing
On Mon, 24 May 2010 16:07:22 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 01:49 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
wrote:
A pointer to the end element would be required for both appending and
back().
This further erodes my confidenc
On Mon, 24 May 2010 16:35:03 -0400, bearophile
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 p
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 05/24/2010 03:18 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 15:58:46 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 12:11 PM, bearophile wrote:
Steven Schveighof
On Mon, 24 May 2010 15:58:46 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 12:11 PM, bearophile wrote:
Steven Schveighoffer:
Is it unreasonable to expect to be able
to it
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
curre
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 good
On 05/24/2010 01:49 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
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
pointer to the last element m
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 d
On 05/24/2010 01:12 PM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
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
wi
On Mon, 24 May 2010 15:29:23 -0400, 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 comple
On Mon, 24 May 2010 15:32:01 -0400, bearophile
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 still pretty new. What do y
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
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 ho
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.
On Mon, 24 May 2010 12:27:10 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 11:14 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
w
On Thu, 20 May 2010 02:11:58 -0400, 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 overri
On Mon, 24 May 2010 13:36:01 -0400, Andrei Alexandrescu
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 you can iterate on all keys or
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:11:27 -0400, Simen kjaeraas
wrote:
Steven Schveighoffer 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 dcollections, where are you then?
You're at
Steven Schveighoffer 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 dcollections, where are you then?
You're at the point where the language allows you to create a class
foll
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.
Bye,
bearophile
On Mon, 24 May 2010 13:04:31 -0400, bearophile
wrote:
Steven Schveighoffer:
Scope class members should solve this. It's been thrown around forever
--
essentially, you should be able to define that a class member's storage
is
contained within the owner object.
I too have proposed this
Steven Schveighoffer:
> Scope class members should solve this. It's been thrown around forever --
> essentially, you should be able to define that a class member's storage is
> contained within the owner object.
I too have proposed this idea, but in my opinion you can't design a big part of
On Mon, 24 May 2010 12:18:02 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:58 AM, Steven Schveighoffer wrote:
On Sun, 23 May 2010 17:36:52 -0400, 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 c
On Mon, 24 May 2010 12:06:18 -0400, Robert Jacques
wrote:
On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
wrote:
[snip]
I understand these points, bu
On Mon, 24 May 2010 11:45:51 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:01 AM, Steven Schveighoffer wrote:
On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
wrote:
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
I.e. there aren't many kinds
On 05/24/2010 11:14 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
length
On Mon, 24 May 2010 11:51:39 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:39 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:21:20 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
I am not familiar with tries,
Missed that upon the first
On 05/24/2010 10:58 AM, Steven Schveighoffer wrote:
On Sun, 23 May 2010 17:36:52 -0400, 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 trad
On Mon, 24 May 2010 11:45:44 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
wrote:
On 05/24/2010 06:54 AM, Steven Schveighoffer wrote:
length is allowed to return NO_LENGTH_SUPPORT if O(1) leng
On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
wrote:
[snip]
I understand these points, but I'm already using interfaces to copy
data between container
On Sun, 23 May 2010 17:36:52 -0400, 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
On 05/24/2010 10:39 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 11:21:20 -0400, Andrei Alexandrescu
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 the
following other structure
On 05/24/2010 10:01 AM, Steven Schveighoffer wrote:
On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
wrote:
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
I.e. there aren't many kinds of HashMaps that derive from each
other. But the interfaces are not
On 05/24/2010 10:23 AM, Steven Schveighoffer wrote:
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
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 t
On Fri, 21 May 2010 22:56:54 -0400, Vladimir Panteleev
wrote:
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
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.
On Mon, 24 May 2010 11:21:20 -0400, Andrei Alexandrescu
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 the
following other structures as good examples that it's futile to fit
coll
On Mon, 24 May 2010 10:10:51 -0400, Andrei Alexandrescu
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 optimization. The only place whe
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
http://l
On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
wrote:
On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
I.e. there aren't many
kinds of HashMaps that derive from each other. But the interfaces
are not detrimental to your ideas. The only thing interfa
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 collection
On Sat, 22 May 2010 07:56:31 -0400, Michel Fortin
wrote:
On 2010-05-21 22:55:16 -0400, Walter Bright
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
On Fri, 21 May 2010 14:00:42 -0400, Andrei Alexandrescu
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, but this way, only one function
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
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,
On Sat, 22 May 2010 16:58:12 -0400, Andrei Alexandrescu
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
collections.
One thing befo
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 make
Fantastic work Steve,
Pretty good design IMHO, not sure why .. but somehow the collection
battle reminds me to
Steve Vai vs Ry Cooder
Bjoern
On 2010-05-23 17:36:52 -0400, Andrei Alexandrescu
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 nonessential.
I'm starting to wonder
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-22 16:01:37 -0400, Walter Bright 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 expensive operation.
When
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 t
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
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) {
/
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 concret
Michel Fortin wrote:
On 2010-05-21 22:55:16 -0400, Walter Bright
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",
defi
On 05/22/2010 06:28 AM, 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.
No it isn't. The point Pelle was making is that there are three use
cases for parameter passed arrays:
1. read-only (correspo
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 re
BCS 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 ) >
R2.complexity( 10_000 ) )
On 2010-05-22 08:16:27 -0400, bearophile said:
Michel Fortin:
Couldn't we just make a struct that cannot be implicitly copied?
The @disable attribute was invented for this purpose too:
struct Foo {
int x;
@disable this(this) {}
}
void main() {
Foo f1;
Foo f2 = f1;
}
That p
Michel Fortin:
> and you have to worry about null.
Nonnull references of course solve this problem.
> Couldn't we just make a struct that cannot be implicitly copied?
The @disable attribute was invented for this purpose too:
struct Foo {
int x;
@disable this(this) {}
}
void main() {
On 2010-05-22 07:56:31 -0400, Michel Fortin said:
@explicitdup struct Array { }
void testVal(Array array);
void testRef(ref Array array);
unittest {
Array array;
testVal(array); // error, cannot copy array implicitly
On 2010-05-21 22:55:16 -0400, Walter Bright 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",
defined as the work necessar
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 05/22/2010 01:00 PM, bearophile wrote:
Pelle:
Wouldn't gain anything from ref, and wouldn't work with const.
You are wrong, it works correctly with ref:
Yes, it works, but it doesn't gain anything from it, which is what I
said. :)
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[]
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:
voi
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
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
li
Andrei Alexandrescu Wrote:
>
> I don't know Tango, but Java's containers are a terrible example to
> follow. Java's container library is a ill-advised design on top of an
> underpowered language, patched later with some half-understood seeming
> of genericity. I think Java containers are a huge
Hello Andrei,
On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven
Schveighoffer 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
Hello Vladimir,
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
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 there is no reason that
Hello BLS,
ok Some collection types belong to the same family. So they should be
loosely coupled. How to do that without having Interfaces ?
How about this: Make a flat family of collections. Name the methods so that
across the lib, the same name does the same kind of thing and different nam
Hello Bill,
On Fri, May 21, 2010 at 9:43 AM, Steven Schveighoffer
wrote:
void foo(int[int] x)
{
x[5] = 5;
}
void main()
{
int[int] x;
foo(x);
assert(x[5] == 5); // fails
}
And with arrays at least it's even more insidious, because sometimes
it will seem to work, and sometimes it won't.
void
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
poo.ad
On Thu, 20 May 2010 04:42:35 +0300, Steven Schveighoffer
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.
Without meaning any disrespect to all the work you did, allow me t
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
libr
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
http://www.pr
On 21/05/2010 19:15, Andrei Alexandrescu wrote:
I'll now slowly answer the great replies I got in this thread, in
chronological order. Since I read them all before replying, I might
sometimes refer to future posts. Hopefully that won't be too confusing.
Andrei
Following the dcollection thread,
Steven Schveighoffer wrote:
I myself don't really use the interface aspect of the classes, it is mostly a
carryover from the Java/Tango inspirations. But I can see one good reason to
keep them -- binary interoperability. For example, it might be the case some
day when D has good support wit
Andrei Alexandrescu wrote:
See the -mergefunc compiler switch of LDC, to merge identical
functions (like ones produced by template instantiations). This
feature is not very powerful yet, but it's present and I have seen it
works.
Indeed. I'm no expert in linkers, but in my opinion this is one o
On 05/21/2010 01:34 PM, Walter Bright wrote:
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 Mi
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. I
On Fri, May 21, 2010 at 10:50 AM, superdan 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.
Unfort
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
1 - 100 of 167 matches
Mail list logo
