It is a game chager for D, or a least huge step forward  but what is the killer feature against a betterC done through C++ + STL ? Can anyone who really know both D and C++ godlike say why  D as betterC and not C++ as better C? Maybe Andrei or Walter ?

Learning a new language (as opposed to playing with it, which takes hours) takes a lot if investment in time. So please somone help us pople new to it.

1. D BetterC blogs says no RAII.
2. No high level library available. C++ has the whole power of STL which can be used in a better C mode. D has to use only C standard lib. STL gets you covered for a lot. This is *huge* win for C++. I cannot overstate how important this is.
3. No exceptions. (Blessing or curse ?) C++ in a betterC mode
4. saftey. Full saftey is neither D as better C in C++. Arrays ? use STL. Uninit locals varibales ?  good compiler implementation -Wall -Werror.
5. Most C++ features cannot be inhibited with a compiler switch. Oh well. This sucks.
6. No array overflows in D. STL solves this. Design by contract in D and not in C++. Usefull for some projects.
7. Modules. This is big for keeping things neat. Not in C++.
8. metaprogramming. better in D no question about it, even after a couple of days one can see this. Static introspection. Not in C++, but it will come. D wins for now.
9. Easy to port C to D. Should be as easier to port to C++ with saftey features.
10. Ecosystem. C++... the whole computing world rests on a C/C++ titan. A lot of quality code which have run sometimes in exces of 40 years getting mentenance and bug fixes. What is D situation.
11. Sintax. D prolly wins here especially for metaprogramming.
12. Speed of compiles. D is fast to compile needs quantifying. LDC/CLANG not dmd/clang comparisions. same lvel of optimizations. Then you can get an accurate ideea. Speed of compilation is king for bottom up design.
13. Refactors. C++ is meh. Tools arrise to make this easier. How is D here ? Also
great feature for bottom up design.
14. Debugging. How are debugging tools in D compared to C++ ?


>> D as betterC really is a game changer, for anyone who cares to give it a try.
>
> Yes, it really is.
>

On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:
>
> It is a game chager for D, or a least huge step forward  but what is the killer feature against a betterC done through C++ + STL ? Can anyone who really know both D and C++ godlike say why
>  D as betterC and not C++ as better C? Maybe Andrei or Walter ?
>

The motivation behind the -betterC flag is *not* to write new programs in the general case. It's to make it a whole lot easier to a) port existing C code to D and b) enable D code to be used in places where one might otherwise use C. That's hard to do with the full range of D features because of the dependency on DRuntime. By taking away that dependency and treating D solely as a "better C", it becomes much easier.

For example, say you have a program written in C that you'd like to port to D. With -betterC, you can move each function into a D module one at a time, compile to an object file and link in to the program without worrying about linking in DRuntime or creating your own object.d stub. Your program continues to work just as if it were sill all in C. Then, once the program is ported you can start refactoring it to use regular D features. This approach reduces the chance for errors and makes it easier to ensure the program works as it always has.

From that perspective, comparing "D as a better C" to C++ is not appropriate. Comparing regular D (without -betterC) to C++ makes more sense.

That said, some things that currently are not supported in -betterC mode may be in the future. For example, the upcoming 2.078.0 release will add RAII support (including scope(exit))[1] to -betterC mode. Future versions might support exception handling of some kind.

But for new code, D is already a better C without the -betterC flag.

https://dlang.org/changelog/2.078.0.html#raii

On Sunday, 24 December 2017 at 10:57:28 UTC, Mike Parker wrote:
> The motivation behind the -betterC flag is *not* to write new programs in the general case.

Whether you agree or not, that is *exactly* how some programmers would like to use it. I think that's a good thing, and I hope lots of other people do too, and start writing lots of betterC code. Let a thousand flowers bloom.

> From that perspective, comparing "D as a better C" to C++ is not appropriate. Comparing regular D (without -betterC) to C++ makes more sense.

If you think that GCs suck, or at least, that the D GC sucks, then D doesn't fare well in the comparison with C++. Rust might, by that criteria.

I'd have preferred not to have worded it that way, since I don't think GCs suck in general, but it seems there's a big failure to communicate between different camps of programmers, which affects D more than other languages since it is intended to be a very general purpose language, much like C++. GC is not an unqualified positive

> That said, some things that currently are not supported in -betterC mode may be in the future. For example, the upcoming 2.078.0 release will add RAII support (including scope(exit))[1] to -betterC mode. Future versions might support exception handling of some kind.

That's great!

> But for new code, D is already a better C without the -betterC flag.

In general, GCs and runtimes don't compose well, so if you write a D library that you want to be called from a language with its own GC and runtime, that's yet another hoop to jump through. Go might be a better C for some people, but extending Python with Go libraries hasn't caught on. New D libraries written as betterC handle this case.

On 12/24/2017 2:11 AM, Dan Partelly wrote:
> 
> It is a game chager for D, or a least huge step forward  but what is the killer feature against a betterC done through C++ + STL ? Can anyone who really know both D and C++ godlike say why  D as betterC and not C++ as better C? Maybe Andrei or Walter ?

Anyone using C that wanted to move to C++ has already done so. For those left, C++ is not an option for whatever reason.

D is not billed as betterC++ (yet), though Andrei is working on it (essentially building an interface to C++ STL).


> Learning a new language (as opposed to playing with it, which takes hours) takes a lot if investment in time. So please somone help us pople new to it.
> 
> 1. D BetterC blogs says no RAII.

It has RAII now (recently added).


> 2. No high level library available. C++ has the whole power of STL which can be used in a better C mode. D has to use only C standard lib. STL gets you covered for a lot. This is *huge* win for C++. I cannot overstate how important this is.

Most of Phobos is actually workable with betterC, it's just that nobody had gone through and figured out what is.


> 3. No exceptions. (Blessing or curse ?) C++ in a betterC mode

People who use C are not really interested in exceptions. EH adds overhead (there is no such thing as zero cost exceptions).


> 4. saftey. Full saftey is neither D as better C in C++. Arrays ? use STL. Uninit locals varibales ?  good compiler implementation -Wall -Werror.

D as betterC has full safety built in, via dip1000 etc. Experience shows that C is not a safe language, neither is C++, despite STL.


> 5. Most C++ features cannot be inhibited with a compiler switch. Oh well. This sucks.
> 6. No array overflows in D. STL solves this. Design by contract in D and not in C++. Usefull for some projects.

STL solves it only if STL is used. That's a large barrier.

On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:
> On 12/24/2017 2:11 AM, Dan Partelly wrote:

> D is not billed as betterC++ (yet), though Andrei is working on it (essentially building an interface to C++ STL).
>

You piqued my interest. Link?

On Monday, 25 December 2017 at 00:05:07 UTC, 12345swordy wrote:
> On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:
>> On 12/24/2017 2:11 AM, Dan Partelly wrote:
>
>> D is not billed as betterC++ (yet), though Andrei is working on it (essentially building an interface to C++ STL).
>>
>
> You piqued my interest. Link?

I think this is what he's referring to:

http://dconf.org/2017/talks/caciulescu.html
https://youtube.com/watch?v=c5zGnOWKaGo

On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:

>>Most of Phobos is actually workable with betterC, it's just that nobody had gone through >>and figured out what is.

Could you "fix" Phobos so it works out of the box regardless with no GC runtime ? Or at least properly label the each thing whatever it works in "betterC' or not ?

>
>> 3. No exceptions. (Blessing or curse ?) C++ in a betterC mode
>
> People who use C are not really interested in exceptions. EH adds overhead (there is no such thing as zero cost exceptions).
>
>

I disagree:

1. Exceptions can be done "you do not use it, you do not pay for them". Also, compiler switches to diable exceptions totally exist in most compilers.

2. Expceptions can be implemented in such a way that the run-time cost, when used ,is minimal.

3. In several extensive C programs I seen, expception handling was used. A poor man's version implemented with setjmp/longjmp, but neverthless was there. And it was very well used, it was not code done by somone who learned a gimmick and abused it everywhere. It was the sanest way to handle errors in that portion of the code. The use was confined where needed.

4. Windows C compilers long had access to SEH mechanisms. __except{} __finally{}  where might usefull. This is yet another form of exception handling. It was used extensivly by people workin on NT platform. It was even used in kernel code, if you look in kernel you can find handlers for try/finally in a lot of places.  Yes, NT's kernel engineers agreed that in some places it was well worth to pay the run-time cost.

5. When I wrote for unices, the thing I missed most in C as compared to writting in C for NT was SEH support. It really solved some problems very elgantly, and as Im sure you agree __finally is very valuable, after all you put it in D with a different syntax.

On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:

>>> D as betterC really is a game changer, for anyone who cares to give it a try.
>>
>> Yes, it really is.

The fact that -betterC exists is a glaring admission that D "got it wrong".

-betterC was an idea that I heard Walter propose a few years ago, and probably existed in his mind long before that, but has only been actively developed in the past year, maybe two.  AIUI the primary motivation for the current development around -betterC is to use it for DMD's backend, which is still written in C+ (not a typo).  So that begs the rhetorical question:  What did D get so wrong that makes it unsuitable for DMD's backend.  Or more generally, what did D get so wrong that -betterC was required?  Why not fix the language so such things aren't required?

Mike

On Monday, 25 December 2017 at 09:25:46 UTC, Dan Partelly wrote:

>
> 2. Expceptions can be implemented in such a way that the run-time cost, when used ,is minimal.

I did some testing a few years ago with g++ and the ARM Cortex-M platform.  I found that, compared with checking return values, using exceptions improved performance of the no-throw path, but paid a heavy cost for the throw path.  I think that is a useful tradeoff if exceptions are used judiciously.

Mike

On Monday, 25 December 2017 at 10:06:31 UTC, Mike Franklin wrote:
> On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:
>
>>>> D as betterC really is a game changer, for anyone who cares to give it a try.
>>>
>>> Yes, it really is.
>
> The fact that -betterC exists is a glaring admission that D "got it wrong".

I strongly disagree. D got it right, but when there's a heavy investment in an existing code base, there has to be a strong incentive to port to a different language. The less work required to do so, the lower that barrier becomes.

Support for inner classes was motivated by a desire to make porting Java code easier. Support for COFF was motivated by requests to better integrate with existing Windows toolchains. extern(C), extern(C++), -betterC, and a future "Better C++" are all in that vein.

None of this is evidence of anything D got wrong, but rather that the range of excuses for not adopting D is shrinking.