Growable BinaryHeap: use w/Array?
Just wondering: If I want a growable binary heap (I'd be open to other priority queue structures, for that matter ;), is the standard way in D (w/Phobos) to combine std.container.BinaryHeap with std.container.Array? Any reason why BinaryHeap can't deal with ordinary dynamic array appending, or appender instances, for that matter? Or, to put the questions a bit differently: Is there a reason why std.array doesn't have an insertBack method (that BinaryHeap can use) either defined for dynamic arrays or for std.array.Appender? Just trying to figure out what's what here :) -- Magnus Lie Hetland http://hetland.org
std.gc doc page
It seems std.gc is no longer available -- or, rather, that it is now core.memory? Is there a reason why this page exists, and has a link in the sidebar? http://www.digitalmars.com/d/2.0/phobos/std_gc.html (Yes, the documentation is for core.memory, but the page name/link name is std.gc. Also, there's no core.memory link in the sidebar...) -- Magnus Lie Hetland http://hetland.org
Re: Growable BinaryHeap: use w/Array?
On 2011-03-06 14:37:19 +0100, Magnus Lie Hetland said: Just wondering: If I want a growable binary heap (I'd be open to other priority queue structures, for that matter ;), is the standard way in D (w/Phobos) to combine std.container.BinaryHeap with std.container.Array? Another thing ... when I use priority queues, I'm usually not interested in just having a set of priorities -- the payload data is what it's all about. So I thought I'd just use an Array of Tuples, managed by BinaryHeap (possibly with a custom comparison, to avoid comparing the payloads). But perhaps that's not a good idea? When I try alias Tuple!(real,int) Entry; Array!Entry Q; that works just fine. However, if I try alias Tuple!(real,int) Entry; Array!Entry Q; then I get the following errors: container.d(1549): Error: this for _data needs to be type Array not type Payload container.d(1550): Error: this for _data needs to be type Array not type Payload container.d(1551): Error: this for _data needs to be type Array not type Payload It seems the lines that are being referred to are GC.removeRange(_data._payload.ptr); free(_data._payload.ptr); _data._payload = newPayload; though I may be wrong about that. Is this a bug in Array? Am I using it wrong? And what would be the recommended best practice for a priority queue with payload data in D (using Phobos)? (I could just write one myself, but that seems sort of wasteful ;) -- Magnus Lie Hetland http://hetland.org
Re: Growable BinaryHeap: use w/Array?
On 3/6/11 2:58 PM, Magnus Lie Hetland wrote: alias Tuple!(real,int) Entry; Array!Entry Q; […] alias Tuple!(real,int) Entry; Array!Entry Q; Is it just me, or is there really no difference between the two snippets? ;) David
Re: Growable BinaryHeap: use w/Array?
On 2011-03-06 15:00:29 +0100, David Nadlinger said: On 3/6/11 2:58 PM, Magnus Lie Hetland wrote: alias Tuple!(real,int) Entry; Array!Entry Q; [...] alias Tuple!(real,int) Entry; Array!Entry Q; Is it just me, or is there really no difference between the two snippets? ;) $(WITTY_REPLY) ;-) The one that fails should have string (or some other reference type, perhaps) rather than int. Copy/paste fail :D -- Magnus Lie Hetland http://hetland.org
dmd gdc in archlinux
i can't install dmd or gdc in arch linux from AUR i don't way?
Re: in/out with -release
user@domain.invalid Wrote: I still think I would like it if you could be a little more explicit about the in/out blocks. Are they always disabled entirely (skipped) with -release, or just certain things? Thanks for your help! -Kai Meyer By definition, if a pre contract fails, then the body received bad parameters. An AssertError is thrown. If a post contract fails, then there is a bug in the body. An AssertError is thrown. http://www.digitalmars.com/d/2.0/dbc.html
Re: dmd gdc in archlinux
%u wrote: i can't install dmd or gdc in arch linux from AUR i don't way? For gdc, which package exactly are you trying to install? On what platform (32 or 64 bits)? And what error do you get? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
No case ranges in final switches?
Do you know why final switches disallow case ranges? Case ranges are not
bug-prone:
void main() {
ubyte u;
final switch (u) {
case 0: .. case 100:
break;
case 101: .. case 255:
break;
}
}
DMD 2.052 gives the errors:
test.d(4): Error: case ranges not allowed in final switch
test.d(6): Error: case ranges not allowed in final switch
Thank you and bye,
bearophile
Static Associative Array
Can you define an associative array in a way that can be evaluated at compile time like you can with non-associative arrays?
Re: dmd gdc in archlinux
in dmd: this the error massage object.d: Error: module object is in file 'object.d' which cannot be read import path[0] = /usr/include/d import path[1] = /usr/include/d/druntime/import in gdc: i can't install it and i use this command yaourt -R gdc
Re: std.gc doc page
On Sunday 06 March 2011 05:39:14 Magnus Lie Hetland wrote: It seems std.gc is no longer available -- or, rather, that it is now core.memory? Is there a reason why this page exists, and has a link in the sidebar? http://www.digitalmars.com/d/2.0/phobos/std_gc.html (Yes, the documentation is for core.memory, but the page name/link name is std.gc. Also, there's no core.memory link in the sidebar...) The site probably just needs to be adjusted. You can open a bug report on it: http://d.puremagic.com/issues/enter_bug.cgi There are several modules which used to be in Phobos (std) which were moved to druntime (core), and the online docs have not been quick to change. - Jonathan M Davis
Re: Static Associative Array
Jonathan M Davis:
I'm pretty sure not. I think that it's currently suffering the same fate as
stuff
like classes and is not yet able to be CTFEed. Some day...
This works:
import std.stdio;
string foo(int x) {
auto aa = [1: hello, 2: red];
return aa[x];
}
enum string s = foo(1);
void main() {
writeln(s);
}
Bye,
bearophile
Re: Static Associative Array
What about:
enum : string[int]
{
aa = [1: blue, 2: red]
}
enum string s = aa[1];
void main()
{
writeln(s);
}
Re: Static Associative Array
On Sunday 06 March 2011 16:30:00 Andrej Mitrovic wrote:
What about:
enum : string[int]
{
aa = [1: blue, 2: red]
}
enum string s = aa[1];
void main()
{
writeln(s);
}
In both cases, the AA does not exist past compile time. That may be why it
works.
- Jonathan M Davis
Re: Win7 64-bit
On 01/03/2011 23:19, Dan McLeran wrote: never mind, i got it. i had to pass the switches: -D -unittest -cov life is hard. it's even harder when you're dumb. Would you care to enlighten the rest of us on what code you were using that requires those extra switches? Stewart.
Re: Win7 64-bit
On Sunday 06 March 2011 17:48:12 Stewart Gordon wrote: On 01/03/2011 23:19, Dan McLeran wrote: never mind, i got it. i had to pass the switches: -D -unittest -cov life is hard. it's even harder when you're dumb. Would you care to enlighten the rest of us on what code you were using that requires those extra switches? Yeah. That's weird. If you want to run the unit tests, you use -unittest. If you want code coverage, you use -unittest and -cov. If you want documentation, you use -D, but it has no relation to -unittest and -cov, and it isn't necessarily a good idea to build your code with -D normally because of the effects that version(D_Ddoc) could have on your code, and there are a number places in druntime and Phobos which won't result in valid code if you build with -D (until it's fixed in the next release so that druntime and Phobos' documentation is versioned with version(StdDoc) instead). So, _needing_ all three of those flags seems just plain wrong. If you're using -cov, you probably want -unittest, but -D has no relation to the others and shouldn't be necessary for _anything_ other than generating documentation. - Jonathan M Davis
Re: Static Associative Array
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote: Can you define an associative array in a way that can be evaluated at compile time like you can with non-associative arrays? I'm pretty sure not. I think that it's currently suffering the same fate as stuff like classes and is not yet able to be CTFEed. Some day... - Jonathan M Davis If not, then what is the D way to initialize a static field of a struct or class a la Java's static initializer blocks? I don't mind constructing the associative array at run-time if I have to, but I can't afford to do it more than the once needed.
Re: Static Associative Array
Peter Lundgren:
If not, then what is the D way to initialize a static field of a struct or
class a
la Java's static initializer blocks? I don't mind constructing the associative
array at run-time if I have to, but I can't afford to do it more than the
once needed.
Is this good enough?
struct Foo {
static int[int] aa;
static this() {
aa[0] = 1;
}
}
void main() {
assert(Foo.aa[0] == 1);
}
Bye,
bearophile
Re: No case ranges in final switches?
On 3/6/2011 1:11 PM, bearophile wrote:
Do you know why final switches disallow case ranges? Case ranges are not
bug-prone:
void main() {
ubyte u;
final switch (u) {
case 0: .. case 100:
break;
case 101: .. case 255:
break;
}
}
Final switch is really just meant to be used with enums; since
enumeration values don't have to cover the whole range of possible base
type values, and enumeration values don't often have a natural ordering,
ranges make little sense there.
Re: Static Associative Array
On 3/7/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Kidding, just kidding..
Re: No case ranges in final switches?
On Sunday 06 March 2011 18:26:26 Bekenn wrote:
On 3/6/2011 1:11 PM, bearophile wrote:
Do you know why final switches disallow case ranges? Case ranges are not
bug-prone:
void main() {
ubyte u;
final switch (u) {
case 0: .. case 100:
break;
case 101: .. case 255:
break;
}
}
Final switch is really just meant to be used with enums; since
enumeration values don't have to cover the whole range of possible base
type values, and enumeration values don't often have a natural ordering,
ranges make little sense there.
Yeah. While I can see how you might want to use a final switch here, final
switches were really intended for enums, and I'm not sure that they really work
properly with anything else (I'm not even sure that they work properly with
enums - IIRC last time I tried to use one, it didn't enforce anything;
hopefully
that's changed by now though).
- Jonathan M Davis
Re: Static Associative Array
On Sunday 06 March 2011 18:33:04 Andrej Mitrovic wrote: On 3/7/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Kidding, just kidding.. That _did_ seem like a rather rude post for you... - Jonathan M Davis
Benchmarking with -profile
How do you guys benchmark your D code? I tried using the -profile option, but was surprised to see wildly varying results (greater than an order of magnitude difference in Func Time) from one run to the next.
Re: No case ranges in final switches?
On Sunday 06 March 2011 18:51:04 bearophile wrote:
Bekenn:
Final switch is really just meant to be used with enums; since
enumeration values don't have to cover the whole range of possible base
type values, and enumeration values don't often have a natural ordering,
ranges make little sense there.
Thank you for your answer.
If something doesn't have an ordering, then it's right to disallow the case
range on it. But I'd like to be able to use case ranges in safer final
switches on bytes/ubytes/chars.
-
Jonathan M Davis:
Yeah. While I can see how you might want to use a final switch here, final
switches were really intended for enums,
You often say that language features must pull their weight. Artificially
restricting the usability of final switches to just enums makes them not
pull their weight.
There are times when I'd like to do this, but DMD is buggy here (I don't
remember if I have already put this in Bugzilla):
void main() {
int x = 100;
final switch (x % 3) {
case 0: /*...*/ break;
case 1: /*...*/ break;
}
}
I would say that it's actually fairly rare for you to even be _able_ to have a
specific set of values which you could limit a final switch statement to. enum
is
the obvious case. Not only do you have a fixed set of values which the could be
covered in by the case statements, but it's almost always buggy when you miss
some. It's highly abnormal to want to have a case for each value of a byte or
an
integer or whatever. And while it's easy for a human to see that your example
can only result in the values 0, 1, and 2, I'm not sure that it's so easy for
the computer. Certainly, it would have to special case % and restrict it to
primitive integral types.
I expect that it would complicate final switch quite a bit to deal with
anything
other than enums, particularly since I don't think that that can really be
generalized. I expect that final switch over enums is actually quite simple to
implement. So, whether the additional complexity is worth what is likely a very
rare thing to do for most programmers is debatable.
As for pulling it's weight, I must definitely think that final switch pulls its
weight for enums, just like disallowing ; as the body of a loop or conditional
statement pulls its weight. It's a very simple feature which fixes a common set
of bugs.
If final switch could be reasonably expanded to cover more than enums, it may
be
worth it, but if it doesn't do that already, I question that it's worth it.
Before you mentioned it, it certainly never occurred to me that anyone would
want to. I've never seen anyone try to. The feature is sold completely on the
idea of fixing bugs with missing cases for enums in switch statements. And that
is _well_ worth it IMHO.
If final switch doesn't do more than enums, and you think that it should, then
by
all means open up an enhancement request with suitable use cases as to why it
would be useful, but I wouldn't expect it to be implemented. It seems to me
that
it would be complicating the implementation of final switch for minimal
benefit.
But it's not my decision to make anyway. It's Walter's.
Now, if final switch actually compiles with anything other than an enum, then
it
needs to either stop compiling for anything which isn't an enum, or it needs to
start working for non-enums, but I don't think that it was really intended to
work for anything other than enums.
- Jonathan M Davis
Re: Static Associative Array
On 03/07/2011 03:22 AM, Peter Lundgren wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote:
Can you define an associative array in a way that can be evaluated at
compile time like you can with non-associative arrays?
I'm pretty sure not. I think that it's currently suffering the same fate as
stuff
like classes and is not yet able to be CTFEed. Some day...
- Jonathan M Davis
If not, then what is the D way to initialize a static field of a struct or
class a
la Java's static initializer blocks? I don't mind constructing the associative
array at run-time if I have to, but I can't afford to do it more than the once
needed.
Use the module's static this () {...} clause:
int[string] aa;
static this () { aa = [a:1, b:2, c:3]; }
unittest {
foreach (k,v ; aa)
writefln(%s -- %s, k,v);
}
Note: you can have as many such ckauses as you like.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: dmd gdc in archlinux
== Quote from %u (asm...@hotmail.com)'s article i can't install it and i use this command yaourt -R gdc i mean yaourt -S gdc
