Re: Problem with receiveOnly and classes
On 3/25/12 19:33 , Ghislain wrote: Hello, [...] I do not understand why an object of type A is fetched as a Variant, while a object of type B is received correctly. [...] Any idea? Hi! I get the same on Mac DMD 2.058. I have no idea. Looks like a bug to me, although I can't say which part is wrong/right. The chapter on concurrency in TDPL ( http://www.informit.com/articles/article.aspx?p=1609144seqNum=6 ) only ever uses values and arrays as examples, and ddocs sort of strategically says nothing, so I guess it's not really clear if passing objects should be possible at all? Either way, I once tried to pass over ownership of trees of objects to other threads but gave up on that. I don't think std.concurrency and D really can work like that. (?) Concurrency seems to work much better when you pass messages and data, structs are fine, and then build object trees from that on the other side etc. Sorry I can't help more.
Re: Compiling DMD on MAC OS X
On 2/19/12 09:20 , Tyro[a.c.edwards] wrote: Hi all, I've just installed DMD 2.058 and attempted to compile a little script but was greeted with the following error: gcc: Invalid argument I used the .dmg installer from http://www.dlang.org/download.html and issued the command: dmd average Is there something I'm missing? Thanks, Andrew Hi! Could you try dmd -v avarage and tell us what comes out? Also, how does avarage.d look? Also what does uname -a and gcc --version say? Also, just in case which dmd
Let this() figure out T implicitly?
Hi!
This doesn't work:
import std.stdio;
class Foo(T)
{
T t;
this(T val)
{
t = val;
}
}
void main()
{
auto o = new Foo(5);
}
_
$ dmd foo
foo.d(13): Error: class foo.Foo(T) is used as a type
$ _
So I must
auto o = new Foo!(int)(5);
Then it compiles. Is it possible to have this() figure out the type some
way? (In this particular example it's perhaps not such a big deal. But
imagine a lot more args.)
(Side note: What _does_ that error message mean? I don't get it.)
thanks
/krbrn
Re: Let this() figure out T implicitly?
On 2/17/12 1:32 PM, bearophile wrote:
kraybourne:
Then it compiles. Is it possible to have this() figure out the type some
way?
Usually people write a small global function helper.
Hm, so, something like this:
Foo!(T) newFoo(T)(T val)
{
return new Foo!(T)(val);
}
...
auto o = newFoo(5);
Works! Ha! How silly.
Thanks!
(Side note: What _does_ that error message mean? I don't get it.)
I think the meaning is: when a class template is not yet instantiated, it's not
a type yet.
Bye,
bearophile
Re: Let this() figure out T implicitly?
On 2/17/12 1:51 PM, Kevin Cox wrote:
The error message is saying that you are trying to use Foo as a type but
Foo is not a type, it is a template for a type.
Ah, so module.Foo is really not a class, but a template? I think I get
it! Thanks!
(Is then module.Foo(int).Foo the actual class type? I think I've seen
errors like that pop up...)
On Feb 17, 2012 7:20 AM, kraybourne st...@kraybourne.com
mailto:st...@kraybourne.com wrote:
Hi!
This doesn't work:
import std.stdio;
class Foo(T)
{
T t;
this(T val)
{
t = val;
}
}
void main()
{
auto o = new Foo(5);
}
_
$ dmd foo
foo.d(13): Error: class foo.Foo(T) is used as a type
$ _
So I must
auto o = new Foo!(int)(5);
Then it compiles. Is it possible to have this() figure out the type
some way? (In this particular example it's perhaps not such a big
deal. But imagine a lot more args.)
(Side note: What _does_ that error message mean? I don't get it.)
thanks
/krbrn
Re: Let this() figure out T implicitly?
On 2/17/12 2:38 PM, Timon Gehr wrote:
On 02/17/2012 02:07 PM, Kevin Cox wrote:
Yes. At least as the compiler would say. It's a little odd but I
believe that is how the D Nam mangling works. I personally just think
of Foo!(Class) as the type.
class Foo(T){ ... }
Is syntactic sugar for
template Foo(T){
class Foo{ ... }
}
Therefore the type is Foo!(Class).Foo.
Aaah, I see, clever, thx
I'd prefer the compiler to output
Foo!(Class) in error messages and for .stringof though, vote here:
http://d.puremagic.com/issues/show_bug.cgi?id=7064
