Jump to page: 1 2
Thread overview
CTFE with C functions not possible?
Dec 31, 2015
Shriramana Sharma
Dec 31, 2015
Rikki Cattermole
Dec 31, 2015
Shriramana Sharma
Dec 31, 2015
Rikki Cattermole
Dec 31, 2015
Shriramana Sharma
Dec 31, 2015
Rikki Cattermole
Dec 31, 2015
Shriramana Sharma
Dec 31, 2015
Rikki Cattermole
Dec 31, 2015
Shriramana Sharma
Dec 31, 2015
Rikki Cattermole
Jan 01, 2016
Shriramana Sharma
Jan 01, 2016
Rikki Cattermole
Jan 02, 2016
Shriramana Sharma
Dec 31, 2015
Daniel Kozak
December 31, 2015
Using DMD 2.0.69.2, the following code:

extern (C) double sqrt(double x);
enum q = sqrt(4.0);

gives the error:

Error: sqrt cannot be interpreted at compile time, because it has no available source code

But if I do:

import std.math;
enum q = sqrt(4.0);

There is no problem. So two questions:

1) Why exactly can't the compiler call a C function at compile time whereas it can call a D function?

2) <same as above> ... which itself only in the end calls that very same C function IIANM?

I see druntime/import/core/math.d l 91:

double sqrt(double x);  /* intrinsic */

-- 
Shriramana Sharma, Penguin #395953
January 01, 2016
On 01/01/16 12:52 AM, Shriramana Sharma wrote:
> Using DMD 2.0.69.2, the following code:
>
> extern (C) double sqrt(double x);
> enum q = sqrt(4.0);
>
> gives the error:
>
> Error: sqrt cannot be interpreted at compile time, because it has no
> available source code
>
> But if I do:
>
> import std.math;
> enum q = sqrt(4.0);
>
> There is no problem. So two questions:
>
> 1) Why exactly can't the compiler call a C function at compile time whereas
> it can call a D function?
>
> 2) <same as above> ... which itself only in the end calls that very same C
> function IIANM?
>
> I see druntime/import/core/math.d l 91:
>
> double sqrt(double x);  /* intrinsic */

From what I've been able to tell, std.math have some special yucky rules about it and intrinsics.
It will make it very hard to split std.math up.
December 31, 2015
Rikki Cattermole wrote:

> It will make it very hard to split std.math up.

I have no desire to split std.math up. :-)

What I desire to do is be able to call a C library from a D template like octal to compute a string at compile time.

Is this possible or not?

-- 
Shriramana Sharma, Penguin #395953
January 01, 2016
On 01/01/16 1:05 AM, Shriramana Sharma wrote:
> Rikki Cattermole wrote:
>
>> It will make it very hard to split std.math up.
>
> I have no desire to split std.math up. :-)

I do though.

> What I desire to do is be able to call a C library from a D template like
> octal to compute a string at compile time.
>
> Is this possible or not?

No, source is not available.

December 31, 2015
Shriramana Sharma wrote:

> What I desire to do is be able to call a C library from a D template like octal to compute a string at compile time.

To be more explicit, I wrote a library in C since it's much leaner size-wise than the D code (although admittedly much *much* more tedious to write especially with all those string manipulations) and since it's callable from other languages like Python too.

None of those other languages have CTFE AFAICS. I would like to provide at least the D wrapper to the C library with a template which will enable CTFE computation via the library (it's just a string to string conversion). But the D compiler is complaining that it cannot call the C function at compile time even though the library is installed under /usr/local/lib and Python is able to access it via CTypes.

Please help!

-- 
Shriramana Sharma, Penguin #395953
December 31, 2015
Rikki Cattermole wrote:

>> Is this possible or not?
> 
> No, source is not available.

Why, is it because the D compiler is already linked to the C library (and hence knows where the functions are located and such), but not to my library? I mean, I even gave -L-lmylib and all that, but of course now I realize that that is only telling the *linker* about the lib. How do I tell the compiler to the lib? If Python CTypes can query and find out any library with the SO filename I throw at it, can't a D compiler?

-- 
Shriramana Sharma, Penguin #395953
January 01, 2016
On 01/01/16 1:11 AM, Shriramana Sharma wrote:
> Shriramana Sharma wrote:
>
>> What I desire to do is be able to call a C library from a D template like
>> octal to compute a string at compile time.
>
> To be more explicit, I wrote a library in C since it's much leaner size-wise
> than the D code (although admittedly much *much* more tedious to write
> especially with all those string manipulations) and since it's callable from
> other languages like Python too.
>
> None of those other languages have CTFE AFAICS. I would like to provide at
> least the D wrapper to the C library with a template which will enable CTFE
> computation via the library (it's just a string to string conversion). But
> the D compiler is complaining that it cannot call the C function at compile
> time even though the library is installed under /usr/local/lib and Python is
> able to access it via CTypes.
>
> Please help!

As I said its just not possible.
Either port it to D and extern(C) it so it is accesible from other languages or not have CTFE support.

January 01, 2016
On 01/01/16 1:14 AM, Shriramana Sharma wrote:
> Rikki Cattermole wrote:
>
>>> Is this possible or not?
>>
>> No, source is not available.
>
> Why, is it because the D compiler is already linked to the C library (and
> hence knows where the functions are located and such), but not to my
> library? I mean, I even gave -L-lmylib and all that, but of course now I
> realize that that is only telling the *linker* about the lib. How do I tell
> the compiler to the lib? If Python CTypes can query and find out any library
> with the SO filename I throw at it, can't a D compiler?

You misunderstand, its hardcoded into the CTFE evaluator. That is what an intrinsic is.
December 31, 2015
Rikki Cattermole wrote:

> You misunderstand, its hardcoded into the CTFE evaluator. That is what an intrinsic is.

What do you mean hardcoded into the CTFE evaluator? Surely you aren't suggesting that the D compiler contains its own implementation of the functions already implemented in libc?

-- 
Shriramana Sharma, Penguin #395953
January 01, 2016
On 01/01/16 1:29 AM, Shriramana Sharma wrote:
> Rikki Cattermole wrote:
>
>> You misunderstand, its hardcoded into the CTFE evaluator. That is what
>> an intrinsic is.
>
> What do you mean hardcoded into the CTFE evaluator? Surely you aren't
> suggesting that the D compiler contains its own implementation of the
> functions already implemented in libc?

Yes and no.
It has a small subset of functions which it consider intrinsics.
Intrinsics are only a way to tell the compiler hey go call x and give me the result.

Remember, if you don't have the source you can't execute it.
Unless you provide an escape hatch which is what intrinsics are.

« First   ‹ Prev
1 2