Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 31, 2015 CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | 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 Re: CTFE with C functions not possible? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | 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.
|
Copyright © 1999-2021 by the D Language Foundation