On Monday, 5 February 2018 at 12:41:29 UTC, Jacob Carlborg wrote:
> On 2018-02-05 06:28, Walter Bright wrote:
>
>> True, D cannot directly read .h files. There are tools, though, to convert C .h files to D.
>> 
>> I have thought about building this into D many times, especially since the Digital Mars C compiler is now available since it is Boost licensed.
>
> I did that as an experiment. Embedding DStep in the compiler [1]. It got a mixed response. Some prefer to have it as a separate tool, some prefer to have it built-in. DStep depends on libclang, meaning the compiler would depend on libclang as well.
>
> [1] https://forum.dlang.org/post/ks3kir$1ubq$1@digitalmars.com

I started working on something like this, but not integrated with the compiler. But also not like DStep.

Atila

On Monday, 5 February 2018 at 01:38:13 UTC, psychoticRabbit wrote:
> On Sunday, 4 February 2018 at 20:15:47 UTC, bpr wrote:
>>
>> Which benefits of C are lost?
>>
>
> The ability to program on 16-bit platforms (yeah.. they still exist ;-)

Thanks, that's a good answer!

I did put a bit of effort in trying out betterC (I don't write C these days and it was fun) but I admit I don't program in the 16 bit realm. I'm more interested in HPC than tiny embedded systems, so my concerns are probably different.

On Monday, 5 February 2018 at 12:23:58 UTC, psychoticRabbit wrote:
> No. C++ is primarliy about higher order abstractions. That's why it came about.
> Without the need for those higher order abstractions, C is just fine - no need for C++

Actually, many programmers switched to C++ in the 90s just to get function overloads and inlining without macros.

If you think C is just fine then I'm not sure why you are interested in D.

> The benefits of C, come from C - and only C (and some good compiler writers)

Not sure what you mean by that.

There is little overhead by using C++ over C if you set your project up for that. The only benefits with C these days is portability.

> (depends on what 'many' means)  - There certinaly are 'numerous' (what ever that means) projects trying to create a better c - which contradicts your assertion.

Which ones are you thinking of?

On Sunday, 4 February 2018 at 11:14:43 UTC, JN wrote:
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go.
>>
>
> While not as trivial as just using a dub package, D easy interop with C means you can use C libraries for PDF like libharu or w/e.
>
>> * Are you targeting C developers?
>>
>> Sure BetterC is a way towards that but again, what do you offer more then Rust? I see C developers more going for Rust then D on this point. Or hell even Zig or Jai or whatever 3 letter flavor of the month language.
>>
>
> The problem with flavor of the month languages is that people switch to them, play with them for a bit and abandon them. To quote Bjarne Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses". Languages like D or Java fall into the "get stuff done" category. They don't try to reinvent programming, they don't use the latest abstract higher order category theory union type lambdas, so they are considered boring by the language-hoppers. That's not a flaw of the language.
>
> Personally I agree that BetterC isn't a good alternative for C programmers. Sure, you get some benefits of D, but you will lose many benefits of C and you'll have to constantly fight "wait, can I use this in BetterC or not" kind of thing.

What is the specific purpose of -betterC? I see from <https://dlang.org/spec/betterc.html> that it's (A) useful when targeting constrained environments, and (B) for easier embedding of D libraries into larger projects. But I think I've read elsewhere in this forum that it was specifically useful for the DMD implementation itself.

Is betterC intended to be used for standalone "D -betterC" programs where C might've otherwise been used? My impression of D so far is that it can indeed already be used as a better C by avoiding the GC yourself, or invoking it yourself when appropriate.

It may be useful if that betterc.html page gave a rationale for it; to avoid any confusion on what its intended purpose is.

On 2/5/2018 12:06 AM, Boris-Barboris wrote:
> I think that would be most logical thing to have, but that would also imply preprocessor, or at least it's restricted subset, wich you most probably though about as well.

Sure. I could use the Boost licensed preprocessor in DMC, or the Boost licensed preprocessor in Warp.


>> D has a pretty good chunk of those already built in. The others don't come up very often, and can be done using D's inline assembler.
> 
> I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language.

Most of those gcc builtin's I've never heard of, and I've been programming C for 35 years now. I've also never had a use for them. I find it hard to believe that list would be a deal breaker, especially since much of it seems to be a replacement for the inline assembler, and D has a nice inline assembler.

This is called "checklisting". One lists the features of X culled from the documentation, and then compares it with Y. Inevitably, Y is found wanting. The checklist is never taken from the features of Y, because then X would be wanting :-)

This can be done with virtually any X and Y.

(Also, the builtins are extensions, and are hardly reliably available in any random Standard-conforming C compiler.)

On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
> Most of those gcc builtin's I've never heard of, and I've been programming C for 35 years now. I've also never had a use for them. I find it hard to believe that list would be a deal breaker, especially since much of it seems to be a replacement for the inline assembler, and D has a nice inline assembler.

Inline assembler requires, ghm, assembly. Builtins are a bit more gracious.

I have been dabbling in C for 6 months during OS course about 3 years ago, when I for some reason wanted to have a good understanding of Linux scheduler, and I wrote a toy real-time periodic scheduling class. The code there is swarming with stuff like 'likely\unlikely' and other tricks, wich is understandable, if the importance of it's speed is taken into consideration. The point is, I could use stuff written by people way more experienced than me without writing a single line of assembly, just because it was already there, tested and integrated into the compiler, and there were plenty of examples in other parts of battle-tested code.

"Here is a one-liner wich may make your condition statements faster, if you use it right. Here's how you use it, here's the doc wich teaches how it works under the hood, so you don't cargo cult". Pretty neat in my opinion. Of course you can write it in asm, but you don't need to under gcc.

Oh, and look what I just found:
https://github.com/rust-lang/rust/issues/26179

> This is called "checklisting". One lists the features of X culled from the documentation, and then compares it with Y. Inevitably, Y is found wanting. The checklist is never taken from the features of Y, because then X would be wanting :-)
>
> This can be done with virtually any X and Y.

If Y is not a superset of X, you always lose something when ditching X for Y. No place for miracles under the sun.

> (Also, the builtins are extensions, and are hardly reliably available in any random Standard-conforming C compiler.)

I am of the opinion that currently C has no use outside of OS\embedded stuff (everywhere else it has a superior competitor, imo), and therefore I don't share this concern about C's portability. Well, that, and the fact that I am probably of about half of your age, wich distinguishes the C we know. You probably remember it big\general purpose, but it never was in my days.

Extentions wouldn't emerge, if pure C was enough.

On Monday, February 05, 2018 18:54:32 John Gabriele via Digitalmars-d wrote:
> What is the specific purpose of -betterC? I see from <https://dlang.org/spec/betterc.html> that it's (A) useful when targeting constrained environments, and (B) for easier embedding of D libraries into larger projects. But I think I've read elsewhere in this forum that it was specifically useful for the DMD implementation itself.
>
> Is betterC intended to be used for standalone "D -betterC" programs where C might've otherwise been used? My impression of D so far is that it can indeed already be used as a better C by avoiding the GC yourself, or invoking it yourself when appropriate.
>
> It may be useful if that betterc.html page gave a rationale for it; to avoid any confusion on what its intended purpose is.

Based on Walter's comments, I get the impression that he thinks that the primary benefit of -betterC is to make it easier to port a C program to D, because then you can port it piece by piece rather than having to do it all at once. After that, it's D, and you can ditch -betterC and start taking advantage of the full feature set of D. Certainly, that's all that I would ever consider using -betterC for. I have zero interest in giving up on the features that require druntime. If I were going to consider that, I'd just ditch D for C++. At least then, I'd get a fully featured language even if it isn't as nice as D.

However, there are some folks who like the idea of using -betterC as their primary or only way to use D, because they don't want the runtime for whatever reason. Some of that comes from the fact that it's easier to link against a D library from a C/C++ program when the D library doesn't require the runtime, but I don't think that that's the only reason.

- Jonathan M Davis

On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
> "Here is a one-liner wich may make your condition statements faster, if you use it right.

There is PGO (Profile Guided Optimization) that can do that without additional language extensions. You need to find better example to support your claims.

On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
> much of it seems to be a replacement for the inline assembler, and D has a nice inline assembler.

Inline assembler is not portable and limits optimizing compilers ability to optimize your code. Also assembler is bad at communicating intent but judging from the code both you and Andrei write you do not value the idea of self documenting code with one or two letter variables everywhere in your code.

To write really low level code you need more than what standard C provides because just changing alignment can have huge difference in performance
https://stackoverflow.com/questions/19470873/why-does-gcc-generate-15-20-faster-code-if-i-optimize-for-size-instead-of-speed

On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
> I am of the opinion that currently C has no use outside of OS\embedded stuff....

Plenty of others seems to have a different opinion ;-)

https://github.com/kozross/awesome-c

(and that link is just for starters)