www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is betterC affect to compile time?

reply Oleg B <code.viator gmail.com> writes:
Hello everyone!

I try build this code with betterC

import core.stdc.stdio;
import std.format : format;

extern(C) int main()
{
     mixin(format!`enum str = "%s\0";`("hello"));
     fprintf(stderr, "%s\n", str.ptr);
     return 0;
}

but compilation fails

/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278): 
Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308): 
Error: template instance `std.format.checkFormatException!("enum 
str = \"%s\\0\";", string)` error instantiating
onlineapp.d(6):        instantiated from here: format!("enum str 
= \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):       
  while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204): Error: 
TypeInfo cannot be used with -betterC

Is this a bug?

https://run.dlang.io/is/TG1uhg
Jul 25 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:

 Hello everyone!

 I try build this code with betterC

 import core.stdc.stdio;
 import std.format : format;

 extern(C) int main()
 {
     mixin(format!`enum str = "%s\0";`("hello"));
     fprintf(stderr, "%s\n", str.ptr);
     return 0;
 }

 but compilation fails

 /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278): 
 Error: Cannot use try-catch statements with -betterC
 /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308): 
 Error: template instance 
 `std.format.checkFormatException!("enum str = \"%s\\0\";", 
 string)` error instantiating
 onlineapp.d(6):        instantiated from here: format!("enum 
 str = \"%s\\0\";", string)
 /dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
  while evaluating: static assert(!e)
 /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204): 
 Error: TypeInfo cannot be used with -betterC

 Is this a bug?

 https://run.dlang.io/is/TG1uhg


If you read the documentation for betterC 
(https://dlang.org/spec/betterc.html#consequences) you'll see 
that there are features of the D language which are not 
supported. Therefore, libraries that use such features (e.g. 
std.format, std.array) are also not supported, and that is why 
you are encountering such errors.

There are some features of Phobos which can be used in betterC 
builds, but you're going to find that it's hit-and-miss.

Mike
Jul 25 2019
parent reply Oleg B <code.viator gmail.com> writes:
On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote:

 If you read the documentation for betterC 
 (https://dlang.org/spec/betterc.html#consequences) you'll see 
 that there are features of the D language which are not 
 supported. Therefore, libraries that use such features (e.g. 
 std.format, std.array) are also not supported, and that is why 
 you are encountering such errors.

 There are some features of Phobos which can be used in betterC 
 builds, but you're going to find that it's hit-and-miss.

 Mike


You don't understand my question and don't read code. I ask about 
compile time evaluation (`format` used inside `mixin` that means 
it must be computed at compile time). I know that I can't use 
many features with betterC at runtime.
Jul 25 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 26/07/2019 12:30 AM, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:20:04 UTC, Mike Franklin wrote:

 If you read the documentation for betterC 
 (https://dlang.org/spec/betterc.html#consequences) you'll see that 
 there are features of the D language which are not supported. 
 Therefore, libraries that use such features (e.g. std.format, 
 std.array) are also not supported, and that is why you are 
 encountering such errors.

 There are some features of Phobos which can be used in betterC builds, 
 but you're going to find that it's hit-and-miss.

 Mike


 
 You don't understand my question and don't read code. I ask about 
 compile time evaluation (`format` used inside `mixin` that means it must 
 be computed at compile time). I know that I can't use many features with 
 betterC at runtime.


Those restrictions don't stop at runtime.
Jul 25 2019
parent reply Oleg B <code.viator gmail.com> writes:
On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:

 Those restrictions don't stop at runtime.


It's vary sad.

What reason for such restrictions? It's fundamental idea or 
temporary implementation?
Jul 25 2019
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/25/2019 05:46 AM, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:

 Those restrictions don't stop at runtime.


 
 It's vary sad.
 
 What reason for such restrictions? It's fundamental idea or temporary 
 implementation?


It looks like a bug to me.

Ali
Jul 25 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, July 25, 2019 8:20:03 AM MDT Ali Çehreli via Digitalmars-d-
learn wrote:

 On 07/25/2019 05:46 AM, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote:

 Those restrictions don't stop at runtime.


 It's vary sad.

 What reason for such restrictions? It's fundamental idea or temporary
 implementation?


 It looks like a bug to me.


There's probably at least one bug report on it, but as I understand it, it's
not a bug in the sense that the implementation is currently expected to
handle such a case. It's an area where betterC should be improved upon, but
it would be an enhancement, not a bug fix.

- Jonathan M Davis
Jul 25 2019
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote:


 There's probably at least one bug report on it, but as I 
 understand it, it's not a bug in the sense that the 
 implementation is currently expected to handle such a case. 
 It's an area where betterC should be improved upon, but it 
 would be an enhancement, not a bug fix.


Yes.  The point is that libraries have to be written with betterC 
and compile-time evaluation in mind.  If they aren't the code is 
likely not going to work in those use cases.  Much of the code in 
Phobos was written long before betterC was introduced.

There are probably changes that could be made to Phobos so the OP 
could get a build, but that requires someone with enough interest 
in the issue to volunteer their time and talent to improve the 
implementation for betterC and compile-time use cases.

We have a GSoC student making changes the druntime to help with 
this matter and I have been picking away at it too.  It will take 
time and could use more contributors.

Mike
Jul 25 2019
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, July 25, 2019 6:13:38 PM MDT Mike Franklin via Digitalmars-d-
learn wrote:

 On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote:

 There's probably at least one bug report on it, but as I
 understand it, it's not a bug in the sense that the
 implementation is currently expected to handle such a case.
 It's an area where betterC should be improved upon, but it
 would be an enhancement, not a bug fix.


 Yes.  The point is that libraries have to be written with betterC
 and compile-time evaluation in mind.  If they aren't the code is
 likely not going to work in those use cases.  Much of the code in
 Phobos was written long before betterC was introduced.

 There are probably changes that could be made to Phobos so the OP
 could get a build, but that requires someone with enough interest
 in the issue to volunteer their time and talent to improve the
 implementation for betterC and compile-time use cases.

 We have a GSoC student making changes the druntime to help with
 this matter and I have been picking away at it too.  It will take
 time and could use more contributors.


I honestly don't see why how the library works should matter for CTFE so
long as it's CTFE-able. format creates a string, and mixin then mixes in
that string as code. None of that should have any effect on the generated
code or what happens at runtime beyond the code that's mixed in. Sure,
whether a library can be used with betterC at runtime depends on how the
library was implemented, but runtime is a completely different beast from
compile time. IMHO, the fact that you can't use format to create a
compile-time construct with betterC is purely a problem with dmd's current
implementation.

- Jonathan M Davis
Jul 26 2019
prev sibling parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 25 July 2019 at 14:20:03 UTC, Ali Çehreli wrote:

 On 07/25/2019 05:46 AM, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole 
 wrote:

 Those restrictions don't stop at runtime.


 
 It's vary sad.
 
 What reason for such restrictions? It's fundamental idea or 
 temporary implementation?


 It looks like a bug to me.

 Ali


If the spec is to be believed then it is.

I filed a bugzilla, https://issues.dlang.org/show_bug.cgi?id=20086
Jul 26 2019
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole 
 wrote:

 Those restrictions don't stop at runtime.


 It's vary sad.

 What reason for such restrictions? It's fundamental idea or 
 temporary implementation?


Yes it is very sad.  It's an implementation thing.  I can guess 
as to a couple reasons why it doesn't work, but I think there's a 
few big ones that contribute to not being able to use certain 
features at compile-time without having it introduce things at 
runtime.
Jul 25 2019
parent bauss <jj_1337 live.dk> writes:
On Thursday, 25 July 2019 at 18:06:02 UTC, Jonathan Marler wrote:

 On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:

 On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole 
 wrote:

 Those restrictions don't stop at runtime.


 It's vary sad.

 What reason for such restrictions? It's fundamental idea or 
 temporary implementation?


 Yes it is very sad.  It's an implementation thing.  I can guess 
 as to a couple reasons why it doesn't work, but I think there's 
 a few big ones that contribute to not being able to use certain 
 features at compile-time without having it introduce things at 
 runtime.


Anything you do at compile-time should never produce anything at 
runtime UNLESS it's a field created or something created using 
mixin.

D's betterC is pretty useless if you can't use D to its fullest 
at compile-time regardless of whether you're compiling with 
betterC or not.

It takes the one thing away from D that it does better than other 
languages, which is CTFE and metaprogramming.
Jul 25 2019
prev sibling parent Kagamin <spam here.lot> writes:
On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:

 What reason for such restrictions? It's fundamental idea or 
 temporary implementation?


I think it's a dmd limitation. Currently it has a bug that it can 
still generate code for ctfe templated functions, and they will 
fail to link if they use runtime. So yeah, currently betterC 
really means betterC all the way down. The alternative is to 
compile without -betterC switch and just use a minimal runtime if 
you use runtime features, then you have full language in ctfe.
Jul 26 2019