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
24 matches
Mail list logo
