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 contr
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 beca
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 membe
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)
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 misus
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. Ma
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 member
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. How
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
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 fun
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 funct
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
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
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 tr
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
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.
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 typ
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
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 q
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
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;}
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
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
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 cha
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'
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 ev
http://dpaste.dzfl.pl/f888feb6f743
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/pho
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, b
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
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)
{
c
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
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://issue
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
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 t
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
te
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
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
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
Two possible solutions... If you don't need to
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;
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
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
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[])'
write
43 matches
Mail list logo
