Hello all,
I came across some weird behaviors yesterday and I can't figure
out what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward declaration of factorial.
If I change the return type to int,
On Wednesday, 27 June 2012 at 09:07:57 UTC, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't
figure out what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward
How can I do that?
Why not list.remove(x); like in STL?
On Wednesday, 27 June 2012 at 09:37:01 UTC, Minas Mina wrote:
How can I do that?
Why not list.remove(x); like in STL?
std.container encodes the complexity of operations in the method
names. There is no way to remove a range in constant time in
SList, so you only get linearRemove.
And you
On Wednesday, 27 June 2012 at 09:52:14 UTC, Tobias Pankrath wrote:
On Wednesday, 27 June 2012 at 09:37:01 UTC, Minas Mina wrote:
How can I do that?
Why not list.remove(x); like in STL?
std.container encodes the complexity of operations in the
method names. There is no way to remove a range
Can you show me an example or removing a number?
I think that is a prime example of why std.container sucks both
in documentation and implemantation.
We really need to improve here, sadly development seems to be
bottlenecked by Andrei working on on allocator proposal. And
Andrei is busy at
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward declaration of factorial. If I
On 06/27/2012 01:24 PM, Timon Gehr wrote:
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained
Thank you for your reply. Yes, std.container really sucks.
Anyway, I made my program using C++ and STL
On Wed, 27 Jun 2012 05:37:00 -0400, Minas Mina
minas_mina1...@hotmail.co.uk wrote:
How can I do that?
Why not list.remove(x); like in STL?
SList is quite unusable.
If you are looking for STL-like containers, there is dcollections which
has a doubly-linked list, and supports syntax like
On Wednesday, June 27, 2012 08:25:04 Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 05:37:00 -0400, Minas Mina
minas_mina1...@hotmail.co.uk wrote:
How can I do that?
Why not list.remove(x); like in STL?
SList is quite unusable.
If you are looking for STL-like containers, there is
On Wed, 27 Jun 2012 13:44:34 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, June 27, 2012 08:25:04 Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 05:37:00 -0400, Minas Mina
minas_mina1...@hotmail.co.uk wrote:
How can I do that?
Why not list.remove(x); like in STL?
On Wednesday, 27 June 2012 at 18:26:46 UTC, Steven Schveighoffer
wrote:
The thing that makes SList useless is the O(n) removal. Nobody
will ever use SList when they can write a replacement that has
O(1) removal in 10 minutes.
Do you mean something like indexed/sorted dictionary? It doesn't
On 06/27/2012 08:46 PM, Roman D. Boiko wrote:
On Wednesday, 27 June 2012 at 18:26:46 UTC, Steven Schveighoffer wrote:
The thing that makes SList useless is the O(n) removal. Nobody will
ever use SList when they can write a replacement that has O(1) removal
in 10 minutes.
Do you mean something
On Wed, 27 Jun 2012 14:46:36 -0400, Roman D. Boiko r...@d-coding.com wrote:
On Wednesday, 27 June 2012 at 18:26:46 UTC, Steven Schveighoffer wrote:
The thing that makes SList useless is the O(n) removal. Nobody will
ever use SList when they can write a replacement that has O(1) removal
in
On Wednesday, 27 June 2012 at 19:10:24 UTC, Steven Schveighoffer
wrote:
On Wed, 27 Jun 2012 14:46:36 -0400, Roman D. Boiko
r...@d-coding.com wrote:
On Wednesday, 27 June 2012 at 18:26:46 UTC, Steven
Schveighoffer wrote:
The thing that makes SList useless is the O(n) removal.
Nobody will
On Wednesday, 27 June 2012 at 19:55:02 UTC, Roman D. Boiko wrote:
Look up SList docs, even with a reference to a *specific
element*, you cannot do O(1) removal.
Ha-ha, didn't know SList doesn't support that.
I somehow confused removal after a referenced element (which
should be easy to
On Wednesday, 27 June 2012 at 19:06:46 UTC, Timon Gehr wrote:
On 06/27/2012 08:46 PM, Roman D. Boiko wrote:
On Wednesday, 27 June 2012 at 18:26:46 UTC, Steven
Schveighoffer wrote:
The thing that makes SList useless is the O(n) removal.
Nobody will
ever use SList when they can write a
On Wednesday, 27 June 2012 at 20:00:18 UTC, Roman D. Boiko wrote:
Nice. But forces to use iterators everywhere.
(I'm not against iterators, they are almost necessary in certain
use cases, like this one.)
On Wed, 27 Jun 2012 15:57:42 -0400, Roman D. Boiko r...@d-coding.com wrote:
On Wednesday, 27 June 2012 at 19:55:02 UTC, Roman D. Boiko wrote:
Look up SList docs, even with a reference to a *specific element*, you
cannot do O(1) removal.
Ha-ha, didn't know SList doesn't support that.
I
On Wednesday, 27 June 2012 at 20:14:53 UTC, Steven Schveighoffer
wrote:
Removal of that element is perfectly possible, you just need to
maintain a reference to its predecessor. Which SList's range
does not keep track of. It all depends on tradeoffs of what
you want for performance, vs.
On Wednesday, 27 June 2012 at 20:29:02 UTC, Roman D. Boiko wrote:
On Wednesday, 27 June 2012 at 20:14:53 UTC, Steven
Schveighoffer wrote:
Removal of that element is perfectly possible, you just need
to maintain a reference to its predecessor. Which SList's
range does not keep track of. It
On Wednesday, 27 June 2012 at 21:22:31 UTC, Tobias Pankrath wrote:
E.g., to point to an element in the middle of some range we
would need to create another range and pass it to a function
along with the original range. I would hesitate to call them
ranges unless that is explicitly a goal for
On Wednesday, June 27, 2012 22:29:01 Roman D. Boiko wrote:
On Wednesday, 27 June 2012 at 20:14:53 UTC, Steven Schveighoffer
wrote:
Removal of that element is perfectly possible, you just need to
maintain a reference to its predecessor. Which SList's range
does not keep track of. It all
On Wednesday, 27 June 2012 at 21:38:28 UTC, Jonathan M Davis
wrote:
On Wednesday, June 27, 2012 22:29:01 Roman D. Boiko wrote:
On Wednesday, 27 June 2012 at 20:14:53 UTC, Steven
Schveighoffer
wrote:
Removal of that element is perfectly possible, you just need
to
maintain a reference to
Doesn't Andrei plan to do something about this module?
I have been playing latetly with std.concurrency and
core.thread. I like both, but they are entirely different
approaches to concurrency.
std.concurrency: Uses message passing. Does not allow passing of
mutable types.
core.thread: Essentially the same as the approach taken by Java.
1) Is
Minas Mina wrote:
I have been playing latetly with std.concurrency and
core.thread. I like both, but they are entirely different
approaches to concurrency.
std.concurrency: Uses message passing. Does not allow passing of
mutable types.
core.thread: Essentially the same as the approach
On Thu, 28 Jun 2012 00:34:50 +0200, Minas Mina wrote:
I have been playing latetly with std.concurrency and core.thread. I
like both, but they are entirely different approaches to concurrency.
std.concurrency: Uses message passing. Does not allow passing of mutable
types.
core.thread:
On Wednesday, 27 June 2012 at 22:34:51 UTC, Minas Mina wrote:
I have been playing latetly with std.concurrency and
core.thread. I like both, but they are entirely different
approaches to concurrency.
Aren't they great? ;)
std.concurrency: Uses message passing. Does not allow passing
of
On 06/27/2012 04:05 PM, Adam Burton wrote:
For example I would like to
have a thread calculate the sum of the first half of an array
while another thread would calculate the other half, and I could
add the two results at the end.
For this task there is another concurrency module called
You all helped, thank you :)
I will read the concurrency part tomorrow!
On Thursday, June 28, 2012 00:23:03 Minas Mina wrote:
Doesn't Andrei plan to do something about this module?
He came up with the basic design, and he's working on the custom allocator
design. Once that's been sorted out, std.container will be made to use it, and
more containers will be added
On Tuesday, 24 April 2012 at 20:09:32 UTC, Namespace wrote:
On Tuesday, 24 April 2012 at 19:34:26 UTC, Timon Gehr wrote:
On 04/24/2012 07:09 PM, Namespace wrote:
...
And therefore i get the same error, as if i wrote return
NotNull!(Foo)(this); instead of return
assumeNotNull(this);, in the
On Monday, 25 June 2012 at 20:06:21 UTC, Tobias Pankrath wrote:
-
struct A { bool a; alias a this; }
struct B { int b; alias b this; }
A a = false; // works
B b = 12; // works
struct C
{
A aa;
B ab;
}
C c = { false, 12 }; // does not work, because the implicit
conversion does
On Thursday, 28 June 2012 at 04:43:07 UTC, BLM768 wrote:
On Monday, 25 June 2012 at 20:06:21 UTC, Tobias Pankrath wrote:
-
struct A { bool a; alias a this; }
struct B { int b; alias b this; }
A a = false; // works
B b = 12; // works
struct C
{
A aa;
B ab;
}
C c = { false, 12 };
36 matches
Mail list logo
