Re: Instantiating a class with different types at runtime
On Sunday, 27 November 2016 at 20:57:28 UTC, Namespace wrote:
class Example(L, R)
{
L _left;
R _right;
this(L l, R r)
{
_left = l;
_right = r;
}
}
That was fast! But I needed the second reply in order to
understand yours. Thanks anyway.
Re: Instantiating a class with different types at runtime
On Sunday, 27 November 2016 at 21:06:58 UTC, ag0aep6g wrote:
Turn Example into a template, and add a free function for nice
construction:
class Example(Type_left, Type_right)
{
/* ... as you had it ... */
}
Example!(L, R) makeExample(L, R)(L x, R y)
{
return new Example!(L, R)(x, y);
}
void main()
{
auto foo = makeExample(1, 2);
auto bar = makeExample(3, "baz");
}
Note that Example is not a type, but a template. That means,
foo and bar have different types, because their types are
different instantiations of the Example template. You can
define a common interface or (possibly abstract) base class.
Great! Many thanks.
Re: Parsing a string to instantiate classes at runtime
On Monday, 28 November 2016 at 09:33:08 UTC, Jacob Carlborg wrote: It's possible to bypass the constructors [1]. [1] https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L166 Aha! Interesting. Thanks.
Re: Parsing a string to instantiate classes at runtime
On Sunday, 27 November 2016 at 21:28:52 UTC, ag0aep6g wrote: Ok, that's a hypothetical. It's "if D had a 'dynamic mixin', then we could do fancy things with it." D doesn't have a 'dynamic mixin', so you can't do those fancy things, at least not in the envisioned way. You are right. I misread.
Re: Parsing a string to instantiate classes at runtime
On Sunday, 27 November 2016 at 21:10:30 UTC, ag0aep6g wrote: Can you link that post, please? I can't imagine what "dynamic mixin" could refer to. Sure, it's here: http://forum.dlang.org/post/xmnnsdiuwyjrhkasy...@forum.dlang.org In that thread they also mention Object.factory, but the documentation says that the class must have either no constructor or the default constructor, which is not my case.
Parsing a string to instantiate classes at runtime
Dear all, I would like to write a program that: 1. Receives a string from the UI 2. Parses the string 3. Instantiates classes, whose names are contained in the string, passing parts of the string as constructor arguments. From my experience with other programming languages, I suppose I need to define an eval function. I read in an old post in these forums that with a dynamic mixin it is possible to add structures and classes at runtime. I searched "dynamic mixin" but I did not find more information. Any help will be greatly appreciated.
Instantiating a class with different types at runtime
Dear all,
I would like to have a kind of template class like the following:
class Example {
this(Type_left x, Type_right y) {
this.left = x;
this.right = y;
}
Type_left left;
Type_right right;
}
Such that at runtime I can instantiate it with different types:
new Example(int a, int b);
new Example(int a, string b);
I have read about templates and abstract classes, but I have not
figured how to get this to work. Thanks.
Re: Complex numbers are harder to use than in C
On Sunday, 20 November 2016 at 11:46:04 UTC, Marc Schütz wrote: Try placing it outside the function. Method call syntax doesn't work with nested functions, see here: https://dlang.org/spec/function.html#pseudo-member "The reason why local symbols are not considered by UFCS, is to avoid unexpected name conflicts." Aha! Now it works. Thank you for the explanation.
Re: Complex numbers are harder to use than in C
On Sunday, 20 November 2016 at 12:08:23 UTC, Ilya Yaroshenko wrote: You can use builtin complex numbers (cfloat/cdouble/creal). The idea of std.complex is wrong . Mir GLAS uses builtin complex numbers and I don't think they will be really deprecated. --Ilya Good to know! The builtin syntax is more reasonable than std.complex.
Re: Complex numbers are harder to use than in C
On Saturday, 19 November 2016 at 12:55:57 UTC, Marc Schütz wrote:
On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote:
On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
The difference is that D is more verbose. Am I missing
something? Can we have C's behaviour in D?
Something like
auto I(T)(T im)
if (isNumeric!T)
{
return complex(0, im);
}
unittest
{
auto x = 1 + 2.I;
}
Or simply:
enum I = complex(0, 1);
auto x = 1 + 2*I;
Thanks! That's a clever idea.
What I do not understand is why if I declare the array with
Complex!double I need to complexify each entry. I would expect
that D automatically casts 0.0 to complex(0.0).
Re: Complex numbers are harder to use than in C
On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote:
On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
The difference is that D is more verbose. Am I missing
something? Can we have C's behaviour in D?
Something like
auto I(T)(T im)
if (isNumeric!T)
{
return complex(0, im);
}
unittest
{
auto x = 1 + 2.I;
}
Nice. But I am unsure of how to use this. I just pasted the
definition of I inside the main function of my program followed
by auto x = 1 + 2.I; and the compiler complained with Error: no
property 'I' for type 'int'.
Re: Using mixin in array declarations
On Saturday, 19 November 2016 at 13:57:26 UTC, Jonathan M Davis
wrote:
On Saturday, November 19, 2016 09:46:08 Marduk via
Digitalmars-d-learn wrote:
[...]
A string mixin literally puts the code there. So, doing
mixin("int n = 10");
double[n][n] m;
is identical to
int n = 10;
double[n][n] m;
except that you made the compile do the extra work of
converting the string mixin to the code. String mixins really
only become valuable when you start doing string manipulation
rather than simply using string literals. If you want a
compile-time constant, then use the enum keyword. e.g.
enum n = 10;
double[n][n] m;
And if you want the value of n to be calculated instead of
being fixed, then you can even do something like
enum n = calcN();
double[n][n] m;
so long as calcN can be run at compile time.
- Jonathan M Davis
Thank you very much for taking the time to write such a detailed
explanation. The first part I had already figured out.
String mixins really only become valuable when you start doing
string manipulation rather than simply using string literals.
Yes. I saw some examples in the docs.
The last part is very interesting.
Re: Complex numbers are harder to use than in C
On Saturday, 19 November 2016 at 16:17:08 UTC, Meta wrote:
On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
Dear all,
I just discovered D and I am translating some numerical code I
wrote in C. I was surprised to learn that there are at least
two things that are easier in C than in D:
+ Writing complex numbers
C: complex double z = 2.0 + 3.0*I;
D: auto z = complex(2.0, 3.0);
+ Arrays of complex numbers
C: complex double a[2][2] = {{1.0*I, 0.0}, {0.0, 1.0*I}};
D: Complex!double[2][2] a = [[complex(0.0, 1.0),
complex(0.0)], [complex(0.0), complex(0.0, 1.0)]];
The difference is that D is more verbose. Am I missing
something? Can we have C's behaviour in D?
D used to support complex numbers in the language (actually it
still does, they're just deprecated). This code should compile
with any D compiler:
cdouble[2][2] a = [[0 + 1i, 0], [0, 0 + 1i]];
Thank you! However, I am concerned that if this is deprecated,
then I should not use it (it is not future-proof). I wonder why D
dropped this syntax for complex numbers. It is very handy.
Re: Array operations with multidimensional arrays
On Saturday, 19 November 2016 at 17:37:58 UTC, John Colvin wrote: On Saturday, 19 November 2016 at 10:20:16 UTC, Marduk wrote: Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; You have the dimensions the wrong way around. a is a 2 element array of 2 element arrays of 3 element arrays. int[3][2][2] a; a[0] = [[2,2,2], [2,2,2]]; works fine. Thanks a lot! Now I get what it means that array declarations are read from right to left.
Array operations with multidimensional arrays
In the documentation one can learn how to do array operations with 1D arrays. However, this does not scale up for 2D arrays. For example, the following does not work: int[2][2] a,b; a = [[1,1],[1,1]]; b[][] = a[][]*2; Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; I did not understand how to use std.experimental.ndslice to do this. An example would be greatly appreciated.
Re: Using mixin in array declarations
On Saturday, 19 November 2016 at 09:49:48 UTC, rikki cattermole
wrote:
On 19/11/2016 10:46 PM, Marduk wrote:
In C one can do the following:
# define N 10
double M[N][N];
In D I would like to achieve the same result. I tried with:
mixin("int N = 10;");
double[N][N] M;
but the compiler (DMD) complained with Error: variable N
cannot be read
at compile time.
What am I doing wrong?
enum N = 10;
double[N][N] M;
enum is a constant available for use at compile time, your int
there is a runtime variable not accessible at runtime.
Great! Thanks! I just understood why what I did did not work.
Missing features from numpy
In order to make D more useful for writing numerical code I would like to suggest the following extensions for built-in functions: 1. Generate random arrays 2. Arithmetic operations with arrays 3. Mathematical functions evaluated element-wise for arrays I am aware of the existence of mir-glas, which will eventually satisfy 2. As for 1. and 3. I guess it is just a matter of method overloading. Eventually, it would be great to have a Rosetta stone to help newcomers start using D for numerical computations.
Using mixin in array declarations
In C one can do the following:
# define N 10
double M[N][N];
In D I would like to achieve the same result. I tried with:
mixin("int N = 10;");
double[N][N] M;
but the compiler (DMD) complained with Error: variable N cannot
be read at compile time.
What am I doing wrong?
Complex numbers are harder to use than in C
Dear all,
I just discovered D and I am translating some numerical code I
wrote in C. I was surprised to learn that there are at least two
things that are easier in C than in D:
+ Writing complex numbers
C: complex double z = 2.0 + 3.0*I;
D: auto z = complex(2.0, 3.0);
+ Arrays of complex numbers
C: complex double a[2][2] = {{1.0*I, 0.0}, {0.0, 1.0*I}};
D: Complex!double[2][2] a = [[complex(0.0, 1.0), complex(0.0)],
[complex(0.0), complex(0.0, 1.0)]];
The difference is that D is more verbose. Am I missing something?
Can we have C's behaviour in D?
