Re: rehabilitating Juno
On 06/21/2014 06:40 AM, Jesse Phillips wrote: On Thursday, 19 June 2014 at 15:24:41 UTC, Jesse Phillips wrote: Once I get some examples compiling again in 32bit, it should be easier for you to play around with COM in D. I've pushed changes which get the library building and examples working. Let me know if there is any other direction I can provide. And if your curious you can check the commit history to see what changes where needed. https://github.com/JesseKPhillips/Juno-Windows-Class-Library This is great. I used Juno back in 2007 for working with Excel, and it worked great. Nice to see the library getting an update for D2. I remember seeing some slides on another COM library for D2 a while ago. Was that effort ever open-sourced?
Re: C structs
On 06/20/14 14:42, Dicebot via Digitalmars-d-learn wrote: On Friday, 20 June 2014 at 12:17:22 UTC, Johann Lermer wrote: So, why is there no init routine for the rectangle? There's only one for the matrix. That needs actually building deimos cairo and checking symbols in object files so I will do as soon as have a bit more spare time ;) If i were to guess: the compiler optimizes the init-blitting into a memset(-equivalent) when all the members are default initted to zero; D's doubles are initialized to NaN, so this optimization is not happening when a struct contains such fields. artur
Re: template mixins for boilerplate
On 06/21/14 05:32, Paul D Anderson via Digitalmars-d-learn wrote:
I can't use a template mixin:
mixin template Function(string name)
{
const char[] Function =
public static int ~ name ~ () { return other.module. ~ name ~; };
}
Error: mixin templates are not regular templates.
mixin template Function(string name) {
mixin(public static int ~ name ~ () { return other.module. ~ name
~; });
}
struct S {
mixin Function!fctn1;
}
artur
Re: template mixins for boilerplate
On Saturday, 21 June 2014 at 11:12:18 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
On 06/21/14 05:32, Paul D Anderson via Digitalmars-d-learn
wrote:
I can't use a template mixin:
mixin template Function(string name)
{
const char[] Function =
public static int ~ name ~ () { return other.module.
~ name ~; };
}
Error: mixin templates are not regular templates.
mixin template Function(string name) {
mixin(public static int ~ name ~ () { return
other.module. ~ name ~; });
}
struct S {
mixin Function!fctn1;
}
artur
Beautiful! That's it.
Thanks,
Paul
Re: template mixins for boilerplate
Out of curiosity, why use a mixin template containing a string mixin instead of, well, directly injecting a string mixin in your struct, with a function?
Re: template mixins for boilerplate
On Saturday, 21 June 2014 at 13:45:14 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: Out of curiosity, why use a mixin template containing a string mixin instead of, well, directly injecting a string mixin in your struct, with a function? Hiding non-hygienic implementation behind a more reliable interface.
Re: rehabilitating Juno
On Saturday, 21 June 2014 at 10:26:57 UTC, simendsjo wrote: This is great. I used Juno back in 2007 for working with Excel, and it worked great. Nice to see the library getting an update for D2. I remember seeing some slides on another COM library for D2 a while ago. Was that effort ever open-sourced? IIRC it was a Microsoft employee using D with WinRT[1]. He did not open-source his work. I think Juno was pretty much on par with ease of use, but I never got to the point of doing a direct comparison (now that I have Windows 8 I think it would be possible) http://www.lunesu.com/index.php?/archives/126-Modern-COM-Programming-in-D.html Anyway, Juno does work in 32 bit, I think 64 bit is close. If I actually had a problem to solve with COM I'd probably be working out the kinks. But I want to give credit to Richard Webb for providing solutions for several COM integration problems. I've just been deprecating things and keeping it compiling for the latest compiler.
Re: Working on a library: request for code review
On Friday, 20 June 2014 at 11:15:20 UTC, Mike wrote: Do you think it's ready for a v0.1 release? It be willing to add it to dub if it passes general D coding stardards. Sure, go for it :). Dub package versioning should be done using SemVer so there are some restrictions on how to number a release. http://semver.org/
Re: template mixins for boilerplate
On Sat, Jun 21, 2014 at 4:24 PM, Dicebot via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Saturday, 21 June 2014 at 13:45:14 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
Out of curiosity, why use a mixin template containing a string mixin
instead of, well, directly injecting a string mixin in your struct,
with a function?
Hiding non-hygienic implementation behind a more reliable interface.
In what way is a template more reliable than the equivalent function?
That's an honest question: I'm just looking at the code a few posts
upward:
mixin template Function(string name) {
mixin(public static int ~ name ~ () { return other.module. ~
name ~; });
}
struct S {
mixin Function!fctn1;
}
And this double-mixin construction seems needlessly complicated to me,
compared to:
string Function(string name) {
return public static int ~ name ~ () { return other.module.
~ name ~; };
}
struct S {
mixin(Function(fctn1));
}
assocArray.get(key, default) exists?
IS there such method get(key, default) for associative arrays, like in Python?
Re: assocArray.get(key, default) exists?
On Saturday, June 21, 2014, Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: IS there such method get(key, default) for associative arrays, like in Python? I think it's named getDefault, try that.
Re: enum functions
On Saturday, June 21, 2014, Paul D Anderson via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Does enum have any effect on functions? I think that's just a parser bug.
Re: assocArray.get(key, default) exists?
Paul: IS there such method get(key, default) for associative arrays, like in Python? Try it. Bye, bearophile
What is the correct way to forward method calls to the struct field?
I tried this:
struct S {
R opDispatch(string name, R, Args...)(Args args) {
return mixin((*iface). ~ name)(iface, args);
}
SomeT ** iface;
}
But then val.foo(1, 2) gives me no property 'foo' for type 'S'.
I've seen the template solution:
struct S {
template opDispatch(string name) {
R opDispatch(R, Args...)(Args args) {
return mixin((*iface). ~ name)(iface, args);
}
}
SomeT ** iface;
}
But that does not seem to work anymore.
I've tried then
struct S {
auto ifc() {
return *iface;
}
auto ifc() const {
return *iface;
}
SomeT ** iface;
}
And that worked, but it's not perfect: i also want to pass iface
as a first argument.
val.foo(1, 2) - (*val.iface).foo(val.iface, 1, 2).
Any suggestions?
Re: What is the correct way to forward method calls to the struct field?
Actyaly, last variant didn't work either: i was testing it inside S like ifc.foo(1), so UFCS kiked in, not alias this.
Re: assocArray.get(key, default) exists?
On Saturday, 21 June 2014 at 18:14:15 UTC, bearophile wrote: Paul: IS there such method get(key, default) for associative arrays, like in Python? Try it. Bye, bearophile Wow! Thank you! It exists. Excuse my silly question :)
Re: What is the correct way to forward method calls to the struct field?
On Saturday, 21 June 2014 at 18:16:17 UTC, monnoroch wrote: Actyaly, last variant didn't work either: i was testing it inside S like ifc.foo(1), so UFCS kiked in, not alias this. Oh, my bad, alias impl this; actually did work. But the first argument problem still holds.
Re: Some kind of RPC exists for D?
On Wednesday, 18 June 2014 at 19:24:03 UTC, Bienlein wrote: Hello, I'm looking for a way to do some kind of RPC in D. Some way of being able to say aFoo.bar(int i, ...) with receiver object and method being marshalled at the sender's site and being unmarshalled and invoked at the receiver's site. Any hints appreciated. Thanks, Bienlein I wrote some (JSONRPC and TXTRPC) and used them with vibe. I can send you via email
opAssign() calls members' postblits?
import std.stdio;
struct A {
this(this) {
writeln(A.this(this));
}
B b1, b2;
}
struct B {
this(this) {
writeln(B.this(this));
}
}
void main() {
A a, b;
a = b;
}
This outputs:
B.this(this)
B.this(this)
A.this(this)
Now, http://dlang.org/struct.html#AssignOverload says:
ref S opAssign(S s)
{
S tmp = this; // bitcopy this into tmp
this = s; // bitcopy s into this
tmp.__dtor(); // call destructor on tmp
return this;
}
Note the term bitcopy, which for me implies that no postblits
are supposed to be called.
What the compiler does makes sense to me, but it seems to
contradict the documentation. I guess the call to the postblit is
missing in the pseudo-code... Am I right?
(DMD git 514db2e212ae52e1206d4296e48d4a689370d04b)
Re: template mixins for boilerplate
On 06/21/14 18:01, Philippe Sigaud via Digitalmars-d-learn wrote:
In what way is a template more reliable than the equivalent function?
mixin template Function(string name) {
mixin(public static int ~ name ~ () { return other.module. ~
name ~; });
}
struct S {
mixin Function!fctn1;
}
And this double-mixin construction seems needlessly complicated to me,
It does not make much difference for this simple case, but doing it this
way allows for other declarations that do not need to be mixed in.
IOW if 'Function' contains more boilerplate, then it does not all need
to be written inside a string. Not to mention it saves two sets of parens. :)
A mixin template *is* slightly more reliable than a function, because
it won't be (ab-)usable in many context where a normal function call works.
But I think this choice is mostly an aesthetical (ie subjective) one.
artur
Re: opAssign() calls members' postblits?
On 06/21/2014 11:56 AM, Marc Schütz schue...@gmx.net wrote:
import std.stdio;
struct A {
this(this) {
writeln(A.this(this));
}
B b1, b2;
}
struct B {
this(this) {
writeln(B.this(this));
}
}
void main() {
A a, b;
a = b;
}
This outputs:
B.this(this)
B.this(this)
A.this(this)
Now, http://dlang.org/struct.html#AssignOverload says:
ref S opAssign(S s)
{
Note that opAssign takes by-value. The post-blits that you see are due
that copy. i.e. b in main is copied to the argument that opAssign sees.
Also note that if the right-hand side in main() were an rvalue, then
that copy would not involve any post-blit.
S tmp = this; // bitcopy this into tmp
this = s; // bitcopy s into this
tmp.__dtor(); // call destructor on tmp
return this;
}
Note the term bitcopy, which for me implies that no postblits are
supposed to be called.
What the compiler does makes sense to me, but it seems to contradict the
documentation. I guess the call to the postblit is missing in the
pseudo-code... Am I right?
(DMD git 514db2e212ae52e1206d4296e48d4a689370d04b)
Ali
Re: What is the correct way to forward method calls to the struct field?
You can use 'auto' to let the compiler deduce the return type. Here I
use 'foo' which returns an int and 'bar', which returns void.
struct SomeT {
int foo(double d) { return 0;}
void bar(double d) { return;}
}
struct S {
auto /* here */
opDispatch(string name, Args...)(Args args) {
return mixin((*iface). ~ name)(args);
}
SomeT** iface;
}
void main()
{
SomeT st;
SomeT* st_p = st;
SomeT** st_p_p = st_p;
S s = S(st_p_p);
import std.stdio : writeln;
writeln(s.foo(3.14)); // 0
writeln(typeof(s.bar(3.14)).stringof); // void
}
On Sat, Jun 21, 2014 at 8:21 PM, monnoroch via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Saturday, 21 June 2014 at 18:16:17 UTC, monnoroch wrote:
Actyaly, last variant didn't work either: i was testing it
inside S like ifc.foo(1), so UFCS kiked in, not alias this.
Oh, my bad, alias impl this; actually did work. But the first
argument problem still holds.
Re: template mixins for boilerplate
Apart from what Artur has mentioned template mixins also give you
opportunity to do qualified injection in case generated symbols
conflict with existing ones:
class A
{
void foo() {}
mixin(void foo() {}); // error, need to add manual
namespace wrapper
mixin func!foo Sub; // does this out of the box
}
It also slightly improves error messages because semantic
analysis of generated code is done in template declaration
context as opposed to whole aggregate.
In general it is pretty good styling rule to follow by default
even if it does not make any real difference in simple cases like
this one.
