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 2010-05-24 00.06, bearophile wrote:
Andrei Alexandrescu:
1. Using a class makes implementing members easier because there's no
need to do work through an additional member. With a struct, you need a
pimpl approach. For example:
struct Array {
struct Impl {
...
}
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
Am 24.05.2010 16:08, schrieb Don:
4056 Template instantiation with bare parameter not documented
why don't remove this feature? it isn't syntactic sugar just an
alternative syntax (how many other alternative syntaxes needed?)
On 05/24/2010 11:53 AM, dennis luehring wrote:
Am 24.05.2010 16:08, schrieb Don:
4056 Template instantiation with bare parameter not documented
why don't remove this feature? it isn't syntactic sugar just an
alternative syntax (how many other alternative syntaxes needed?)
FWIW I swear by
Andrei Alexandrescu:
Oh, and the monitor isn't needed so that's an unused word there. I'd
forgotten about it.
It can be invented some kind of property or pragma for classes, to remove the
monitor from all the instances of that class. I don't know if this can be done,
if it is useful, and if
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 5/24/10, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
FWIW I swear by it.
Me too. I was opposed to it in the beginning as being unnecessary, but
it is really nice now that I use it.
auto a = to!int(whatever);
Just flows really nicely. to!(int)(whatever) isn't quite the same.
Adam Ruppe:
I was opposed to it in the beginning as being unnecessary, but
it is really nice now that I use it.
This is true for me too.
Bye,
bearophile
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 05/24/2010 07:04 PM, Adam Ruppe wrote:
On 5/24/10, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
FWIW I swear by it.
Me too. I was opposed to it in the beginning as being unnecessary, but
it is really nice now that I use it.
auto a = to!int(whatever);
Just flows really nicely.
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
50 matches
Mail list logo
