On Sunday, 28 July 2019 at 07:32:37 UTC, Paulo Pinto wrote:
> For the same reason that C++ needs a C like subset when you want to extract the ultimate performance out of it.

...are you talking about extern "C" there? Because that's not at all how extern "C" works in a C++ compiler.

I mean, your point in relation to High Performance C# is valid, it's literally "C#, but everything that touches the garbage collector has been removed". And their rationale for doing HPC# was more to do with making sure engine logic and user-facing logic was written in the same language.

But it's also not really valid in relation to -betterC, which - as has been mentioned a few times in this thread - is more of a stand-in for "pay what you use of the D runtime" in lieu of DMD actually being able to do that. You don't need -betterC to @nogc and do completely manual memory management for example.

On Sunday, 28 July 2019 at 11:07:51 UTC, Ethan wrote:
> On Sunday, 28 July 2019 at 07:32:37 UTC, Paulo Pinto wrote:
>> For the same reason that C++ needs a C like subset when you want to extract the ultimate performance out of it.
>
> ...are you talking about extern "C" there? Because that's not at all how extern "C" works in a C++ compiler.
>
> I mean, your point in relation to High Performance C# is valid, it's literally "C#, but everything that touches the garbage collector has been removed". And their rationale for doing HPC# was more to do with making sure engine logic and user-facing logic was written in the same language.
>
> But it's also not really valid in relation to -betterC, which - as has been mentioned a few times in this thread - is more of a stand-in for "pay what you use of the D runtime" in lieu of DMD actually being able to do that. You don't need -betterC to @nogc and do completely manual memory management for example.

I am referring to the ISO C89 subset of the ISO C++98 programming language. which is now updated to the ISO C89 + ISO C11 libraries as of ISO C++17, and will be updated to some C90 language constructs like aggregate initializers in ISO C++20.

On Sunday, 28 July 2019 at 12:00:19 UTC, Paulo Pinto wrote:
> I am referring to the ISO C89 subset of the ISO C++98 programming language. which is now updated to the ISO C89 + ISO C11 libraries as of ISO C++17, and will be updated to some C90 language constructs like aggregate initializers in ISO C++20.

Okay, but you understand that C++ was specifically designed as a superset of C, right? It's the exact opposite of my point. C++ added features to C; HPC# and -betterC remove them from their respective languages.

Your point that C is what you use to write faster code than C++ is also misguided. I regularly write much faster code in C++ than I ever could in C thanks to heavy use of inlining and templates. This is even more true historically on (for example) 32-bit Windows systems, where the C ABI was very stack-heavy yet I could use things like __fastcall to call functions with parameters in registers and avoid the stack entirely.

On Saturday, 27 July 2019 at 17:57:07 UTC, Jonathan M Davis wrote:
> I actually think that -betterC is mostly a waste of time, because I don't see enough benefit in using a stripped down version of D over just using C++ to bother, but it definitely can have benefits when porting code, and some people seem to think that it's the way to go, much as I really don't understand that.

I think the main appeal of betterC right now is that it's very portable and offers new opportunities. Want to do web with D? Only BetterC can compile to WebAssembly at the moment. Want to do embedded? Usually only BetterC will be supported. Want to do mobile? In many cases it's betterC only.

On Sunday, 28 July 2019 at 16:13:10 UTC, Ethan wrote:
> On Sunday, 28 July 2019 at 12:00:19 UTC, Paulo Pinto wrote:
>> I am referring to the ISO C89 subset of the ISO C++98 programming language. which is now updated to the ISO C89 + ISO C11 libraries as of ISO C++17, and will be updated to some C90 language constructs like aggregate initializers in ISO C++20.
>
> Okay, but you understand that C++ was specifically designed as a superset of C, right? It's the exact opposite of my point. C++ added features to C; HPC# and -betterC remove them from their respective languages.
>
> Your point that C is what you use to write faster code than C++ is also misguided. I regularly write much faster code in C++ than I ever could in C thanks to heavy use of inlining and templates. This is even more true historically on (for example) 32-bit Windows systems, where the C ABI was very stack-heavy yet I could use things like __fastcall to call functions with parameters in registers and avoid the stack entirely.

So here goes another example, disabling exceptions and RTTI, which is considered UB as per ISO C++ standard, given that the standard assumes those features cannot be turned off and the standard library (as per ISO C++ document) does require them being present.

Or constraing to subsets like Embedded C++ used by Apple's IO Kit.

Disabling exceptions and RTTI, coupled with an alternative library like EASTL, or Embedded C++ existance, do follow the same spirit as HPC# and -betterC.

On Saturday, 27 July 2019 at 14:20:52 UTC, Ethan wrote:

> I've got a related point about the Unity guys writing High Performance C#. If C# is so good, why do you need a subset of it? This exact argument is what I have about -betterC. If D is so good, why do I need a subset of it?

I generally agree and have facetiously referred to betterC as worseD.

betterC is a janky feature added to the compiler because it was too much work to modify the compiler and runtime properly.  You can achieve almost the same think by importing druntime, but not link to it; with a few caveats, that's all betterC does.

Consider the following minimal D program:

--- main.d
void main() { }

Compile with `dmd -release main.d` and you get this:
$ size main
   text    data     bss     dec     hex filename
 526835   53168    2672  582675   8e413 main

Compare that with an equivalent C program:
$ size main
   text    data     bss     dec     hex filename
   1274     512       8    1794     702 main

Whatever D is adding to the binary is probably unnecessary.  In fact, if you modify the above main.d program as...

--- main.d
extern(C) void _d_dso_registry() {}

extern(C) void main() { }

... and then compile and link separate, you get a much more reasonable result:
$ dmd -release -c main.d
$ gcc test.o -o main
$ size main
   text    data     bss     dec     hex filename
   1430     544      16    1990     7c6 main


Seems to be a lot of room for improvement to achieve a pay-as-you-go experience.

There are some of us working to improve the compiler-runtime interface so, hopefully someday, you'll just be able to opt-in to any feature of the language by simply choosing to use it or not.  I welcome others to join in and help.

Mike

On Monday, 29 July 2019 at 00:30:03 UTC, Mike Franklin wrote:

> can achieve almost the same think by importing druntime, but

Yeah, if only computers could actually think.  Of course, I meant thing.

> $ gcc test.o -o main

Should have been `gcc main.o -o main`.

On Sunday, 28 July 2019 at 17:44:38 UTC, Paulo Pinto wrote:
> So here goes another example, disabling exceptions and RTTI, which is considered UB as per ISO C++ standard, given that the standard assumes those features cannot be turned off and the standard library (as per ISO C++ document) does require them being present.
>
> Or constraing to subsets like Embedded C++ used by Apple's IO Kit.
>
> Disabling exceptions and RTTI, coupled with an alternative library like EASTL, or Embedded C++ existance, do follow the same spirit as HPC# and -betterC.

Exceptions basically cost nothing on x64 these days. Structured exception handling hardware support, baybeeeeeee. Leave exceptions on. Either way, if you never try/throw/catch then the code isn't generated.

RTTI as well. Don't have virtuals in your objects? You won't get typeinfo code in your resulting binary. Don't dynamic cast? Compiler won't insert dynamic casts.

This is the "Pay as you go" thing we continually mention in here. Have all the features. Don't use them? Don't pay for them.

Embedded C++, HPC#, and -betterC do not follow this spirit. They are a restrictive subset that for all intents and purposes is a different language made after the fact. Try to use a feature of the full language? Nope, not supported. No pay as you go. Just a compiler error.

EASTL? It does not follow the "pay as you go" spirit. EASTL is a drop-in replacement for STL that followed the API as defined, but replaced the awful memory patterns and added extra methods in to it. Extra methods that showed up in C++ 11 standard. Why are you bringing up EASTL? That thing's ancient history and has known bugs that never got fixed. Had to patch some stuff myself many years ago for a project I was shipping.

On Monday, 29 July 2019 at 15:05:15 UTC, Ethan wrote:
> On Sunday, 28 July 2019 at 17:44:38 UTC, Paulo Pinto wrote:
>> So here goes another example, disabling exceptions and RTTI, which is considered UB as per ISO C++ standard, given that the standard assumes those features cannot be turned off and the standard library (as per ISO C++ document) does require them being present.
>>
>> Or constraing to subsets like Embedded C++ used by Apple's IO Kit.
>>
>> Disabling exceptions and RTTI, coupled with an alternative library like EASTL, or Embedded C++ existance, do follow the same spirit as HPC# and -betterC.
>
> Exceptions basically cost nothing on x64 these days. Structured exception handling hardware support, baybeeeeeee. Leave exceptions on. Either way, if you never try/throw/catch then the code isn't generated.
>
> RTTI as well. Don't have virtuals in your objects? You won't get typeinfo code in your resulting binary. Don't dynamic cast? Compiler won't insert dynamic casts.
>
> This is the "Pay as you go" thing we continually mention in here. Have all the features. Don't use them? Don't pay for them.
>
> Embedded C++, HPC#, and -betterC do not follow this spirit. They are a restrictive subset that for all intents and purposes is a different language made after the fact. Try to use a feature of the full language? Nope, not supported. No pay as you go. Just a compiler error.
>
> EASTL? It does not follow the "pay as you go" spirit. EASTL is a drop-in replacement for STL that followed the API as defined, but replaced the awful memory patterns and added extra methods in to it. Extra methods that showed up in C++ 11 standard. Why are you bringing up EASTL? That thing's ancient history and has known bugs that never got fixed. Had to patch some stuff myself many years ago for a project I was shipping.

To show that also C++ does not follow some high standard that doesn't do language subsets in specific domains.

Good luck having that speech in some C++ communities that use every possible way to "write C with C++ compiler", explicitly turning off compiler features and staying at an arm's length from the standard library.

C++Now, CppCon, NDC and Meeting C++ have plenty of talks how to advocate to those communities.