fOn 04/27/2014 06:00 PM, David Held wrote:
> I would like to do something like this:
>
> Foo[Bar][Baz] nestedAA;
> auto innerAA = nestedAA[someBaz];
> innerAA[someBar] = someFoo;
> assert(someFoo in nestedAA[someBaz]);
in operator uses a key, not a value. This should work:
assert(someBar in
I am trying to figure out how to change the value of an element
in a BinaryHeap (from std.container) and have it repositioned
such that the heap is still valid.
Can anyone help me with this? The approach I would have taken (I
think) is to remove the elements that get new values from the
heap,
On Sunday, 27 April 2014 at 00:48:53 UTC, Ali Çehreli wrote:
I think the following is a start:
import std.variant;
class MyClass
{
Variant[string] store;
void attach(T)(string key, ref T var)
{
store[key] = &var;
}
void set(T)(string key, T value)
{
*s
I would like to do something like this:
Foo[Bar][Baz] nestedAA;
auto innerAA = nestedAA[someBaz];
innerAA[someBar] = someFoo;
assert(someFoo in nestedAA[someBaz]);
Unfortunately, this does not do what I would like, because innerAA
appears to be a copy rather than a reference. Is there a nice w
i wrote a module which public imports other modules (to avoid
importing 'em by hand, 'cause import lists depends on version()).
then i imported this 'main' module with renaming: import zmod =
my.module;
now i can't acces any identifiers from modules that my.module
public imports and i forced
If no one comment I'll put this in Bugzilla.
https://issues.dlang.org/show_bug.cgi?id=12667
Bye,
bearophile
Meta:
The more I try to use Algebraic, the more I come to think that
this is something that can't be done cleanly in a library, even
in D.
Algebraic is currently unfinished and needs improvements. If it
turns out it's not possible to implement it well in library code,
we can find the minima
On Sunday, 27 April 2014 at 20:54:02 UTC, bearophile wrote:
An Algebraic is a sum type, so you can't store two value in it,
only one, an int or a T*. But this is not going to solve your
problems...
Bye,
bearophile
Ah, you're right. I'm getting mixed up from my own initial
example. Fiddling
Meta:
I should specify. This did not work:
alias T = Algebraic!(int, This*);
void main() {
auto l = T(1, new T(2, new T(3, null)));
}
An Algebraic is a sum type, so you can't store two value in it,
only one, an int or a T*. But this is not going to solve your
problems...
Bye,
bea
On Sunday, 27 April 2014 at 20:28:28 UTC, bearophile wrote:
Meta:
alias List = Algebraic!(typeof(null), Cons!(int, This));
Also your Cons seems a value type, like Algebraic itself. You
have to avoid creating an infinite-size algebraic value.
Bye,
bearophile
Yes, it's hard to figure out A
On Sunday, 27 April 2014 at 20:38:37 UTC, Meta wrote:
Is it necessary to use This[]? I tried changing it to This* and
it blew up on me.
I should specify. This did not work:
alias T = Algebraic!(int, This*);
void main() {
auto l = T(1, new T(2, new T(3, null)));
}
On Sunday, 27 April 2014 at 20:22:12 UTC, bearophile wrote:
Meta:
I'm trying to create a basic List type using Algebraic, but
the compiler keeps complaining about recursive aliasing.
As stated in its docs, Algebraic is not yet finished and good
for recursive data structures. But here I have
Meta:
alias List = Algebraic!(typeof(null), Cons!(int, This));
Also your Cons seems a value type, like Algebraic itself. You
have to avoid creating an infinite-size algebraic value.
Bye,
bearophile
Meta:
I'm trying to create a basic List type using Algebraic, but the
compiler keeps complaining about recursive aliasing.
As stated in its docs, Algebraic is not yet finished and good for
recursive data structures. But here I have put an usage example
of that kind:
http://rosettacode.org/
I'm trying to create a basic List type using Algebraic, but the
compiler keeps complaining about recursive aliasing.
import std.variant;
struct Cons(T, U: List)
{
public static opCall(T t, U u)
{
}
}
//Error
alias List = Algebraic!(typeof(null), Cons!(int, This));
void
spec:
I usually try to refrain myself from opinionating on stuff
where i lack proper knowledge and i'am still a newbie with D
(contrary to you bearophile).
It's not just a matter of experience, when there are many
interacting parts it's also a matter of intelligence (and people
like Timon a
On Sunday, 27 April 2014 at 08:04:54 UTC, Andrej Mitrovic via
Digitalmars-d-learn wrote:
On 4/27/14, Damian Day via Digitalmars-d-learn
wrote:
So I have this procedure.
Have a look at std.exception.assumeWontThrow:
http://dlang.org/phobos/std_exception.html#.assumeWontThrow
Keep in mind tha
On Sunday, 27 April 2014 at 13:31:39 UTC, bearophile wrote:
Is it possible and a good idea to raise a compilation error in
such cases where code tries to use Bar static fields before bar
static this() has run? (But perhaps a more fine-grained error
is needed, that tracks single fields, to allow
Dicebot:
It happens because attribute inference does not work properly
on generated delegated for lazy argument. I think it is a bug
"lazy int x" is effectively same as "int delegate() x" and
@nogc states that you can only call other @nogc functions and
delegates from something annotated as
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
D doesn't like warnings, but it could be an error. This is
minimized code:
st
On Sunday, 27 April 2014 at 13:09:39 UTC, bearophile wrote:
Lazy arguments in general allocate, but who is to blame for the
allocation?
Isn't the allocation at the calling point?
This code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives:
test.d(
Lazy arguments in general allocate, but who is to blame for the
allocation?
Isn't the allocation at the calling point?
This code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives:
test.d(2,15): Error: @nogc function 'test.foo' cannot call
non-@nog
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
If you think this can be done and it's useful, then ask for this
enhancement requ
On Sunday, 27 April 2014 at 02:06:14 UTC, Ali Çehreli wrote:
I don't know whether the inconsistency is a bug but according
to documentation, static this inside a module are executed in
lexical order: "Static constructors within a module are
executed in the lexical order in which they appear."
Am 26.04.2014 20:18, schrieb Entry:
> I'd like to use GLFW from Deimos, but I couldn't get it to work (DMD
> said it cannot use libglfw.a) and I've read somewhere that only GDC can
> use these DLLs directly (with a D header, but that's still better than
> hooking the methods). So do I need GDC for
On 4/27/14, Damian Day via Digitalmars-d-learn
wrote:
> So I have this procedure.
Have a look at std.exception.assumeWontThrow:
http://dlang.org/phobos/std_exception.html#.assumeWontThrow
26 matches
Mail list logo