D as a betterC a game changer ?
Walter Bright
newshound2 at digitalmars.com
Sun Dec 24 22:33:38 UTC 2017
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.
More information about the Digitalmars-d
mailing list