Re: declaration with typedef
== Quote from Stanislav Blinov (stanislav.bli...@gmail.com)'s article
> On 12/27/2010 06:41 PM, Hamad Mohammad wrote:
> >> If you tried to assign person2 to person1 or vice versa
> >
> > how?
> >
> I don't think I got what David meant with it either. Assigning instances
> of the same type is perfectly valid as long as you do not define some
> very peculiar opAssign.
> Andrej, on the other hand, made a perfect point.
> A typedef is deprecated in D2. typedef in D2 differs from C/C++ one.
> What typedef does (in the old, D1 way) is introducing a new, distinct
> type. Many D constructs, especially templates, can handle only certain
> types. Those, depending on conditions, may or may not include
> user-defined types.
> writeln requires that a given value is 'formattable' to string. It knows
> how to deal with numerics, strings, arrays, structs and classes. But it
> does not put out assumptions on unknown types (and typedef'd type is
> "unknown" to D's type system). There are some ways to "introduce" your
> types to certain constructs. For example, if you do
> writeln(person1) in your code, you'll get "Human" on the console - this
> is a default way writeln handles structs. But if you define a method
> "toString" for your Human struct, e.g:
> import std.conv;
> struct Human
> {
> //...
> string toString()
> {
> return text(name, ": ", age);
> }
> }
> , then writeln(person1) would output ': 12' to the console.
> (Mind that this 'toString' idiom may change, which is the effect of
> recent discussions about this certain topic).
> Generally, if you want a "distinct" type in D2, define a struct (or a
> class if you want your type to have reference semantics). If you want a
> simple alias to existing type, use "alias" declaration (alias is an
> analog of C/C++ typedef, though the keyword itself does more than this.
> You can find out additional uses in documentaion or "The D Programming
> Language" book).
> At this point, language gurus should start throwing rotten tomatoes at
> my general location, but I tried to explain the thing in the easiest way
> I could.
thanks
Re: declaration with typedef
On 12/28/10 2:09 AM, Stanislav Blinov wrote:
I don't think I got what David meant with it either. Assigning instances
of the same type is perfectly valid as long as you do not define some
very peculiar opAssign.
The point here is that person1 and person2 are not instances of the same
type, try compiling the following snippet:
---
struct Human {
string name;
int age;
}
void main() {
Human person1;
typedef Human Mankind;
Mankind person2 = person1;
}
---
This might not be what Hamad wanted to know when he asked »but why that
code works«, but I could think of no other reason why the snipped he
posted should fail to compile.
David
Re: declaration with typedef
28.12.2010 20:42, David Nadlinger пишет:
On 12/28/10 2:09 AM, Stanislav Blinov wrote:
I don't think I got what David meant with it either. Assigning instances
of the same type is perfectly valid as long as you do not define some
very peculiar opAssign.
The point here is that person1 and person2 are not instances of the
same type, try compiling the following snippet:
---
struct Human {
string name;
int age;
}
void main() {
Human person1;
typedef Human Mankind;
Mankind person2 = person1;
}
---
Oh, right, I missed that one, sorry.
This might not be what Hamad wanted to know when he asked »but why
that code works«, but I could think of no other reason why the snipped
he posted should fail to compile.
Yes, the original snippet should compile fine because typedef'd type
isn't actually used in any way except for accessing fields, which of
course have built-in types.
Re: abstract function templates
Andrej Mitrovic wrote:
> I think this is relevant:
> http://www.digitalmars.com/d/2.0/template.html : "Limitations":
>
> Templates cannot be used to add non-static members or virtual
> functions to classes.
> Templates cannot add functions to interfaces.
>
> But I'm a little confused as to how it all works out. This will work:
>
> import std.stdio;
>
> class Foo
> {
> void draw(T)(T t) { writeln("Foo"); };
> }
>
> class Bar : Foo
> {
> /* override */ void draw(T)(T t) { writeln("Bar"); };
> }
Bar.draw does not override, but "hide" Foo.draw. They are unrelated
functions.
> void main()
> {
> Bar bar = new Bar();
> bar.draw(1); // "Bar"
Bar.draw!int is called. No virtual dispatch is involved, as Foo.draw!int
doesn't even exist.
> (cast(Foo)bar).draw(1); // "Foo"
Now Foo.draw!int is instantiated (at compile time) an is called. There
is no Bar.draw!int instantiated at all.
> }
>
> But uncomment the override and it fails.
That's because "Templates cannot be used to add [...] virtual functions
to classes"
Ali
Re: abstract function templates
Thanks, Ali! :)
Re: abstract function templates
Ali Ãehreli: > > But uncomment the override and it fails. > > That's because "Templates cannot be used to add [...] virtual functions > to classes" But the error messages given by DMD 2.051 aren't easy to understand for me: test.d(10): Error: variable test.Bar.draw!(int).draw.this override cannot be applied to variable test.d(10): Error: variable test.Bar.draw!(int).draw.t override cannot be applied to variable Bye, bearophile
Re: abstract function templates
On 12/28/10, bearophile wrote: > But the error messages given by DMD 2.051 aren't easy to understand for me: > > test.d(10): Error: variable test.Bar.draw!(int).draw.this override cannot be > applied to variable > test.d(10): Error: variable test.Bar.draw!(int).draw.t override cannot be > applied to variable Agreed. Can you file a bug report?
Re: abstract function templates
Andrej Mitrovic: > Agreed. Can you file a bug report? Sorry, but I don't understand the topic enough yet (I don't know why templated methods can't be virtual), so I leave the bug report to someone else that's able to write something meaningful in the bug report :-) Bye, bearophile
slist insertion
why does SList.insertFront have a complexity of O(log(n)) ?
Re: slist insertion
Ellery Newcomer wrote: why does SList.insertFront have a complexity of O(log(n)) ? Good question! It certainly is not the code's fault, as that's O(1) for single elements and O(m) for ranges. File it to Bugzilly, I guess. -- Simen
gaming pointers
I know this is just playing dangerous, still tempting to use for things like
plugins ,"member interfaces" or even struct interfaces.
It is easy to do without unions because delegates have ptr and funcptr pointers
with just a swap of pointers.
Are .ptr and .funcptr really needed to be writeable?
"could be a warning" (:
Here a example (note that the union it is used only to pretty print)
module gccmembug;
import std.stdio;
union dlgtrick(T){
void delegate() aptr;
struct{
T* cptr;
void* mptr;
}
}
class bypassing{
private int x;
void outx(){writeln(x);}
}
class dump{
int x;
void changex(){
x +=2;
}
}
void gamingboard(){
dump tool = new dump();
bypassing instance = new bypassing();
dlgtrick!bypassing drill;
drill.aptr = &instance.outx;
writeln("real bypassing \t",drill.cptr," ",drill.mptr);
drill.aptr = &tool.changex;
writeln("real tool \t",drill.cptr," ",drill.mptr);
drill.aptr.ptr = (&instance.outx).ptr;
writeln("faked \t",drill.cptr," ",drill.mptr);
writeln("original function called : ");
instance.outx();
writeln("hacked version called :");
drill.aptr();
instance.outx();
}
Excuse my if I maade something obvious or silly.
Thanks g.
Re: abstract function templates
bearophile wrote: > (I don't know why templated methods can't be virtual), so I leave the bug report to someone else that's able to write something meaningful in the bug report :-) I created a bug report just about the compiler error message: http://d.puremagic.com/issues/show_bug.cgi?id=5387 I think the compiler rejects the code according to spec. Ali
Re: abstract function templates
bearophile wrote: (I don't know why templated methods can't be virtual) First of all, they can. But it's a shitload of extra work, and requires that compilation be mixed up with linking. Whenever a templated method is used from any subclass, it has to be generated for the base class, and any and all subclasses that override it. We can't know every subclass until link-time (not even then, given dynamic linking). -- Simen
