Re: DMD OSX / Segfault 11
On 2/2/16 1:06 PM, Robert M. Münch wrote:
I have a very strange effect, I'm not sure what it is about:
Value: {}
WordV: Value {
Value* get() {}
}
BaseOperator: Value : {
}
Now comes the code using this:
auto op = cast(BaseOperator)(Word.get());
if (op !is null) {...
If get() returns "Value*" it segfaults, if I change it to "Value" it
works. How can this be?
I want to check of the Value returned from get() is a BaseOperator or not.
If this is valid D, I'm not sure what it means :)
-Steve
Re: Linking C libraries with DMD
On Friday, 22 January 2016 at 04:43:52 UTC, Mike Parker wrote: [snip] Thanks again for your help. I've worked through some simple examples and started trying to write a binding to a C library. I think I've got the .h file converted properly (the D file compiles), but I was getting a linking error. The enums were showing up, but not the functions. I tried creating a simple project that mimics what was happening in the C library and found no issues. I think I narrowed it down to what is causing the linking error. I had not compiled the C dll myself. Looking in to the issue, I noticed it was compiled with MinGW. There were instructions for using it with Visual Studio (to make the .def and .dll files into a .lib) though and I assumed following those was sufficient. However, based on what you've said, I suspect that if I re-compile the dll using Visual Studio, then it will work with D. I don't think I would have figured that out without your comments above.
Re: Determine type of property
On Tuesday, 2 February 2016 at 03:36:25 UTC, Steven Schveighoffer
wrote:
int y() { return 1;}
No need for meta-programming hackery, mark it as @property:
int y() @property { return 1;}
Re: How would you implement this in D? (signals & slots)
On Tuesday, 2 February 2016 at 17:35:25 UTC, Chris Wright wrote: On Tue, 02 Feb 2016 15:59:06 +, Atila Neves wrote: [...] I've seen this sort of thing before. A blogger I used to follow, Jeremy Miller, implemented an event broker using this pattern. I don't like it. It requires a new type for each event, and you have to defensively use that pattern even if you only have one event at the moment. Every time I implemented an event system, I've gone with named events and no special type for their parameters. [...] Nice. I liked your example and Kagamin's better than mine. Atila
const and immutable member variables in classes
const and immutable members make structs non-assignable:
struct S {
const int c;// Makes S non-assignable
immutable int i;// Makes S non-assignable
}
void main() {
auto a = S();
auto b = S();
a = b; // Compilation ERROR
}
(That is the same issue in C++.)
That's why I've been avoiding them altogether. However, considering that
there is no default-assignment for classes, there is no problem with
using const or immutable members with classes, right?
Ali
Re: Linking C libraries with DMD
On Tuesday, 2 February 2016 at 20:06:05 UTC, jmh530 wrote: I suspect that if I re-compile the dll using Visual Studio, then it will work with D. Yeah, this is what finally allowed me to progress. Unfortunately, my sample example compiles, but throws an Access Violation error when I run it. I think I will start a new thread to address that.
Binding to C - Arrays and Access Violation
I'm working on generating a binding to a C library. I've got the
.h file converted and can call some parts of the library with no
errors. However, I have reached a stumbling block in a critical
part.
The library requires passing function pointers to various
functions in the library. When I try to run these functions, I
get an Access Violation error. I enabled additional DMD warnings,
which helped pinpoint the issue.
My D code calls a C function. One of the parameters to the C
function is a function pointer to a D function. This D function
(below) is one that I copied from the C library's tutorial. I
only slightly changed the signature. This function is eventually
called in other functions in the C library.
double myfunc(uint n, const double* x, double* grad, void*
my_func_data)
{
if (grad)
{
grad[0] = 0.0;
grad[1] = 0.5 / sqrt(x[1]);
}
return sqrt(x[1]);
}
The line (though likely the next will too) that causes a problem
is
grad[0] = 0.0;
Thus, as it is an Access Violation, I'm guessing the issue is
with accessing elements of arrays in the D function from the C
function. I don't know. When I try to call the D function in D,
it works, but I have to refer to x and grad as x.ptr and grad.ptr.
I'm not sure how to go about fixing this...
Re: const and immutable member variables in classes
On 02.02.2016 23:48, Ali Çehreli wrote:
struct S {
const int c;// Makes S non-assignable
immutable int i;// Makes S non-assignable
}
void main() {
auto a = S();
auto b = S();
a = b; // Compilation ERROR
}
(That is the same issue in C++.)
That's why I've been avoiding them altogether. However, considering that
there is no default-assignment for classes, there is no problem with
using const or immutable members with classes, right?
I'm not sure what you mean by "default assignment". I'd say it works
more simply with classes, because they're reference types. It's the same
as using pointers to structs:
auto a = new S();
auto b = new S();
a = b; /* no problem */
Re: const and immutable member variables in classes
On 02/02/2016 03:02 PM, anonymous wrote: > I'm not sure what you mean by "default assignment". I think I meant member-wise assignment. :) > I'd say it works > more simply with classes, because they're reference types. It's the same > as using pointers to structs: > > auto a = new S(); > auto b = new S(); > a = b; /* no problem */ Exactly. This aspect of reference types had not occurred to me until recently. Ali
Re: Binding to C - Arrays and Access Violation
On Tuesday, 2 February 2016 at 22:56:28 UTC, jmh530 wrote:
I'm working on generating a binding to a C library. I've got
the .h file converted and can call some parts of the library
with no errors. However, I have reached a stumbling block in a
critical part.
The library requires passing function pointers to various
functions in the library. When I try to run these functions, I
get an Access Violation error. I enabled additional DMD
warnings, which helped pinpoint the issue.
My D code calls a C function. One of the parameters to the C
function is a function pointer to a D function. This D function
(below) is one that I copied from the C library's tutorial. I
only slightly changed the signature. This function is
eventually called in other functions in the C library.
double myfunc(uint n, const double* x, double* grad, void*
my_func_data)
{
if (grad)
{
grad[0] = 0.0;
grad[1] = 0.5 / sqrt(x[1]);
}
return sqrt(x[1]);
}
The line (though likely the next will too) that causes a
problem is
grad[0] = 0.0;
Thus, as it is an Access Violation, I'm guessing the issue is
with accessing elements of arrays in the D function from the C
function. I don't know. When I try to call the D function in D,
it works, but I have to refer to x and grad as x.ptr and
grad.ptr.
I'm not sure how to go about fixing this...
Is grad allocated in the D code? If so, it could have been
collected because the GC lost track of its use when passing to
and from the C code. Or is grad owned by the C code? If so,
either there is a bug in the library or it's misused, because its
memory has been freed/has never been allocated/has gone out of
scope.
Re: Binding to C - Arrays and Access Violation
On Tuesday, 2 February 2016 at 22:56:28 UTC, jmh530 wrote:
My D code calls a C function. One of the parameters to the C
function is a function pointer to a D function. This D function
(below) is one that I copied from the C library's tutorial. I
only slightly changed the signature. This function is
eventually called in other functions in the C library.
double myfunc(uint n, const double* x, double* grad, void*
my_func_data)
Thus, as it is an Access Violation, I'm guessing the issue is
with accessing elements of arrays in the D function from the C
function. I don't know. When I try to call the D function in D,
it works, but I have to refer to x and grad as x.ptr and
grad.ptr.
I'm not sure how to go about fixing this...
The parameter to the C function should be declared as extern(C),
and so should your function implementation.
extern(C) alias FuncPtr = double function(uint, const(double)*,
double*, void*);
extern(C) void takeFuncPtr(FuncPtr);
extern(C) double myfunc(uint n, const(double)* x, double* grad,
void* my_func_data) {
...
}
If you haven't done that, then this is quite possibly the root of
your problem.
Re: const and immutable member variables in classes
On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn
wrote:
> const and immutable members make structs non-assignable:
>
> struct S {
> const int c;// Makes S non-assignable
> immutable int i;// Makes S non-assignable
> }
>
> void main() {
> auto a = S();
> auto b = S();
> a = b; // Compilation ERROR
> }
>
> (That is the same issue in C++.)
>
> That's why I've been avoiding them altogether. However, considering that
> there is no default-assignment for classes, there is no problem with
> using const or immutable members with classes, right?
Default initialization isn't really the issue. It's assignability in
general. Even if you @disabled default initialization in a struct, then
having a const or immutable member would be annoying, because you couldn't
assign it another value later. But in any case, no, classes don't have that
problem (at least not normally), because you don't assign to them. You just
assign to their references. So, you don't normally run into an issue where
you're trying to overwrite the state of a class object and aren't able to.
Now, you _can_ run into issues if you want to provide a way to overwrite the
whole state of a class object similar to assigning to a struct, but the
class would have to be specially written to support that via some kind of
non-standard function in order to support that, and you could just avoid
giving such a class any const or immutable members.
- Jonathan M Davis
DMD OSX / Segfault 11
I have a very strange effect, I'm not sure what it is about:
Value: {}
WordV: Value {
Value* get() {}
}
BaseOperator: Value : {
}
Now comes the code using this:
auto op = cast(BaseOperator)(Word.get());
if (op !is null) {...
If get() returns "Value*" it segfaults, if I change it to "Value" it
works. How can this be?
I want to check of the Value returned from get() is a BaseOperator or not.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: DMD OSX / Segfault 11
On 02.02.2016 19:06, Robert M. Münch wrote:
I have a very strange effect, I'm not sure what it is about:
Value: {}
WordV: Value {
Value* get() {}
}
BaseOperator: Value : {
}
This isn't valid D code at all, which makes it unnecessarily hard to
understand what you mean.
Now comes the code using this:
auto op = cast(BaseOperator)(Word.get());
if (op !is null) {...
If get() returns "Value*" it segfaults, if I change it to "Value" it
works. How can this be?
A Value* is a pointer to a class reference. Unless you're doing
something really funky with the pointer, casting it to a class type
doesn't make sense.
Casting between class types that have an inheritance relation, like
Value and BaseOperator, does make sense (upcat/downcast).
If anything, you should be casting between Value* and BaseOperator*
(both pointer types) if you want to do something with pointers.
But you very seldom need pointers to class references. Just return Value
from get, and cast to BaseOperator.
Re: const and immutable member variables in classes
On Tue, Feb 02, 2016 at 09:08:07PM -0800, Jonathan M Davis via Digitalmars-d-learn wrote: > On Tuesday, February 02, 2016 19:32:39 Ali Çehreli via Digitalmars-d-learn > wrote: > > On 02/02/2016 07:05 PM, Jonathan M Davis via Digitalmars-d-learn wrote: > > > I usually tell folks not to do it because of all of the problems > > > it causes. > > > > That's been my guideline: "const and immutable members should be > > avoided." Now I'm tempted to add this: "only in structs." > > IIRC, I've pretty much always been telling folks specifically to not > have structs with const or immutable members and haven't generally > said anything about classes. > > But I really don't see any reason to avoid it in classes at this > point. Maybe if a serialization mechanism were involved, it would > matter, but the class would probably have to be designed to support > that given that there is no equivalent to the assignment operator for > the class objects themselves (just their references). Ultimately, it's > the ability to overwrite the state of the object that's the problem, > and that simply isn't an issue with class objects under normal > circumstances. [...] I still can't come up with a compelling use case that would justify using a const/immutable class member, that couldn't be done by some other means, though. Especially since we're talking about classes, we already have all the traditional OO mechanisms for controlling access to members - get methods, and so on, which are more flexible and adaptable to different use cases to begin with (e.g., can be overridden by derived classes, can implement custom access criteria not expressible by const/immutable, etc.), so I have a hard time justifying using const/immutable members instead. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Re: Determine type of property
On 2/2/16 2:04 PM, NX wrote:
On Tuesday, 2 February 2016 at 03:36:25 UTC, Steven Schveighoffer wrote:
int y() { return 1;}
No need for meta-programming hackery, mark it as @property:
int y() @property { return 1;}
I don't have control over S. I am passed S and need to figure out that
it qualifies as a type I can use.
I also figured this out on my own, but for some reason my reply didn't
go through. This is what I came up with:
template propertyType(alias x)
{
static if(is(typeof(x) == function))
alias propertyType = typeof(x());
else
alias propertyType = typeof(x);
}
-Steve
Re: Binding to C - Arrays and Access Violation
On Wednesday, 3 February 2016 at 00:28:24 UTC, biozic wrote: Is grad allocated in the D code? If so, it could have been collected because the GC lost track of its use when passing to and from the C code. Or is grad owned by the C code? If so, either there is a bug in the library or it's misused, because its memory has been freed/has never been allocated/has gone out of scope. grad is only created in the C code. I don't pass it myself.
Re: Binding to C - Arrays and Access Violation
On Wednesday, 3 February 2016 at 00:37:25 UTC, Mike Parker wrote:
The parameter to the C function should be declared as
extern(C), and so should your function implementation.
extern(C) alias FuncPtr = double function(uint, const(double)*,
double*, void*);
extern(C) void takeFuncPtr(FuncPtr);
extern(C) double myfunc(uint n, const(double)* x, double* grad,
void* my_func_data) {
...
}
If you haven't done that, then this is quite possibly the root
of your problem.
Success! Couldn't have done it without your help.
I had originally had the equivalent of FuncPtr as extern(C), but
I had removed that because myfunc wouldn't compile. I hadn't
thought of putting those modifications on myfunc. Just assumed
that I did the function pointers wrong.
A few extra questions: 1) In other parts of the code I'm using
extern(System), but that doesn't work for these. Why is extern(C)
used for function pointers?, 2) You use const(double)*, in other
parts of the code I had converted the C code from const char* to
const(char*). Does it matter where the pointer * falls?
Re: const and immutable member variables in classes
On Tuesday, February 02, 2016 19:32:39 Ali Çehreli via Digitalmars-d-learn wrote: > On 02/02/2016 07:05 PM, Jonathan M Davis via Digitalmars-d-learn wrote: > > I usually tell folks not to do it because of > > all of the problems it causes. > > That's been my guideline: "const and immutable members should be > avoided." Now I'm tempted to add this: "only in structs." IIRC, I've pretty much always been telling folks specifically to not have structs with const or immutable members and haven't generally said anything about classes. But I really don't see any reason to avoid it in classes at this point. Maybe if a serialization mechanism were involved, it would matter, but the class would probably have to be designed to support that given that there is no equivalent to the assignment operator for the class objects themselves (just their references). Ultimately, it's the ability to overwrite the state of the object that's the problem, and that simply isn't an issue with class objects under normal circumstances. - Jonathan M Davis
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 13:57:54 UTC, Marc Schütz wrote: On Tuesday, 2 February 2016 at 13:52:55 UTC, Marc Schütz wrote: The last call should work IMO, but it doesn't. I believe that's a compiler bug. Filed: https://issues.dlang.org/show_bug.cgi?id=15640 I would say it is not a bug test!A(new B(), new C()); // works which is what I expected
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 14:47:43 UTC, Marc Schütz wrote: On Tuesday, 2 February 2016 at 14:12:54 UTC, Daniel Kozak wrote: On Tuesday, 2 February 2016 at 13:57:54 UTC, Marc Schütz wrote: On Tuesday, 2 February 2016 at 13:52:55 UTC, Marc Schütz wrote: The last call should work IMO, but it doesn't. I believe that's a compiler bug. Filed: https://issues.dlang.org/show_bug.cgi?id=15640 I would say it is not a bug test!A(new B(), new C()); // works which is what I expected if you mix ints and floats, the common type is deduced correctly: this is a bug for me :). I do not like this. I am ok with (u)byte to int conversion and similar, but mixing float and integral types does not seems to be OK.
Re: Switch with dynamic case
On Tuesday, 2 February 2016 at 15:01:57 UTC, anonymous wrote: On 02.02.2016 15:07, Daniel Kozak wrote: [...] The key thing to understand is that the foreach is a "static" one. A static foreach is unrolled at compile-time. [...] Thanks :), this is all I need to know
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 13:52:55 UTC, Marc Schütz wrote: On Tuesday, 2 February 2016 at 13:20:33 UTC, Voitech wrote: [...] Two possible solutions... If you don't need to know the number of arguments at compile time, you can use normal variadic arguments: [...] Thank you I'll try that.
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 14:55:42 UTC, Daniel Kozak wrote:
On Tuesday, 2 February 2016 at 14:47:43 UTC, Marc Schütz wrote:
if you mix ints and floats, the common type is deduced
correctly:
this is a bug for me :). I do not like this. I am ok with
(u)byte to int conversion and similar, but mixing float and
integral types does not seems to be OK.
I see. But it's also consistent with array type deduction
elsewhere:
auto a = [1, 2.5];
pragma(msg, typeof(a)); // double[]
... and more importantly:
class A { }
class B : A { }
class C : A { }
auto a = [new A(), new B()];
pragma(msg, typeof(a)); // A[]
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 14:12:54 UTC, Daniel Kozak wrote: On Tuesday, 2 February 2016 at 13:57:54 UTC, Marc Schütz wrote: On Tuesday, 2 February 2016 at 13:52:55 UTC, Marc Schütz wrote: The last call should work IMO, but it doesn't. I believe that's a compiler bug. Filed: https://issues.dlang.org/show_bug.cgi?id=15640 I would say it is not a bug test!A(new B(), new C()); // works which is what I expected The bug is that `T` is not automatically inferred to be `A`. That's not a restriction of type inference in general: if you mix ints and floats, the common type is deduced correctly, just not for classes.
Re: How would you implement this in D? (signals & slots)
On Monday, 1 February 2016 at 21:44:28 UTC, Enjoys Math wrote: On Monday, 1 February 2016 at 21:40:45 UTC, Enjoys Math wrote: module signals_and_slots; import std.algorithm: remove; [...] D's signals & slots: https://dlang.org/phobos/std_signals.html I looked at that and perhaps I'm not reading the exampes correctly but I'm not sure how useful std.signals is in the real world. If you have a bunch of slots which take the same parameter types, not unusual in the GUI world, how would that work? The other thing that bugs me is lack of naming for slots and signals, again in the GUI world where you typically have dozens of these on an an individual widget differentiation is quite important. For my GtkD app where I need my own events between components outside of the built-in GTK ones I've just been rolling my own by hand using delegates similar to your example. It's pretty trivial but admittingly there is a bunch of boilerplate I'd love to eliminate via templates if there is a way to address the weaknesses with std.signals.
Re: Switch with dynamic case
On 02.02.2016 15:07, Daniel Kozak wrote:
import std.stdio;
import std.typetuple : TypeTuple;
alias cs = TypeTuple!(0, 1, 2, 3);
void main(string[] argv)
{
switch(argv.length)
{
default: writeln("Uknown number of args"); break;
foreach(c; cs)
{
case c: writefln("%s args", c);
break;
}
}
}
This works, but I dont know why or how, is there some documentation
about this feature?
The key thing to understand is that the foreach is a "static" one. A
static foreach is unrolled at compile-time.
So that switch code is replaced at compile time with this, almost:
switch(argv.length)
{
default: writeln("Uknown number of args"); break;
case 0: writefln("%s args", 0);
break;
case 1: writefln("%s args", 1);
break;
case 2: writefln("%s args", 0);
break;
}
"But", I hear you ask, "it breaks when I put the default at the bottom.
What's up with that?". Yeah, that's a bit weird/buggy.
The problem is with the break statement. It applies to the foreach, not
to the switch. And while the foreach is unrolled at compile-time, the
break is evaluated at run-time. The generated code really looks more
like this:
switch(argv.length)
{
default: writeln("Uknown number of args"); break;
/* start of unrolled foreach */
case 0: writefln("%s args", 0);
goto behind_foreach;
case 1: writefln("%s args", 1);
goto behind_foreach;
case 2: writefln("%s args", 0);
goto behind_foreach;
/* end of unrolled foreach */
behind_foreach:
}
So, the breaks skip past the other cases that were created by the
foreach, but they don't actually break out of the switch.
There are at least two open issues related to this:
https://issues.dlang.org/show_bug.cgi?id=14887
https://issues.dlang.org/show_bug.cgi?id=7835
Everything works fine when breaking the switch with a label:
sw: switch(argv.length)
{
foreach(c; cs)
{
case c: writefln("%s args", c);
break sw;
}
default: writeln("Uknown number of args"); break;
}
Unfortunately, the spec is rather quiet about static foreach. And you
won't actually find the term "static foreach". The only thing I could
find is a little "Foreach over Tuples" section on
, which doesn't tell a lot.
Re: chain(const(array of class)) fails
The constraint that fails is the one with `CommonType`: pragma(msg, CommonType!(const(B), const(C))); // void `CommonType` uses the `?:` operator to derive the common type: writeln(true ? b : c); // Error: incompatible types for ((b) : (c)): 'const(B[])' and 'const(C[])' writeln(true ? b[0] : c[0]); // Error: incompatible types for ((b[0]) : (c[0])): 'const(B)' and 'const(C)' At the moment I can't see a reason why that shouldn't work.
Re: How would you implement this in D? (signals & slots)
On Tuesday, 2 February 2016 at 14:49:21 UTC, Gerald wrote:
On Monday, 1 February 2016 at 21:44:28 UTC, Enjoys Math wrote:
On Monday, 1 February 2016 at 21:40:45 UTC, Enjoys Math wrote:
module signals_and_slots;
import std.algorithm: remove;
[...]
D's signals & slots:
https://dlang.org/phobos/std_signals.html
I looked at that and perhaps I'm not reading the exampes
correctly but I'm not sure how useful std.signals is in the
real world. If you have a bunch of slots which take the same
parameter types, not unusual in the GUI world, how would that
work?
Switch on the value inside the slot. Or use different types by
wrapping, say, an int or a string with a struct:
import std.stdio;
import std.signals;
struct String1 { string s; }
struct String2 { string s; }
class Observer {
void watch1(String1) { writeln("watch1"); }
void watch2(String2) { writeln("watch2"); }
}
class Signals {
mixin Signal!String1;
mixin Signal!String2;
}
void main() {
auto o = new Observer;
auto s = new Signals;
s.connect();
s.connect();
s.emit(String1("foo"));
s.emit(String2("bar"));
}
The other thing that bugs me is lack of naming for slots and
signals, again in the GUI world where you typically have dozens
of these on an an individual widget differentiation is quite
important.
Slots are named: the methods are slots. Signals can be named if
you use only one struct as the parameter, as above. The signals
would be String1 and String2, the slots watch1 and watch2.
Atila
Re: chain(const(array of class)) fails
On Tuesday, 2 February 2016 at 09:51:52 UTC, Marc Schütz wrote: The constraint that fails is the one with `CommonType`: pragma(msg, CommonType!(const(B), const(C))); // void `CommonType` uses the `?:` operator to derive the common type: writeln(true ? b : c); // Error: incompatible types for ((b) : (c)): 'const(B[])' and 'const(C[])' writeln(true ? b[0] : c[0]); // Error: incompatible types for ((b[0]) : (c[0])): 'const(B)' and 'const(C)' At the moment I can't see a reason why that shouldn't work. This change broke it: https://github.com/D-Programming-Language/dmd/pull/125 I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=15638
Variadic template parameters T... bounding
Hi, Is it possible to bound T... in template with some type ? For single Parameter declaration it can be done by T:SomeType but variadics does not seems to have that possibility ? Cheers
Re: How would you implement this in D? (signals & slots)
On Tue, 02 Feb 2016 15:59:06 +, Atila Neves wrote:
> struct String1 { string s; }
> struct String2 { string s; }
I've seen this sort of thing before. A blogger I used to follow, Jeremy
Miller, implemented an event broker using this pattern. I don't like it.
It requires a new type for each event, and you have to defensively use
that pattern even if you only have one event at the moment. Every time I
implemented an event system, I've gone with named events and no special
type for their parameters.
With std.signals, you could do this:
struct Event(TArgs...) {
mixin Signal!TArgs;
}
class Foo {
Event!string usernameEntered;
Event!string passwordEntered;
Event!(long, string) someOtherEventHappened;
void enterPassword(string s) { passwordEntered.emit(s); }
void enterUsername(string s) { usernameEntered.emit(s); }
}
void main() {
auto o = new Observer;
auto f = new Foo;
f.usernameEntered.connect();
f.passwordEntered.connect();
f.enterUsername("adelhurst");
f.enterPassword("");
}
Re: How would you implement this in D? (signals & slots)
On Tuesday, 2 February 2016 at 15:59:06 UTC, Atila Neves wrote: Slots are named: the methods are slots. Signals can be named if you use only one struct as the parameter, as above. The signals would be String1 and String2, the slots watch1 and watch2. What I meant is that the connect call didn't seem to tie you to a specific slot, it looked like it determined the slot based on the types which is potentially error prone. Kagamin showed an example of explicitly connecting to a named slot so I'm happy with that, I'm looking forward to re-writing my event handlers using this technique. Always nice to learn something new.
Re: chain(const(array of class)) fails
On Tuesday, 2 February 2016 at 10:58:35 UTC, Marc Schütz wrote: The constraint that fails is the one with `CommonType`: `CommonType` uses the `?:` operator to derive the common type: I filed a bug report: https://issues.dlang.org/show_bug.cgi?id=15638 Interesting reduced case, so it wasn't chain after all. Thanks for filing the issue already; also thanks to Nic for good test cases. I think Adam D. Ruppe wanted to push more informative template errors -- they'd come in handy. :-) -- Simon
Re: First project: questions on how-to, and on language features
On Sunday, 24 January 2016 at 18:52:41 UTC, Chris Wright wrote: There is no documentation, so I have no idea what you're trying to achieve here. So your questions about why this isn't in Phobos, whether there are any other libraries that do this, and whether there's a way to simplify your contracts are impossible for me to answer. Objections have been noted and (hopefully) corrected: https://github.com/ajvincent/d-experiments/blob/master/IntervalMap/source/intervalmap.d I'm going for the concept of versioning data - first a single value, and then members of an array. (I haven't implemented the versioning of arrays yet.) That's why I said it's an inverse of Phobos ranges: each iteration call to a range could give you a different value. Here, several versions can point to one value. Feedback is still most strongly welcomed.
Re: const and immutable member variables in classes
On 02/02/2016 07:05 PM, Jonathan M Davis via Digitalmars-d-learn wrote: > Well, in principle, if you have a member that's going to be initialized on > construction and then never mutated, having it be const or immutable would > be desirable, That's how I've seen it used in a friend's code. Makes sense to me as long as it's not a struct. > but for all of the reasons that you're listing, to do so with > structs is ultimately a bad idea. Agreed. > But under normal > circumstances, member variables of classes don't have that problem, because > you don't normally ever try to overwrite the state of the whole class > object. Exactly my point. > I usually tell folks not to do it because of > all of the problems it causes. That's been my guideline: "const and immutable members should be avoided." Now I'm tempted to add this: "only in structs." Ali
Re: const and immutable member variables in classes
On Tuesday, February 02, 2016 18:14:50 H. S. Teoh via Digitalmars-d-learn wrote: > On Tue, Feb 02, 2016 at 05:49:00PM -0800, Jonathan M Davis via > Digitalmars-d-learn wrote: > > On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn > > wrote: > > > const and immutable members make structs non-assignable: > [...] > > > That's why I've been avoiding them altogether. However, considering > > > that there is no default-assignment for classes, there is no problem > > > with using const or immutable members with classes, right? > > > > Default initialization isn't really the issue. It's assignability in > > general. Even if you @disabled default initialization in a struct, > > then having a const or immutable member would be annoying, because you > > couldn't assign it another value later. But in any case, no, classes > > don't have that problem (at least not normally), because you don't > > assign to them. You just assign to their references. So, you don't > > normally run into an issue where you're trying to overwrite the state > > of a class object and aren't able to. > [...] > > In general, I find const/immutable members more of a pain than anything > else. Such aggregates are extremely cumbersome to work with, and > besides, I've yet to come up with a conceptually-clean mental model of > just what kind of semantics exactly an aggregate with a const/immutable > member "ought" to have. > > *Reference* members to const/immutable data make sense -- these include > string members, for example, as immutable(char)[]. It's not a problem > because the reference itself is mutable, just not what it refers to. > > It's also not a problem when the entire aggregate is const or immutable, > e.g., when passing by const to a const member, for example. By > transitivity, it's clear that the entire aggregate is const / immutable, > so every member is also transitively so. > > But when a member itself is const or immutable, things become really > icky. A mutable instance of a struct with a const member is in a weird > mixed state of being partially mutable and partially not. You can never > create an instance of the struct that's fully mutable, so even when > given a mutable instance, you can't overwrite it, you can't assign to > it, etc.. > > It's also unclear what guarantee the const/immutable member is supposed > to provide. In the case of an argument to a function, it's clear that > const means the callee promises not to modify, and immutable means the > caller (and callee) promise never to modify. But what promise does a > const/immutable member give? That nobody can ever modify, except this > only applies to that member and the rest of the aggregate may still be > mutable? It's rather unclean semantics that leads to all sorts of > needlessly convoluted cases, with hard-to-grasp results, and it's hard > to think of a use case that requires such a construct, that can't be > done some other way. Well, in principle, if you have a member that's going to be initialized on construction and then never mutated, having it be const or immutable would be desirable, but for all of the reasons that you're listing, to do so with structs is ultimately a bad idea. Things just get weird and annoying when you have const or immutable members in mutable structs. But under normal circumstances, member variables of classes don't have that problem, because you don't normally ever try to overwrite the state of the whole class object. But for some reason, I keep seeing folks post stuff where they've tried to have const or immutable members of structs. I don't know if the folks who do so typically give up on it, but I usually tell folks not to do it because of all of the problems it causes. - Jonathan M Davis
Re: const and immutable member variables in classes
On Tue, Feb 02, 2016 at 05:49:00PM -0800, Jonathan M Davis via Digitalmars-d-learn wrote: > On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn > wrote: > > const and immutable members make structs non-assignable: [...] > > That's why I've been avoiding them altogether. However, considering > > that there is no default-assignment for classes, there is no problem > > with using const or immutable members with classes, right? > > Default initialization isn't really the issue. It's assignability in > general. Even if you @disabled default initialization in a struct, > then having a const or immutable member would be annoying, because you > couldn't assign it another value later. But in any case, no, classes > don't have that problem (at least not normally), because you don't > assign to them. You just assign to their references. So, you don't > normally run into an issue where you're trying to overwrite the state > of a class object and aren't able to. [...] In general, I find const/immutable members more of a pain than anything else. Such aggregates are extremely cumbersome to work with, and besides, I've yet to come up with a conceptually-clean mental model of just what kind of semantics exactly an aggregate with a const/immutable member "ought" to have. *Reference* members to const/immutable data make sense -- these include string members, for example, as immutable(char)[]. It's not a problem because the reference itself is mutable, just not what it refers to. It's also not a problem when the entire aggregate is const or immutable, e.g., when passing by const to a const member, for example. By transitivity, it's clear that the entire aggregate is const / immutable, so every member is also transitively so. But when a member itself is const or immutable, things become really icky. A mutable instance of a struct with a const member is in a weird mixed state of being partially mutable and partially not. You can never create an instance of the struct that's fully mutable, so even when given a mutable instance, you can't overwrite it, you can't assign to it, etc.. It's also unclear what guarantee the const/immutable member is supposed to provide. In the case of an argument to a function, it's clear that const means the callee promises not to modify, and immutable means the caller (and callee) promise never to modify. But what promise does a const/immutable member give? That nobody can ever modify, except this only applies to that member and the rest of the aggregate may still be mutable? It's rather unclean semantics that leads to all sorts of needlessly convoluted cases, with hard-to-grasp results, and it's hard to think of a use case that requires such a construct, that can't be done some other way. T -- Любишь кататься - люби и саночки возить.
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 13:20:33 UTC, Voitech wrote:
Hi, Is it possible to bound T... in template with some type ?
For single Parameter declaration it can be done by T:SomeType
but variadics does not seems to have that possibility ?
Cheers
import std.stdio;
import std.meta: allSatisfy;
import std.traits;
void some(T...)(T Args) if (allSatisfy!(isIntegral,T)) {
writeln(Args);
}
void main()
{
some(1);
some(1,2,3);
some(1,2,3.0); // error
}
Re: Variadic template parameters T... bounding
On Tuesday, 2 February 2016 at 13:52:55 UTC, Marc Schütz wrote: The last call should work IMO, but it doesn't. I believe that's a compiler bug. Filed: https://issues.dlang.org/show_bug.cgi?id=15640
Switch with dynamic case
import std.stdio;
import std.typetuple : TypeTuple;
alias cs = TypeTuple!(0, 1, 2, 3);
void main(string[] argv)
{
switch(argv.length)
{
default: writeln("Uknown number of args"); break;
foreach(c; cs)
{
case c: writefln("%s args", c);
break;
}
}
}
This works, but I dont know why or how, is there some
documentation about this feature?
