Am 16.10.2013 03:17, schrieb DoctorCaptain:
I've gotten extremely close. The DPaste link that follows demonstrates
three different templates:
...
So is there any reason why you still pass the variadic arguments to the
generator function and not do it the way I proposed in my last dpaste
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot call
impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln(DTor);
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot call
impure function 'f223.A.~this'
with this code:
import std.stdio;
On Tuesday, 15 October 2013 at 14:15:15 UTC, bearophile wrote:
Daniel Davidson:
If you are agreeing that chain should be pure and it is just
following all the calls and making all of them pure, until
that happens by the professionals - is there a casting
solution so I can fake a pure and
On Wednesday, 16 October 2013 at 07:27:25 UTC, Namespace wrote:
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot
call impure
andrew@islay:~/dub$ ./build.sh
Generating version file...
Running gdmd...
/usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224:
error: this cannot be interpreted at compile time, because it
has no available source code
On Wednesday, 16 October 2013 at 07:32:27 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 07:27:25 UTC, Namespace wrote:
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
On Wednesday, 16 October 2013 at 06:09:48 UTC, Benjamin Thaut
wrote:
Am 16.10.2013 03:17, schrieb DoctorCaptain:
I've gotten extremely close. The DPaste link that follows
demonstrates
three different templates:
...
So is there any reason why you still pass the variadic
arguments to the
On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote:
andrew@islay:~/dub$ ./build.sh
Generating version file...
Running gdmd...
/usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224:
error: this cannot be interpreted at compile time, because it
has no
As far as I know deimos is a set of official (?) bindings for
common C libraries. I don't know dub's build process but I
assume that if the build script would have worked for you it
would have attempted to clone this repo
https://github.com/D-Programming-Deimos/openssl (you can find
more
On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote:
Giving up on dub, I tried niaively to build one of the vibe.d
samples directly
This is something I have used with vibe.d in absence of dub
(untested, from my memory):
git clone https://github.com/D-Programming-Deimos/openssl
git
On Tuesday, 15 October 2013 at 22:52:42 UTC, Andrew wrote:
andrew@islay:~/dub$ ./build.sh
Generating version file...
Running gdmd...
/usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224:
error: this cannot be interpreted at compile time, because it
has no available
On Tuesday, 15 October 2013 at 23:16:07 UTC, Brad Roberts wrote:
I think you mean catch-22 rather than dead-end. There's not
more people helping support ARM due to ARM not yet working
well, so there's no developers.
ARM's not exotic, it's just not on as many people's desktops.
Thats been
Timothee Cour:
is the following true?
int*[N] a=void;
foreach(i;N)
a[i]=fillValue(i);// some leaks may occur during foreach loop
//at the next GC run, no more leaks due to that piece of code
I think so, but I am not an expert on GC matters, I have not yet
written a similar GC.
Bye,
On Tuesday, 15 October 2013 at 23:03:15 UTC, Andrew wrote:
Thanks for your patience supporting me BTW.
You are welcome. D development is pure open-source movement with
all its pros and cons - almost anyone here will gladly help you
not only because we care about a good public image but
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a D
shared library which exports function (with extern (C)) for
invocation from Java.
My .d file contains only a single function returning an int,
.java calls
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a D
shared library which exports function (with extern (C)) for
invocation from Java.
My .d file
On Wednesday, 16 October 2013 at 10:15:17 UTC, Iain Buclaw wrote:
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a
D shared library which exports
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a D
shared library which exports function (with extern (C)) for
invocation from Java.
My .d file
On Wednesday, 16 October 2013 at 10:15:17 UTC, Iain Buclaw wrote:
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a
D shared library which exports
On Wednesday, 16 October 2013 at 10:53:28 UTC, Andrew wrote:
On Wednesday, 16 October 2013 at 10:41:35 UTC, John Colvin
wrote:
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI -
On 2013-10-16 12:53, Andrew wrote:
Wow, thanks! Now everything works, proving that my guess on
uninitialized runtime was correct.
It's actually Runtime.initialize() according to documentation, by the way.
If you're calling it from C it might be more correct to call this function:
On Wednesday, 16 October 2013 at 11:01:33 UTC, Jacob Carlborg
wrote:
On 2013-10-16 12:53, Andrew wrote:
Wow, thanks! Now everything works, proving that my guess on
uninitialized runtime was correct.
It's actually Runtime.initialize() according to documentation,
by the way.
If you're calling
On Wednesday, 16 October 2013 at 11:01:33 UTC, Jacob Carlborg
wrote:
On 2013-10-16 12:53, Andrew wrote:
Wow, thanks! Now everything works, proving that my guess on
uninitialized runtime was correct.
It's actually Runtime.initialize() according to documentation,
by the way.
If you're calling
On Wednesday, 16 October 2013 at 09:11:16 UTC, Andrew wrote:
As far as I know deimos is a set of official (?) bindings for
common C libraries. I don't know dub's build process but I
assume that if the build script would have worked for you it
would have attempted to clone this repo
It seems that __traits(getAttributes, T) returns an empty tuple
for any template (or template function) T, no matter what UDAs T
has been given.
Am I doing something wrong?
@(1) void foo(T)(){}
pragma(msg, __traits(getAttributes, foo)); // tuple()
pragma(msg, __traits(getAttributes,
On Wednesday, 16 October 2013 at 12:26:34 UTC, John Colvin wrote:
It seems that __traits(getAttributes, T) returns an empty tuple
for any template (or template function) T, no matter what UDAs
T has been given.
Am I doing something wrong?
@(1) void foo(T)(){}
pragma(msg,
(quick experiments show that one can't attached UDA to template
symbol itself by any means - weird limitation, don't know the
rationale behind this)
On Wednesday, 16 October 2013 at 13:12:39 UTC, Max Samukha wrote:
I'd rather have the same set of attributes on both the template
and its instantiations
Impossible, ignore
On Wednesday, 16 October 2013 at 12:37:23 UTC, Dicebot wrote:
(quick experiments show that one can't attached UDA to template
symbol itself by any means - weird limitation, don't know the
rationale behind this)
It is understandable why the attribute is transferred to the
instantiation of the
On Wednesday, 16 October 2013 at 13:14:31 UTC, Max Samukha wrote:
On Wednesday, 16 October 2013 at 13:12:39 UTC, Max Samukha
wrote:
I'd rather have the same set of attributes on both the
template and its instantiations
Impossible, ignore
@(1)
template Foo(T : int) {}
@(2)
template Foo(T :
Would you mind posting your example code? I'm supposed to be
exploring using D on android myself next week and a little kick
to help get started would be cool; I've never actually done any
android stuff.
As I understand it though, you aren't supposed to use native code
for the bulk of the
On Wednesday, 16 October 2013 at 13:24:59 UTC, Max Samukha wrote:
@(1)
template Foo(T : int) {}
@(2)
template Foo(T : short) {}
__traits(getAttributes, Foo) == ?
The current semantics seems quite reasonable.
@(1)
void foo(int) {}
@(2)
void foo(double) {}
pragma(msg,
On Wednesday, October 16, 2013 09:29:31 monarch_dodra wrote:
The problem is that the whole inference things stops at this
level: the attributes of front are not infered, so chain is not
pure simply because it isn't a template.
http://d.puremagic.com/issues/show_bug.cgi?id=10329
And I think
Oh something I forgot. You should really start littering your code with
pragma(msg, ...) statements to better understand what it does.
You can for example make your generator output pramga(msg,
T.stringof); to find out what T actually is.
Kind Regards
Benjamin Thaut
Am 16.10.2013 10:40, schrieb DoctorCaptain:
On Wednesday, 16 October 2013 at 06:09:48 UTC, Benjamin Thaut wrote:
Am 16.10.2013 03:17, schrieb DoctorCaptain:
I've gotten extremely close. The DPaste link that follows demonstrates
three different templates:
...
So is there any reason why you
On Wednesday, 16 October 2013 at 13:38:44 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 13:24:59 UTC, Max Samukha
wrote:
@(1)
template Foo(T : int) {}
@(2)
template Foo(T : short) {}
__traits(getAttributes, Foo) == ?
The current semantics seems quite reasonable.
@(1)
void foo(int)
Am 16.10.2013 10:40, schrieb DoctorCaptain:
http://dpaste.dzfl.pl/07b20d75
Note the use of typeof() to get the type of the elements at each index
of members, to generate a type on which a constructor can be called to
instantiate the elements at each index of members. Magic.
There is actually
The following code runs fine. There is a whole bunch of types
imported, so whittling it down to the problem is not too easy.
import plus.models.assumption;
import pprint.pp;
import std.stdio;
import std.datetime;
void main() {
immutable am = AssumptionModel();
writeln(pp(am));
}
That code
On Wednesday, 16 October 2013 at 13:31:50 UTC, Adam D. Ruppe
wrote:
Would you mind posting your example code? I'm supposed to be
exploring using D on android myself next week and a little kick
to help get started would be cool; I've never actually done any
android stuff.
As I understand it
On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:
Hello there!
I've decided to learn a bit of D, as I am currently Android
Developer (mostly C++ - JNI - Java), I'm trying to create a D
shared library which exports function (with extern (C)) for
invocation from Java.
My .d file
On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels
stephan_schiff...@mac.com wrote:
For example, is there a way of instantiating an object
normally (i.e. mutable), and then later freeze it to
immutable via a simple cast or
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of the rval to ref issue. If
that is the case, how can foo be called by casting?
I'm not a fan of casting but I'm finding cases where it is
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
import std.conv;
struct T {
int[] i;
string[string] ss;
}
void foo(ref T t) {
}
void main() {
T t1;
auto t2 = immutable T();
foo(t1);
foo(cast()t2);
}
It works as it should. Make a mutable copy of t2 and pass
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus. I
definitely agree it would be helpful to
On 10/16/2013 10:23 AM, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson wrote:
guidelines):
1. If a variable is never mutated, make it const, not immutable.
2. Make the parameter reference to immutable if that is how you will
use it anyway. It is fine
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't imagine a single legitimate
use case for destroying type system in a way you want.
How do you propose to make a mutable copy
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson wrote:
[...]
Maybe it is a philosophical question, but where does immutability
really come from? Is it an aspect of some piece of data or is it a
promise that function
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't imagine a single
legitimate use case for destroying type
struct S {
R r;
this(ref immutable(T) t) immutable {
r.tupleof = t.tupleof;
}
}
?
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of the rval to ref issue. If
that is the case, how can foo be called
On Wednesday, 16 October 2013 at 17:58:41 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't
On Wednesday, 16 October 2013 at 17:55:56 UTC, Dicebot wrote:
struct S {
R r;
this(ref immutable(T) t) immutable {
r.tupleof = t.tupleof;
}
}
?
Thanks. It is cute - but not so helpful. The example stands. I
*need* to call a createRFromT.
Their shapes are the same in this simple
On Wednesday, 16 October 2013 at 18:09:55 UTC, Maxim Fomin wrote:
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of
Am 16.10.2013 16:08, schrieb Benjamin Thaut:
Am 16.10.2013 10:40, schrieb DoctorCaptain:
http://dpaste.dzfl.pl/07b20d75
Note the use of typeof() to get the type of the elements at each index
of members, to generate a type on which a constructor can be called to
instantiate the elements at
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
[...]
Maybe it is a philosophical question, but where does
immutability
really come from? Is
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works. The
following diagram may help (please excuse the ASCII graphics):
const
/ \
mutable immutable
I think people in this
On Wednesday, 16 October 2013 at 18:14:22 UTC, Daniel Davidson
wrote:
I agree with the sentiment. But as it stands I think a copy
should not be necessary. I could make a local mutable R, pass
it to createRFromT to get it initialized and then copy it back
somehow to the member variable r. That
On Wed, Oct 16, 2013 at 08:49:51PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
[...]
If you have a type that has now or may ever have in the future any
mutable aliasing (e.g.
AWW you posted that while I was writing my latest novel. So
T[i] doesn't work? I guess I shouldn't have opened my eyes this
morning. In any case, typeof() DOES work, so as long as there
is a way to extract the type, we're good.
I am extremely pleased it's actually possible to get individual
On Wednesday, 16 October 2013 at 18:47:25 UTC, Benjamin Thaut
wrote:
Am 16.10.2013 16:08, schrieb Benjamin Thaut:
Am 16.10.2013 10:40, schrieb DoctorCaptain:
http://dpaste.dzfl.pl/07b20d75
Note the use of typeof() to get the type of the elements at
each index
of members, to generate a type
On Wednesday, 16 October 2013 at 18:52:23 UTC, qznc wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works.
The
following diagram may help (please excuse the ASCII graphics):
const
/
On Wed, Oct 16, 2013 at 08:52:22PM +0200, qznc wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works. The
following diagram may help (please excuse the ASCII graphics):
const
/ \
On Wednesday, 16 October 2013 at 19:06:06 UTC, Daniel Davidson
wrote:
I don't understand how it could be fine. As code grows it would
lead to people not adding useful members like history just
because of the huge repercussions.
struct User {
immutable(Foo) foos;
}
How can I as a user
Am 16.10.2013 21:02, schrieb DoctorCaptain:
On Wednesday, 16 October 2013 at 14:08:52 UTC, Benjamin Thaut wrote:
Am 16.10.2013 10:40, schrieb DoctorCaptain:
http://dpaste.dzfl.pl/07b20d75
Note the use of typeof() to get the type of the elements at each index
of members, to generate a type on
I'm a very happy man ! Everything is built and working including
dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to everybody for the help, now I can start learning D,
exploring vibe.d
On Wednesday, 16 October 2013 at 19:01:59 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 08:49:51PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh
wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson
wrote:
[...]
If you have a type that has
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote:
I'm a very happy man ! Everything is built and working
including dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to
On 2013-10-16 16:05, Max Samukha wrote:
That sucks. Then, getAttributes (and other traits dealing with overload
sets) should return an empty set, a union or accept a pattern to match
against the members of the overload set.
Currenrly one need to call __traits(getOverloads) and then iterate of
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote:
I'm a very happy man ! Everything is built and working
including dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to
On Wed, Oct 16, 2013 at 09:06:05PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 18:52:23 UTC, qznc wrote:
[...]
Library code:
struct Foo { int x; }
User code:
Foo f;
immutable f2 = f;
This works, even though the library writer might not have
anticipated that
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to int*
p ?
On Wednesday, 16 October 2013 at 18:11:48 UTC, Daniel Davidson
On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 19:06:06 UTC, Daniel Davidson
wrote:
I don't understand how it could be fine. As code grows it
would lead to people not adding useful members like history
just because of the huge repercussions.
On 2013-10-16, 18:54, Daniel Davidson wrote:
On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels
stephan_schiff...@mac.com wrote:
For example, is there a way of instantiating an object normally (i.e.
mutable), and then
On Wednesday, 16 October 2013 at 19:55:41 UTC, Simen Kjaeraas
wrote:
On 2013-10-16, 18:54, Daniel Davidson wrote:
On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas
wrote:
On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels
stephan_schiff...@mac.com wrote:
For example, is there a
On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to
int*
On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to
int*
On Wed, Oct 16, 2013 at 09:45:09PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
[...]
I think any usage of immutable with types/entities not initially
designed for immutability is an potential mistake and in that
sense it is good that change has
On Wednesday, 16 October 2013 at 20:09:51 UTC, Daniel Davidson
wrote:
You and dicebot surely disagree on this practice as he sees no
real reason to ever circumvent the type system.
There are some cases were you have no other options because of
language design limitations but it is something
On Wed, Oct 16, 2013 at 10:09:50PM +0200, Daniel Davidson wrote:
[...]
I reported my issue with the `chain` function to this NG and tried
to start annotating items used by chain with pure to see how far the
thread led. Honestly it was quickly clear that it led too far for me
to follow it and
On Wednesday, October 16, 2013 14:10:02 H. S. Teoh wrote:
This is just a hack, of course. The compiler *should* be able to
correctly infer that the ctor is pure. So the real fix is to find out
why the compiler isn't doing that.
Because it sucks at attribute inference. The inference that it
On Wed, Oct 16, 2013 at 02:10:02PM -0700, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 10:09:50PM +0200, Daniel Davidson wrote:
[...]
I reported my issue with the `chain` function to this NG and tried
to start annotating items used by chain with pure to see how far the
thread led. Honestly it
I've clicked on Build Phobos browse info and now I have
absolute no idea how I can restore my old class view for my
current project. Any suggestions?
And it seems that VisualD ignores all of my Tasks. My Tasklist is
always empty, whats wrong? Or is this not implemented?
Basically I want to develop a program on Windows and send the exe
to someone to use on a Linux platform. Is this possible?
On Thursday, October 17, 2013 02:58:50 Stephen Jones wrote:
Basically I want to develop a program on Windows and send the exe
to someone to use on a Linux platform. Is this possible?
AFAIK, it's not possible. It _might_ be possible to do with mingw and gdc or
ldc (I don't know if they use
I would like to get access to a member function pointer. Taking
the this* as
the first argument.
class Foo
{
void bar(int a)
{
//do something awesome
}
}
unittest
{
Foo a = new Foo();
Foo b = new Foo();
auto fp = getFP!(Foo.bar);
fp(a, 1); //Basically calls
On Thursday, 17 October 2013 at 01:18:42 UTC, Jonathan M Davis
wrote:
In general, you can't cross-compile across operating systems.
Linux to Windows is pretty easy. You can just run the Windows
version of dmd under wine on linux to make exes, or you can
compile gcc (and presumably gdc,
On Thu, Oct 17, 2013 at 04:24:07AM +0200, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 01:18:42 UTC, Jonathan M Davis
wrote:
In general, you can't cross-compile across operating systems.
Linux to Windows is pretty easy. You can just run the Windows
version of dmd under wine on linux
On Thursday, 17 October 2013 at 01:17:21 UTC, TheFlyingFiddle
wrote:
I would like to get access to a member function pointer. Taking
the this* as
the first argument.
...snip...
How should i implement getFP above? Is it even possible?
Well, it's certainly possible. If you were to do this:
```
If you want to play within a Linux environment on Windows, you can try CygWIN:
http://www.cygwin.com/
On 17/10/13 04:24, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 01:18:42 UTC, Jonathan M Davis wrote:
In general, you can't cross-compile across operating systems.
Linux to Windows
90 matches
Mail list logo
