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
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
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 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
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
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'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
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++.)
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 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
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
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
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
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 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
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
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
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
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
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
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 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 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
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,
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:
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 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)
{
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[])'
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:
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:
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 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
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
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
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
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.
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
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.
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:
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
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);
41 matches
Mail list logo
