Argument S to typeof is not an expression
template Test(alias N)
if (isIntegral!(typeof(N)))
{
struct S
{
typeof(N) n = N;
auto opAdd(T)(T rhs)
{
//Error: argument S to typeof is not an expression
pragma(msg, typeof(T));
//Error: variable rhs cannot be read at compile time
return Test!(n + rhs.n);
}
}
auto st = S(N);
alias Test = st;
}
void main()
{
auto a = Test!2;
auto b = Test!3;
writeln(typeof(a).stringof ~ " a = ", a, ", ",
typeof(b).stringof ~ " b = ", b, ", ",
typeof(a + b).stringof ~ " a + b = ");
}
I don't really understand why either of these error messages are
occurring. The first is just incomprehensible, and the second
seems like it should work. In this case, rhs is fully accessible
at compile time in the expression (a + b), so why does the
compiler complain?
Re: Dispatching values to handlers, as in std.concurrency
On Tuesday, 7 May 2013 at 00:15:06 UTC, Luís Marques wrote:
On Monday, 6 May 2013 at 23:53:51 UTC, Idan Arye wrote:
If the type handlers are your own classes, then you can let
them check it. Have a method in the handlers that check if an
object can be handled by that handler, and use it on each
handler until you find one that fits.
I don't understand. Imagine I have:
class X
{
void handleFoo(Foo msg) { ... }
void handleBar(Bar msg) { ... }
}
I want to register an instance of X to receive messages of type
Foo (or subclass) and messages of type Bar (or subclass) in the
respective handler methods. Where are you proposing for your
check to be implemented?
I assume that `typeHandler` in your original code is *not* of
type `X` - since it has a single `handler` method while `X` has
two, with different names. That means that at some point, you had
to create it - let's assume it's type is called `TypeHandler`.
There is either a global function, static method, or constructor
where you create a `TypeHandler` and pass to it the delegate you
want to register.
Now, if that function/method/constructor is templated - than you
already have at compile time the type you want to handle, so you
can prepare the check there(anon function?)
If it's not templated - make it templated! You don't have to make
the entire `TypeHanler` templated, just the method that creates
it. There, you can create an anonymous function that receives
`Object` and returns `bool` and all it does is check for type,
and you can have a field in `TypeHandler` that keeps that
function and uses it to check if it can handle a certain type.
Re: Compiler error
07.05.2013 8:55, Alexandr Druzhinin пишет: 07.05.2013 1:40, Maxim Fomin пишет: On Monday, 6 May 2013 at 17:48:58 UTC, Alexandr Druzhinin wrote: 07.05.2013 0:39, Maxim Fomin пишет: On Monday, 6 May 2013 at 16:37:18 UTC, Alexandr Druzhinin wrote: during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this? 1) search or report to bugzilla 2) debug dmd 3) fix sources 4) prepare pull request Честно сказать, я не в курсе как искать в багзилле - все баги такие разные. Думал, тут все за меня сейчас решат. ;) Понял, будем работать... понятно :) Issue 8612 and 8710 looks like your case. Please post there your reduced code. http://d.puremagic.com/issues/show_bug.cgi?id=8612 it looks like 8612 but unfortunatly I found that the error appearance depends on command line arguments - if I compile the file with "reduced code" without other files of the project it compiles, but with the files - it fails. :( I forgot to mention that the these other files don't need for the reduced code compiling, but nevertheless bug is affected by these files.
Re: Compiler error
07.05.2013 1:40, Maxim Fomin пишет: On Monday, 6 May 2013 at 17:48:58 UTC, Alexandr Druzhinin wrote: 07.05.2013 0:39, Maxim Fomin пишет: On Monday, 6 May 2013 at 16:37:18 UTC, Alexandr Druzhinin wrote: during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this? 1) search or report to bugzilla 2) debug dmd 3) fix sources 4) prepare pull request Честно сказать, я не в курсе как искать в багзилле - все баги такие разные. Думал, тут все за меня сейчас решат. ;) Понял, будем работать... понятно :) Issue 8612 and 8710 looks like your case. Please post there your reduced code. http://d.puremagic.com/issues/show_bug.cgi?id=8612 it looks like 8612 but unfortunatly I found that the error appearance depends on command line arguments - if I compile the file with "reduced code" without other files of the project it compiles, but with the files - it fails. :(
Re: Dispatching values to handlers, as in std.concurrency
On Monday, 6 May 2013 at 23:48:11 UTC, Sean Kelly wrote: How are the messages stored? std.concurrency uses Variant.convertsTo. I had looked at Variant.convertsTo but (IIRC) it accepts a type (not a TypeInfo) and in my design I no longer had the type avaliable in the place where I would use the convertsTo, only the TypeInfo. I dispatch my messages as they come, so I don't store them. I only store the handler info, in the format Tuple!(TypeInfo, handler).
Re: Dispatching values to handlers, as in std.concurrency
On Monday, 6 May 2013 at 23:53:51 UTC, Idan Arye wrote:
If the type handlers are your own classes, then you can let
them check it. Have a method in the handlers that check if an
object can be handled by that handler, and use it on each
handler until you find one that fits.
I don't understand. Imagine I have:
class X
{
void handleFoo(Foo msg) { ... }
void handleBar(Bar msg) { ... }
}
I want to register an instance of X to receive messages of type
Foo (or subclass) and messages of type Bar (or subclass) in the
respective handler methods. Where are you proposing for your
check to be implemented?
Re: Dispatching values to handlers, as in std.concurrency
On Monday, 6 May 2013 at 21:26:03 UTC, Luís Marques wrote: On Monday, 6 May 2013 at 21:20:49 UTC, Idan Arye wrote: BTW, for this to work `typeHandler.type` needs to be known at compile-time. That's the rub. This list of handler is dynamic, so `typeHandler.type` is a TypeInfo, not a compile-time type. If the type handlers are your own classes, then you can let them check it. Have a method in the handlers that check if an object can be handled by that handler, and use it on each handler until you find one that fits.
Re: Dispatching values to handlers, as in std.concurrency
On May 6, 2013, at 10:03 AM, "Luís.Marques" "@puremagic.com wrote: > > How can I also accept subclasses? How are the messages stored? std.concurrency uses Variant.convertsTo.
Re: WinAPI callbacks and GC
On May 2, 2013, at 6:17 AM, Regan Heath wrote: > On Wed, 01 May 2013 01:12:39 +0100, Sean Kelly wrote: > >> On Apr 23, 2013, at 2:21 PM, Jack Applegame wrote: >>> >>> According WinAPI documentation, CtrlHandler will be called in new >>> additional thread. Is it safe to allocate GC memory in NOT Phobos threads? >>> If not, how to make it safe? I'm trying call thread_attachThis() at the >>> beginning of CtrlHandler fucntion, but it doesn't compile because >>> thread_attachThis() is not no throw. >> >> >> thread_attachThis should probably just be labeled nothrow. I don't think >> there's anything in that function that can throw an Exception. > > That makes it callable.. but did you see my post about the various timing > issues with using this in a non-GC thread (potentially while the GC is > already collecting - or similar). The GC holds a lock on the global thread list while collecting, so it shouldn't be possible for thread_attachThis to register a thread when this is happening. In fact, thread_attachThis even temporarily disables the GC, and since this operation is protected by the GC lock, it's blocked there as well.
Re: Dispatching values to handlers, as in std.concurrency
On Monday, 6 May 2013 at 21:20:49 UTC, Idan Arye wrote: BTW, for this to work `typeHandler.type` needs to be known at compile-time. That's the rub. This list of handler is dynamic, so `typeHandler.type` is a TypeInfo, not a compile-time type.
Re: Dispatching values to handlers, as in std.concurrency
On Monday, 6 May 2013 at 17:03:20 UTC, Luís Marques wrote:
I have a list of functions which receive values of different
types, like in std.concurrency...
// example from std.concurrency
receive(
(int i) { writeln("Received the number ", i);}
);
...although in my case I can probably live by with only
accepting objects.
I built a list of the handlers and the message classes they
accept. My problem is that I don't know how to check if the
message I have to dispatch is of the class the handler accepts
*or a subclass*. I only managed to check for class equality:
if(typeid(msg) == typeHandler.type)
{
typeHandler.handler(msg);
}
How can I also accept subclasses?
Thanks,
Luís
Just cast it - http://dlang.org/expression.html#CastExpression
Casting object `foo` to type `Bar` will yield `null` if `foo` is
not an instance of a `Bar` or of a subclass of `Bar`.
This is particularly usefull combined with a declaration inside
an `if` statement:
if(auto castedObject = cast(typeHandler.type)msg)
{
typeHandler.handler(msg);
}
BTW, for this to work `typeHandler.type` needs to be known at
compile-time.
Re: Avoid initializing a struct field.
On Mon, 06 May 2013 15:01:42 -0400, jerro wrote: On Monday, 6 May 2013 at 15:15:47 UTC, Steven Schveighoffer wrote: Foo.init must exist, and be filled with *something*. Is it useful to FORCE buffer to not have 0 values? Or is it that you don't care what it has? In the latter, is it terrible that it's 0? I don't care what it contains, I just want to avoid initialization for performance reasons. The issue is that bar int in there. The compiler does not generate initialization code that sets up specific members. It basically has an init value, and it memcpy's that thing onto any uninitialized struct. If you want performance, initialize the memory (all of it) yourself. You can't do any worse :) -Steve
Re: Avoid initializing a struct field.
On Monday, 6 May 2013 at 15:15:47 UTC, Steven Schveighoffer wrote:
On Sat, 04 May 2013 14:11:02 -0400, jerro wrote:
Is there a way to avoid default initializing a struct field in
D? The following doesn't seem to work:
struct Foo
{
int[42] buffer = void;
int bar;
}
I know I can do this:
Foo foo = void
But then all fields are uninitialized.
Foo.init must exist, and be filled with *something*. Is it
useful to FORCE buffer to not have 0 values? Or is it that you
don't care what it has? In the latter, is it terrible that
it's 0?
I don't care what it contains, I just want to avoid
initialization for performance reasons. I have something like
this:
struct Foo(size_t maxNItems)
{
Item[maxNItems] buffer;
size_t nItems;
size_t addItem(...){ ... }
void processItems(...){...}
}
The user of Foo can add up to maxNItems items and then run some
algorithm on them. Now say that Foo needs to support up to, say,
a thousand items, but in most cases just a few of them will be
added. In this case default initialization can take way more time
than the actual algorithm.
Re: Compiler error
On Monday, 6 May 2013 at 17:48:58 UTC, Alexandr Druzhinin wrote: 07.05.2013 0:39, Maxim Fomin пишет: On Monday, 6 May 2013 at 16:37:18 UTC, Alexandr Druzhinin wrote: during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this? 1) search or report to bugzilla 2) debug dmd 3) fix sources 4) prepare pull request Честно сказать, я не в курсе как искать в багзилле - все баги такие разные. Думал, тут все за меня сейчас решат. ;) Понял, будем работать... понятно :) Issue 8612 and 8710 looks like your case. Please post there your reduced code. http://d.puremagic.com/issues/show_bug.cgi?id=8612
Re: Compiler error
07.05.2013 0:39, Maxim Fomin пишет: On Monday, 6 May 2013 at 16:37:18 UTC, Alexandr Druzhinin wrote: during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this? 1) search or report to bugzilla 2) debug dmd 3) fix sources 4) prepare pull request Честно сказать, я не в курсе как искать в багзилле - все баги такие разные. Думал, тут все за меня сейчас решат. ;) Понял, будем работать...
Re: Compiler error
On Monday, 6 May 2013 at 16:37:18 UTC, Alexandr Druzhinin wrote: during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this? 1) search or report to bugzilla 2) debug dmd 3) fix sources 4) prepare pull request
Dispatching values to handlers, as in std.concurrency
I have a list of functions which receive values of different
types, like in std.concurrency...
// example from std.concurrency
receive(
(int i) { writeln("Received the number ", i);}
);
...although in my case I can probably live by with only accepting
objects.
I built a list of the handlers and the message classes they
accept. My problem is that I don't know how to check if the
message I have to dispatch is of the class the handler accepts
*or a subclass*. I only managed to check for class equality:
if(typeid(msg) == typeHandler.type)
{
typeHandler.handler(msg);
}
How can I also accept subclasses?
Thanks,
Luís
Compiler error
during building I get: Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line 239 in file 'struct.c' abnormal program termination what should I do to help us to catch this?
Re: Avoid initializing a struct field.
On Sat, 04 May 2013 14:11:02 -0400, jerro wrote:
Is there a way to avoid default initializing a struct field in D? The
following doesn't seem to work:
struct Foo
{
int[42] buffer = void;
int bar;
}
I know I can do this:
Foo foo = void
But then all fields are uninitialized.
Foo.init must exist, and be filled with *something*. Is it useful to
FORCE buffer to not have 0 values? Or is it that you don't care what it
has? In the latter, is it terrible that it's 0?
I tend to think that without the bar there, it could potentially be
uninitialized (not sure if this is the case). But as long as it's there,
buffer must also be initialized.
-Steve
