Member functions C to D

[Craig Kuhnert]

Hi
I am trying to convert some code I wrote in C++ to D to give it a try and I 
have come across some code that I dont know how to convert.
I have simplified the code to illustrate the problem I have.
How do I do this in D?

class IFieldSetter
{
public:
virtual void SetValue(void * object, const void * value) = 0;
};

template class C, class T
class FieldSetter : public IFieldSetter
{
private:
typedef T (C::* MemberField);
 MemberField field;

public:
FieldSetter(MemberField afield)
: field(afield)
{}

void SetTypedValue(C * object, const T value)
{
object-*field = value;
}

void SetValue(void * object, const void * value)
{
SetTypedValue((C*) object, (const T) value);
}
};

class MySampleClass
{
public:
int Status;
std::string Name;
};

void main(void)
{
IFieldSetter * StatusSetter = new 
FieldSetterMySampleClass,int(MySampleClass::Status);
IFieldSetter * NameSetter   = new 
FieldSetterMySampleClass,std::string(MySampleClass::Name);

MySampleClass * a = new MySampleClass();
MySampleClass * b = new MySampleClass();

StatusSetter-SetValue(a, (void*)20);
StatusSetter-SetValue(b, (void*)40);

NameSetter-SetValue(a, 2002);
NameSetter-SetValue(b, 2002);
}

Thanks
Craig

Re: Getting started - D meta-program question

[downs]

Justin Johansson wrote:
 Your code as below, using auto to declare a temporary var in an if statement, 
 ahh, nice,
 didn't know that.
 
  if (auto res = dg(current.data))
 return res;
 
 What other statement types can you generalized use of auto like this to?
 

Sadly, it's an if-specific syntax.

 Thank you for taking the time downs,
 
 -- Justin

Anytime.

Re: Member functions C to D

[Craig Kuhnert]

downs Wrote:

 Craig Kuhnert wrote:
  Hi
  I am trying to convert some code I wrote in C++ to D to give it a try and I 
  have come across some code that I dont know how to convert.
  I have simplified the code to illustrate the problem I have.
  How do I do this in D?
  
  class IFieldSetter
  {
  public:
  virtual void SetValue(void * object, const void * value) = 0;
  };
  
  template class C, class T
  class FieldSetter : public IFieldSetter
  {
  private:
  typedef T (C::* MemberField);
   MemberField field;
  
  public:
  FieldSetter(MemberField afield)
  : field(afield)
  {}
  
  void SetTypedValue(C * object, const T value)
  {
  object-*field = value;
  }
  
  void SetValue(void * object, const void * value)
  {
  SetTypedValue((C*) object, (const T) value);
  }
  };
  
  class MySampleClass
  {
  public:
  int Status;
  std::string Name;
  };
  
  void main(void)
  {
  IFieldSetter * StatusSetter = new 
  FieldSetterMySampleClass,int(MySampleClass::Status);
  IFieldSetter * NameSetter   = new 
  FieldSetterMySampleClass,std::string(MySampleClass::Name);
  
  MySampleClass * a = new MySampleClass();
  MySampleClass * b = new MySampleClass();
  
  StatusSetter-SetValue(a, (void*)20);
  StatusSetter-SetValue(b, (void*)40);
  
  NameSetter-SetValue(a, 2002);
  NameSetter-SetValue(b, 2002);
  }
  
  Thanks
  Craig
 
 If I'm getting this correctly, here's one way to do it ..
 
 module test;
 
 import std.stdio, tools.ctfe: ctReplace; // easy to write your own ctReplace 
 function
 
 template Init(T) { T Init; }
 
 interface IFieldSetter {
   void setValue(Object obj, void* value);
 }
 
 class FieldSetter(T: Object, string Name) : IFieldSetter {
   override void setValue(Object obj, void* value) {
 auto tee = cast(T) obj;
 mixin(tee.%NAME = *cast(typeof(tee.%NAME)*) value; .ctReplace(%NAME, 
 Name));
   }
   void setValue(T obj, typeof(mixin(Init!(T).~Name)) value) {
 mixin(obj.%NAME = value; .ctReplace(%NAME, Name));
   }
 }
 
 class Sample {
   int status;
   string name;
 }
 
 void main() {
   auto statSetter = new FieldSetter!(Sample, status);
   auto nameSetter = new FieldSetter!(Sample, name);
   auto sample = new Sample;
   int i = 20;
   statSetter.setValue(sample, i);
   statSetter.setValue(sample, 40);
   nameSetter.setValue(sample, Fooblr);
 }

Thanks
Thats brilliant! D rocks!
I never though of using mixin for that purpose.

Re: Member functions C to D

[Jarrett Billingsley]

On Wed, Oct 7, 2009 at 8:07 AM, Don nos...@nospam.com wrote:
 Craig Kuhnert wrote:

 downs Wrote:

 Craig Kuhnert wrote:

 Hi
 I am trying to convert some code I wrote in C++ to D to give it a try
 and I have come across some code that I dont know how to convert.
 I have simplified the code to illustrate the problem I have.
 How do I do this in D?

 class IFieldSetter
 {
 public:
        virtual void SetValue(void * object, const void * value) = 0;
 };

 template class C, class T
 class FieldSetter : public IFieldSetter
 {
 private:
        typedef T (C::* MemberField);
         MemberField field;

 public:
        FieldSetter(MemberField afield)
                : field(afield)
        {}

        void SetTypedValue(C * object, const T value)
        {
                object-*field = value;
        }

        void SetValue(void * object, const void * value)
        {
                SetTypedValue((C*) object, (const T) value);
        }
 };

 class MySampleClass
 {
 public:
        int Status;
        std::string Name;
 };

 void main(void)
 {
        IFieldSetter * StatusSetter = new
 FieldSetterMySampleClass,int(MySampleClass::Status);
        IFieldSetter * NameSetter   = new
 FieldSetterMySampleClass,std::string(MySampleClass::Name);

        MySampleClass * a = new MySampleClass();
        MySampleClass * b = new MySampleClass();

        StatusSetter-SetValue(a, (void*)20);
        StatusSetter-SetValue(b, (void*)40);

        NameSetter-SetValue(a, 2002);
        NameSetter-SetValue(b, 2002);
 }

 Thanks
 Craig

 If I'm getting this correctly, here's one way to do it ..

 module test;

 import std.stdio, tools.ctfe: ctReplace; // easy to write your own
 ctReplace function

 template Init(T) { T Init; }

 interface IFieldSetter {
  void setValue(Object obj, void* value);
 }

 class FieldSetter(T: Object, string Name) : IFieldSetter {
  override void setValue(Object obj, void* value) {
    auto tee = cast(T) obj;
    mixin(tee.%NAME = *cast(typeof(tee.%NAME)*) value;
 .ctReplace(%NAME, Name));
  }
  void setValue(T obj, typeof(mixin(Init!(T).~Name)) value) {
    mixin(obj.%NAME = value; .ctReplace(%NAME, Name));
  }
 }

 class Sample {
  int status;
  string name;
 }

 void main() {
  auto statSetter = new FieldSetter!(Sample, status);
  auto nameSetter = new FieldSetter!(Sample, name);
  auto sample = new Sample;
  int i = 20;
  statSetter.setValue(sample, i);
  statSetter.setValue(sample, 40);
  nameSetter.setValue(sample, Fooblr);
 }

 Thanks
 Thats brilliant! D rocks!
 I never though of using mixin for that purpose.

 There's almost NOTHING which is impossible with string mixins. With just
 recursive string mixins, coupled with .stringof and is(typeof()), you can
 get access to most of the compiler's semantic analysis, and its symbol
 table.
 Deep in the final semantic pass, just before code generation, when you have
 access to all the type information, you can generate new source code for the
 compiler to start again at the beginning with parsing.
 It's insanely powerful.

It's also insanely kludgy and ugly. Bleh.

How about macro == symbol for mixin statement? [was Re: Member functions C to D]

[Steven Schveighoffer]

On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley  
jarrett.billings...@gmail.com wrote:



It's also insanely kludgy and ugly. Bleh.


If all a macro did was translate a scoped normal symbol to a mixin (or  
other macro) statement, would this take care of the ugliness? (would also  
be an insanely simple solution)


i.e.

macro doit(x, y, z) mixin(x ~ y ~ z); // allow easy syntax for  
quoting parameters, since mixins are all about stringification.


doit(a, b, c) = mixin(abc);

Another example, logging:

class Logger
{
  ...
  macro logError(msg) mixin({if(this.level = ERROR)  
logMessage(this.level.Error, msg);});

}

usage:

log.logError(bad error occurred with object:  ~  
expensiveObjectStringification(obj));


No more lazy parameters, no more stupid delegates :)

-Steve

Get template and its instantiation parameters

[Michal Minich]

If one has a template instance, is it possible to get template name and parameter 
type that was used for instantiating, at compile time?


consider:

class List (T) {}

List!(int) lst;
Foo (lst);

I want to create such template Foo which prints:
List!(int)
List
int

Something simiar for Arrays can be created:
int[char] x;
Foo (x);

template Foo (X : T[U], T, U)
{
   void Foo (X arr)
   {
   writeln(typeof(arr).stringof);
   writeln(T.stringof);
   writeln(U.stringof);
   }
}

but similar template for template instances does not work:
template Foo (X : T!(U), T, U) // does not matches List!(int)

when is changed to something more specific, it starts working:
template Foo (X : List!(U), U) // matches List!(int)

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]

[Don]

Steven Schveighoffer wrote:
On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley 
jarrett.billings...@gmail.com wrote:



It's also insanely kludgy and ugly. Bleh.


Ugly, yes. Kludgy, I don't think so. It's only a syntax issue. The basic 
concept of passing meta-code to the compiler in the form of raw text is 
simple:


mixin() if you want to insert something into the parse step.
 is(typeof()) if you want to catch it again after the syntax pass.
 stringof if you want to catch it again after the semantic pass.

And that's all. The syntax is ugly, but the semantics are beautifully 
elegant.


By contrast, something like Nemerle macros are a kludge. The idea of 
providing a 'hook' into the compiler is a horrible hack. It exposes all 
kinds of compiler internals. Yes, it has nicer syntax.


If all a macro did was translate a scoped normal symbol to a mixin (or 
other macro) statement, would this take care of the ugliness? (would 
also be an insanely simple solution)


I think that's where the majority of the ugliness comes from.

Re: Get template and its instantiation parameters

[Jarrett Billingsley]

On Wed, Oct 7, 2009 at 12:54 PM, BCS n...@anon.com wrote:
 Hello Michal,

 If one has a template instance, is it possible to get template name
 and parameter type that was used for instantiating, at compile time?

 consider:

 class List (T) {}

 List!(int) lst;
 Foo (lst);
 I want to create such template Foo which prints:
 List!(int)
 List
 int

 You could try parsing T.stringof at compiletime to extract the parts you
 need.

This is *exactly* the kind of bullshit that I hate about string
mixins. The thought process just ends up going oh, why bother having
any terse, elegant mechanisms to get at program information when you
can *parse arbitrary code at compile time*? And why do you need macros
when a string substitution will do? Is it powerful? Sure. But it's
lame, ugly, slow, easy to mess up, lacks hygiene, and is unidiomatic.
String mixins are basically just a text preprocessor with user-defined
functionality. Neat, but it can only get you so far before you're in
tarpit territory.

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]

[Jarrett Billingsley]

On Wed, Oct 7, 2009 at 11:21 AM, Don nos...@nospam.com wrote:
 Steven Schveighoffer wrote:

 On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley
 jarrett.billings...@gmail.com wrote:

 It's also insanely kludgy and ugly. Bleh.

 Ugly, yes. Kludgy, I don't think so. It's only a syntax issue. The basic
 concept of passing meta-code to the compiler in the form of raw text is
 simple:

 mixin() if you want to insert something into the parse step.
  is(typeof()) if you want to catch it again after the syntax pass.
  stringof if you want to catch it again after the semantic pass.

 And that's all. The syntax is ugly, but the semantics are beautifully
 elegant.

It'd be nice if they actually worked. is(typeof()) fails for *any*
error, and it eats those errors too, so if your code fails to compile
for some reason other than the one you're testing for, welp, good luck
figuring that out. And don't even get me started on .stringof.

Also, see my post on the get template and its instantiation
parameters thread for my detailed opinion on them.

 By contrast, something like Nemerle macros are a kludge. The idea of
 providing a 'hook' into the compiler is a horrible hack. It exposes all
 kinds of compiler internals. Yes, it has nicer syntax.

I.. don't even know how to begin to respond to that.

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]

[Bill Baxter]

 On Wed, Oct 7, 2009 at 11:21 AM, Don nos...@nospam.com wrote:

 By contrast, something like Nemerle macros are a kludge. The idea of
 providing a 'hook' into the compiler is a horrible hack. It exposes all
 kinds of compiler internals. Yes, it has nicer syntax.

Are you talking specifically about the ability to define new syntax?
Because it looks to me that one can use nemerle macros just fine
without defining new syntax.
I'm getting that from here: http://nemerle.org/Macros_tutorial

Here's just a simple macro that adds no new syntax from that page:

macro m () {
  Nemerle.IO.printf (compile-time\n);
  [ Nemerle.IO.printf (run-time\n) ];
}

module M {
  public Main () : void {
m ();
  }
}


That seems significantly more elegant to me than

string m() {
   pragma(msg, compile-time);
   return q{writefln(run-time);}
}
void main() {
   mixin(m());
}

So it looks to me like the mechanics of it are basically identical.
Just Nemerle's syntax is nicer.

If you want to condem Nemerle's ability to define new syntax, I think
that should be taken up as a separate matter.

--bb

Re: Get template and its instantiation parameters

[Michal Minich]

On Wed, 07 Oct 2009 13:15:46 -0400, Jarrett Billingsley wrote:

 On Wed, Oct 7, 2009 at 12:54 PM, BCS n...@anon.com wrote:
 Hello Michal,

 If one has a template instance, is it possible to get template name
 and parameter type that was used for instantiating, at compile time?

 consider:

 class List (T) {}

 List!(int) lst;
 Foo (lst);
 I want to create such template Foo which prints: List!(int)
 List
 int

 You could try parsing T.stringof at compiletime to extract the parts
 you need.
 
 This is *exactly* the kind of bullshit that I hate about string mixins.
 The thought process just ends up going oh, why bother having any terse,
 elegant mechanisms to get at program information when you can *parse
 arbitrary code at compile time*? And why do you need macros when a
 string substitution will do? Is it powerful? Sure. But it's lame, ugly,
 slow, easy to mess up, lacks hygiene, and is unidiomatic. String mixins
 are basically just a text preprocessor with user-defined functionality.
 Neat, but it can only get you so far before you're in tarpit territory.

Jarrett,

I agree with you except the lame and preprocessor part. But I 
wouldn't be so harsh on D. The prospect of parsing D code really does not 
appeal to me. Also the usage of advanced templates is not very intuitive. 
But please don't forget that features that are made possible by D 
templates and/or the .stringof + CTFE are not available in many 
languages. Languages that have such or better type level expressivity as 
D are few, mostly functional ones: Haskell, ML, OCaml, F# (I don't know 
of Scala). Also these features in D are more general, and even if kludgy, 
they are *available*.


The answer to my question is:

The problem was that parameter T needs to be alias because it should 
match List which is not complete type, until is applied to some 
argument (int); it is just template name. The result for T.stringof is 
surprising for me, but anyway, I get what I needed.

class List (T) {}

void main ()
{
List!(int) lst;
Foo (lst);
}


template Foo (C : T!(U), alias T, U)
{
void Foo (C container)
{
writeln(C.stringof); // List
writeln(T.stringof); // List(T)
writeln(U.stringof); // int
}
}

(tested on DMD 2.033)

Re: Get template and its instantiation parameters

[Christopher Wright]

BCS wrote:

Hello Michal,


If one has a template instance, is it possible to get template name
and parameter type that was used for instantiating, at compile time?

consider:

class List (T) {}

List!(int) lst;
Foo (lst);
I want to create such template Foo which prints:
List!(int)
List
int


You could try parsing T.stringof at compiletime to extract the parts you 
need.


No, you can't. You can try parsing demangle!(T.mangleof) at compiletime 
to extract the parts you need. stringof is a morass of inconsistency and 
partial information. Whenever a template gets within a mile of a type, 
all bets are off.

Re: Get template and its instantiation parameters

[BCS]

Hello Jarrett,


On Wed, Oct 7, 2009 at 12:54 PM, BCS n...@anon.com wrote:


You could try parsing T.stringof at compiletime to extract the parts
you need.


This is *exactly* the kind of bullshit that I hate about string
mixins.



The question was how to do somthing now. If the best solution isn't that 
good, it says a few things, but what it does /not/ say is that you shouldn't 
do the best solution.

std.socket again

[Sam Hu]

Greetings!

Is there anybody kindly write several pieces of code to demonstrate how to use 
socket in D2.Say ,just download the D main page and print the content in the 
console should be enough.

 I tried several days but still got lost.The sample accompany with DMD 2032/3 
does not work .

Thank you so much in advance.

Regards,
Sam

std.socket again

[Sam Hu]

Greetings!

Is there anybody kindly write several pieces of code to demonstrate how to use 
socket in D2.Say ,just download the D main page and print the content in the 
console should be enough.

 I tried several days but still got lost.The sample accompany with DMD 2032/3 
does not work .

Thank you so much in advance.

Regards,
Sam