On 05/27/2010 08:42 PM, Leandro Lucarella wrote:
Andrei Alexandrescu, el 27 de mayo a las 20:06 me escribiste:
On 05/27/2010 06:28 PM, Jonathan M Davis wrote:
I take it that Array is basically supposed to be std.container's version of
C++'s vector or Java's ArrayList? If so, I would suggest tha
On 05/27/2010 09:27 PM, Michel Fortin wrote:
On 2010-05-27 21:08:29 -0400, Andrei Alexandrescu
said:
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
I defined Array as a straightforward implementation of the homonym
abstraction. There are a few imperfect
On 2010-05-27 21:08:29 -0400, Andrei Alexandrescu
said:
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
I defined Array as a straightforward implementation of the homonym
abstraction. There are a few imperfect corners, but by and large I'm
starting to b
Andrei Alexandrescu, el 27 de mayo a las 20:06 me escribiste:
> On 05/27/2010 06:28 PM, Jonathan M Davis wrote:
> >I take it that Array is basically supposed to be std.container's version of
> >C++'s vector or Java's ArrayList? If so, I would suggest that Array is not
> >the best of names in that i
Hello sybrandy,
Evening.
I'm having a bit of a problem and I'm hoping someone can help. I'm
trying to create a class that is shared across threads. The only
purpose of this class is to write data to somewhere, though currently
a file. A single-threaded version of this works fine, however I c
Evening.
I'm having a bit of a problem and I'm hoping someone can help. I'm
trying to create a class that is shared across threads. The only
purpose of this class is to write data to somewhere, though currently a
file. A single-threaded version of this works fine, however I can't
seem to g
On 05/27/2010 06:28 PM, Jonathan M Davis wrote:
I take it that Array is basically supposed to be std.container's version of
C++'s vector or Java's ArrayList? If so, I would suggest that Array is not
the best of names in that it would become very easy to confuse it with
built-in arrays when discus
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
I defined Array as a straightforward implementation of the homonym
abstraction. There are a few imperfect corners, but by and large I'm
starting to believe it's becoming possible to write certain
cross-contai
http://d.puremagic.com/issues/show_bug.cgi?id=4244
Jonathan M Davis wrote:
wouldn't be confused with anything else. If you really want Array, that's
Personally, I would have just gone with Vector, since it's a fairly
standard name for that sort of container and wouldn't be confused with
anything else.
I take it you don't work in simulation or
I take it that Array is basically supposed to be std.container's version of
C++'s vector or Java's ArrayList? If so, I would suggest that Array is not
the best of names in that it would become very easy to confuse it with
built-in arrays when discussing them (particularly in verbal communication
On Thu, 27 May 2010 18:32:34 -0400, bearophile
wrote:
out of the well walked down footpath (I don't know how this is written
in English)
off the well beaten path :)
-Steve
Steven Schveighoffer wrote:
I don't feel like pouring through a bugzilla discussion, but the reason
is because I may have gone to vote for an issue, but found I was out of
votes, and I want to keep my existing ones (or I had to cancel another
bug vote in order to vote for the new one). At a l
Don:
> Ouch! I hate it when newbies hit compiler crashes.
This happens often. People that have more experience in D use it in the way it
is meant to be used, so they follow the normal usage patterns, that are often
tested enough (or have already known bugs).
But newbies sometimes use D features
Lutger wrote:
What is the purpose of votes for closed bugs anyway? Should they not just get
removed automatically?
On top of the reasons linked to in my previous reply:
- Many of us would probably like to be able to see which bugs they voted
for have recently been fixed.
- Resolving a bug w
On Thu, 27 May 2010 18:09:48 -0400, Stewart Gordon
wrote:
Steven Schveighoffer wrote:
Indeed, it would be nice if bugzilla reminded you that you have votes
for closed bugs. Every time I go to vote for a bug, I remove my votes
from any closed bugs (which are obvious with the strikethroug
Lutger wrote:
Steven Schveighoffer wrote:
On Thu, 27 May 2010 15:34:38 -0400, Don wrote:
Votes however are definitely not ignored.
If you search bugzilla, you'll find that there are 86 closed bugs which
still have votes for them! Compared with 228 open bugs.
So the votes themeselves are far
Steven Schveighoffer wrote:
> On Thu, 27 May 2010 15:34:38 -0400, Don wrote:
>
>> Votes however are definitely not ignored.
>> If you search bugzilla, you'll find that there are 86 closed bugs which
>> still have votes for them! Compared with 228 open bugs.
>> So the votes themeselves are far fr
Matthias wrote:
I'm very new to D and misused the module identifier, I thought it would
be the namespace/package name.
The dmd compiler v2.046 produces correct output ("Error: module test
from file xxx.d conflicts with another module test from file yyy.d"), if
multiple placement of same modul
Steven Schveighoffer wrote:
Indeed, it would be nice if bugzilla reminded you that you have votes
for closed bugs. Every time I go to vote for a bug, I remove my votes
from any closed bugs (which are obvious with the strikethrough text).
But I don't notice that until I go to vote for one. I
Don wrote:
Stewart Gordon wrote:
Peculiarly, nothing with a WONTFIX resolution has any votes.
I think hardly anything has ever been closed with WONTFIX.
I get 61 as I look. At the moment, about 7.5% of bugs filed here have
any votes, so I'm not sure that 61 counts as hardly anything.
S
Steven Schveighoffer:
> However, doing this may lead to further issues. I think if you had a
> class C that derived from B, calling B.foo(c) would result in an ambiguity
> without a cast.
This is D code:
import std.c.stdio: puts;
class A {
void foo(A a) { puts("A.foo"); }
}
class B :
I'm very new to D and misused the module identifier, I thought it would
be the namespace/package name.
The dmd compiler v2.046 produces correct output ("Error: module test
from file xxx.d conflicts with another module test from file yyy.d"), if
multiple placement of same module identifier are
Steven Schveighoffer:
> This is actually the first question I posted on this newsgroup in 2007.
I am very late then, sorry for not asking this is D.learn.
> It's called method "hijacking", look for it on the D website for a
> thorough explanation. Note that this is actually the default behav
Stewart Gordon wrote:
Don wrote:
The situation is a little more complex than bearophile thinks.
For the last six months or so, Walter has concentrated on making sure
that all of the examples in TDPL will work correctly. This has
involved implementing all of the new features. Most of the bugs
On Thu, 27 May 2010 17:00:08 -0400, bearophile
wrote:
While answering to Larry Luther in a long thread in D.learn:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=19913
I have found an interesting difference that I didn't know between Java
and D.
While answering to Larry Luther in a long thread in D.learn:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=19913
I have found an interesting difference that I didn't know between Java and D.
Here I have reduced the test cases:
// Java code
class A {
Ali Ãehreli:
> Most of it comes from the use of that temporary. -O doesn't help either.
Right. I will probably put this in Bugzilla, even if it's a low priority thing.
Bye,
bearophile
Don wrote:
The situation is a little more complex than bearophile thinks.
For the last six months or so, Walter has concentrated on making sure
that all of the examples in TDPL will work correctly. This has involved
implementing all of the new features. Most of the bugs which were fixed
were
On Thu, 27 May 2010 15:34:38 -0400, Don wrote:
Votes however are definitely not ignored.
If you search bugzilla, you'll find that there are 86 closed bugs which
still have votes for them! Compared with 228 open bugs.
So the votes themeselves are far from up-to-date.
Indeed, it would be nic
Stewart Gordon wrote:
bearophile wrote:
Stewart Gordon:
This is the one that needs fixing most of all:
http://d.puremagic.com/issues/show_bug.cgi?id=677
I don't think Walter will fix that bug.
So you suspect that he's going to leave D until the end of time as a
language that cannot be impl
On 05/27/2010 02:33 PM, bearophile wrote:
I have noticed a significant speed difference between foo1 and foo2 (D2 code):
import std.c.stdio: printf;
int foo1(int x, int y) {
static int[int[2]] cache;
int[2] args = [x, y];
cache[args] = x;
return x;
}
int foo2(int x, int y)
Another update:
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
I simplified the implementation (no more array allocation etc.),
eliminated replace() and insertBefore() after convincing myself they are
not a good fit for lists, and added linearRemove(Take!R
bearophile wrote:
I have noticed a significant speed difference between foo1 and foo2 (D2 code):
import std.c.stdio: printf;
int foo1(int x, int y) {
static int[int[2]] cache;
int[2] args = [x, y];
cache[args] = x;
Most of it comes from the use of that temporary. -O doesn't help e
On 05/27/2010 11:01 AM, Pillsy wrote:
== Quote from Andrei Alexandrescu
(seewebsiteforem...@erdani.org)'s article:
I just implemented a singly-linked list type to illustrate
the container abstraction.
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
[...]
Pl
bearophile wrote:
Stewart Gordon:
This is the one that needs fixing most of all:
http://d.puremagic.com/issues/show_bug.cgi?id=677
I don't think Walter will fix that bug.
So you suspect that he's going to leave D until the end of time as a
language that cannot be implemented by third partie
On Thu, May 27, 2010 at 5:44 AM, Don wrote:
> bearophile wrote:
>>
>> Don:
>>>
>>> When is it better to do it that way, rather than just iterating over all
>>> elements, and then completely empty the container?
>>> (Just curious -- I'm having trouble thinking of a use case for this
>>> feature).
>
On 27.05.2010 18:38, Michel Fortin wrote:
But it isn't thread-safe, and I
expect it would be a pain to make lazy initialization thread-safe,
although I haven't tried yet.
That has been the very point of this thread (no pun). In my other post I
supplied a hack that uses two variables, shared an
== Quote from Andrei Alexandrescu
(seewebsiteforem...@erdani.org)'s article:
> I just implemented a singly-linked list type to illustrate
> the container abstraction.
> http://erdani.com/d/phobos/std_container.html
> http://erdani.com/d/phobos/container.d
[...]
> Please let me know of how you find
On 2010-05-27 09:57:30 -0400, Max Samukha said:
We cannot impose on the user of Q_OBJECT the requirement that a and b
should not be circularly imported or that he has to manually call an
initialization function etc.
Just a small note...
In the D/Objective-C bridge, I've resorted to lazy ini
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Tue, 25 May 2010 23:29:34 -0400, Walter Bright
> wrote:
> > Steven Schveighoffer wrote:
> >> On Mon, 24 May 2010 18:13:38 -0400, Walter Bright
> >> wrote:
> >>
> >>> Steven Schveighoffer wrote:
> All an interface does is
Don:
> Yes, but if I understand correctly, the only reason to have removeAny
> _as a primitive_ is for speed. And iterating over the container followed
> by a single removal is almost always going to be much faster.
Most things in Python are designed to be handy first, and fast later. So I
doub
On 27/05/2010 06:06, Andrei Alexandrescu wrote:
std.container will not contain hot-swappable components. It will contain
components that could be used in some of the hot swaps. It's just one
level lower than what you are discussing.
That doesn't make it any more or less incompatible with dcollec
Stewart Gordon wrote:
Don wrote:
IMHO, one of the most important bugs to fix is actually a spec bug:
4056 Template instantiation with bare parameter not documented
Why single out that one?
Because it's a feature that is used in almost every non-trivial D2
program, and the spec gives no h
On 05/27/2010 08:23 AM, Steven Schveighoffer wrote:
You're making a number of great points in the four posts starting with
this. Since they sort of augment one another, let me quote and answer
them all here.
On Thu, 27 May 2010 00:36:24 -0400, Andrei Alexandrescu
wrote:
I just implemented a
On 05/27/2010 03:47 PM, Jason House wrote:
In module b, delete the import of c. In module c, delete the import of b. Your sample code will then compile and run. It probably wouldn't do what you want though; you'll have two globals
(b.foo and c.foo). I suspect what you really want is one glo
On Thu, 27 May 2010 00:36:24 -0400, Andrei Alexandrescu
wrote:
I just implemented a singly-linked list type to illustrate the container
abstraction.
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
One interesting aspect is that SList must cooperate wit
On Thu, 27 May 2010 09:27:39 -0400, Steven Schveighoffer
wrote:
On Thu, 27 May 2010 09:23:03 -0400, Steven Schveighoffer
wrote:
On Thu, 27 May 2010 00:36:24 -0400, Andrei Alexandrescu
wrote:
I just implemented a singly-linked list type to illustrate the
container abstraction.
htt
On 05/27/2010 06:49 AM, Don wrote:
bearophile wrote:
Jonathan M Davis:
Well, I've never needed to do that particular operation on _any_
container, so it does strike me as weird regardless. I've basically
always been looking to remove a specific element or elements or to
remove the element at a
On Thu, 27 May 2010 09:23:03 -0400, Steven Schveighoffer
wrote:
On Thu, 27 May 2010 00:36:24 -0400, Andrei Alexandrescu
wrote:
I just implemented a singly-linked list type to illustrate the
container abstraction.
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos
On Thu, 27 May 2010 00:36:24 -0400, Andrei Alexandrescu
wrote:
I just implemented a singly-linked list type to illustrate the container
abstraction.
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
One interesting aspect is that SList must cooperate wit
Max Samukha Wrote:
> There was a discussion about those a while ago that terminated with
> Andrei's authoritative "it would be a step backward".
>
> I am not entirely convinced that there had been a step forward in the
> first place. Defining static construction order to be determined by the
>
bearophile wrote:
Don:
When is it better to do it that way, rather than just iterating over all
elements, and then completely empty the container?
(Just curious -- I'm having trouble thinking of a use case for this
feature).
I'm having troubles understanding why two persons have troubles seei
On 05/27/2010 01:37 PM, Max Samukha wrote:
module a;
mixin template Foo()
{
static immutable Object foo;
shared static this()
{
foo = cast(immutable)new Object;
}
}
module b;
import a;
import c;
mixin Foo;
module c;
import a;
import b;
mixin Foo;
In this scenario one is forced to
I have noticed a significant speed difference between foo1 and foo2 (D2 code):
import std.c.stdio: printf;
int foo1(int x, int y) {
static int[int[2]] cache;
int[2] args = [x, y];
cache[args] = x;
return x;
}
int foo2(int x, int y) {
static struct Pair { int x, y; }
stati
Wed, 26 May 2010 21:43:38 -0400, Robert Jacques wrote:
> On Wed, 26 May 2010 20:44:50 -0400, retard wrote:
>
>> Thu, 27 May 2010 01:52:32 +0200, Simen kjaeraas wrote:
>>
>>> On Thu, 27 May 2010 01:41:16 +0200, retard
>>> wrote:
>>>
Wed, 26 May 2010 22:05:48 +0200, Jacob Carlborg wrote:
>>>
Stewart Gordon:
> This is the one that needs fixing most of all:
> http://d.puremagic.com/issues/show_bug.cgi?id=677
I don't think Walter will fix that bug. If you think that bug is important for
you, then I suggest you to find other people that agree with you, and write
down the specs yourself
Don:
> When is it better to do it that way, rather than just iterating over all
> elements, and then completely empty the container?
> (Just curious -- I'm having trouble thinking of a use case for this
> feature).
I'm having troubles understanding why two persons have troubles seeing use
cases
bearophile wrote:
Jonathan M Davis:
Well, I've never needed to do that particular operation on _any_ container,
so it does strike me as weird regardless. I've basically always been looking
to remove a specific element or elements or to remove the element at a
specific location.
You have pro
Don wrote:
IMHO, one of the most important bugs to fix is actually a spec bug:
4056 Template instantiation with bare parameter not documented
Why single out that one?
This is the one that needs fixing most of all:
http://d.puremagic.com/issues/show_bug.cgi?id=677
Stewart.
On Tue, 25 May 2010 23:29:34 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
On Mon, 24 May 2010 18:13:38 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
All an interface does is give an abstract representation of functions
that are *already there*. Removing the inter
On Thu, 27 May 2010 00:20:24 -0400, Jonathan M Davis
wrote:
Steven Schveighoffer wrote:
Jonathan M Davis Wrote:
Looks interesting overall. There is one function, however, which makes
no
sense to me: removeElement()/stableRemoveElement().
So, it basically removes a random element from t
There was a discussion about those a while ago that terminated with
Andrei's authoritative "it would be a step backward".
I am not entirely convinced that there had been a step forward in the
first place. Defining static construction order to be determined by the
module import graph had been a
Jonathan M Davis:
> Well, I've never needed to do that particular operation on _any_ container,
> so it does strike me as weird regardless. I've basically always been looking
> to remove a specific element or elements or to remove the element at a
> specific location.
You have probably missed
Andrei Alexandrescu:
> Done. removeAny was my choice as of a few months ago but I'd forgotten.
I suggest to call it just "pop".
Bye,
bearophile
On 2010-05-27 07.17, Robert Jacques wrote:
On Wed, 26 May 2010 16:05:48 -0400, Jacob Carlborg wrote:
I've asked this before, probably several times: if and when will D get
the uniform function call syntax that has been talked about? Example:
void foo (int i) {}
3.foo();
And please don't say
On 2010-05-27 01.52, Simen kjaeraas wrote:
On Thu, 27 May 2010 01:41:16 +0200, retard wrote:
Wed, 26 May 2010 22:05:48 +0200, Jacob Carlborg wrote:
I've asked this before, probably several times: if and when will D get
the uniform function call syntax that has been talked about? Example:
vo
On 2010-05-27 01.41, retard wrote:
Wed, 26 May 2010 22:05:48 +0200, Jacob Carlborg wrote:
I've asked this before, probably several times: if and when will D get
the uniform function call syntax that has been talked about? Example:
void foo (int i) {}
3.foo();
And please don't say it's already
> ICollection acoll;
> ICollection bcoll;
> A[] cat;
> ICollection.CopyTo(A[],int)
> ICollection.CopyTo(B[],int) - note the signature, the destination array
> can't be an array of supertype. There's no chance to throw an exception
> because the code doesn't pass type check at compile time.
To ea
Steven Schveighoffer Wrote:
> On Tue, 25 May 2010 02:26:02 -0400, Kagamin wrote:
>
> > Recently I've hit a problem with collections in C#. Given classes
> > class A {}
> > class B {}
> > And two collections Collection and Collection it's possible to
> > concat them into an array A[]. The effic
70 matches
Mail list logo
