www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - C++ or D?

reply Mark <forillown cream.pink> writes:
Hi all,

my question would be about using D or not using D. Is the newest 
C++ iteration any good compared to D?

The reason I haven't used C++ anymore for years is that I was too 
naive sometimes. I tried to use new features in Visual C++, found 
myself being like a beta-tester for some things.

And the way C++ was always able to frustrate me is mainly, when 
undefined behavior takes too long to take effect. Sometimes I 
must have had bad luck, or I'm too silly. But for some subtle 
bugs in my hobbyist C++ past the solution would have been to 
rewrite a lot of code. Sometimes it was just too much work to get 
anything done at all.

When I used shared pointers, it got better. But it got a little 
bit ugly, too. And in general, being encouraged or forced to 
write boiler plate code was also frustrating.

I haven't looked into the newest C++. In theory, they might have 
added something helpful in the past years.

Anyone have any thoughts how C++ and D compare?
Nov 09 2020
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:

 Anyone have any thoughts how C++ and D compare?


Broadly speaking: D has a better core language, and C++ has a 
much better library and tooling ecosystem.
Nov 09 2020
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 10, 2020 at 01:00:50AM +0000, Mark via Digitalmars-d-learn wrote:
[...]

 my question would be about using D or not using D. Is the newest C++
 iteration any good compared to D?


[...]

 I haven't looked into the newest C++. In theory, they might have added
 something helpful in the past years.
 
 Anyone have any thoughts how C++ and D compare?


It depends on what you're looking for, what you're trying to do, and
what you expect.

If you're looking for good tooling, top-notch IDE integration, extensive
libraries, etc., then D might not be for you.  That's not to say there
*isn't* good tooling, IDE integration, or libraries; they are there, but
there are rough corners that some people might find frustrating.  Also,
if you're looking for widespread adoption and employment opportunities,
you might find D is not quite there yet.

However, if you're looking for language qualities, like expressive
power, productivity, scalability, ease of writing, ease of maintenance,
metaprogramming, or just general programming language sanity (less
pathological language constructs, gotchas, etc.), I *definitely*
recommend D over C++.  Any day, hands down.

And I say this as an ex-C++ programmer who has renounced C++ almost a
decade ago and never looked back since.  My experience with D has been
so good, I've been totally ruined; I can't stand writing code in any
other language anymore. Every time I have to face C or C++, or worse,
Java, I chafe inside, wishing that I could use this or that D feature.
Don't get me wrong; D has its own share of dark corners and WATs, but
compared to C++, it's a mere scratch vs. a festering, infected wound
that is quickly turning necrotic and requires immediate surgery or
amputation.  Every time I'm forced to work with C++ code I feel an urge
to disinfect my hands with something strong... but all I need is to
write some D and the urge vanishes. ;-)

YMMV, though. :-D


T

-- 
What did the alien say to Schubert? "Take me to your lieder."
Nov 09 2020
prev sibling next sibling parent Guillaume Piolat <first.name guess.com> writes:
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:

 Hi all,

 Anyone have any thoughts how C++ and D compare?



C++ has a bit more mathematical feeling, everything has been 
sorted out in the spec, even if the rules are crazy difficult. D 
feels like it's up to _you_ to write the spec as you discover 
things in the compiler.

C++ code feels a bit more cast in stone than any other language, 
you can't move around things as quickly, and you won't be willing 
to. But as you wrote the lines slower, likely you were a bit more 
careful too as a side-effect.

If you write a small command-line tool, using D vs C++ will be 
appreciably more productive. Just std.process will speed up 
things by a lot, for this kind of work Phobos really shines. I 
don't think it makes the same difference for large projects.

Learning D is something that can be almost finished, whereas with 
C++ you have to aggressively conquer new features from the 
standard one by one, and unfortunately C++ evolves faster than 
you can assimilate C++. Generally when you meet a C++ programmer, 
you are meeting someone who has given up the hope to have a full 
understanding of the language and instead stay strategically on a 
useful, codebase-specific subset (eg: if you learn about 
std:unique_ptr, you can avoid to learn about most of move 
semantics so that's a good learning investment).

D lets you think more about your problem domain, and less about 
language things. Don't know precisely why. If you are deeply 
immersed in C++ everyday, you won't see that problem, but it's 
there. It's as if the culture of C++ was "complexity is free", 
there is little attempt to contain it.

And it shows in the small things, for example:
- D atomics (core.atomic) has 11 public functions and defined 5 
memory models.
- C++ atomics <atomic> has 29 functions and 6 memory models.
It doesn't seem like much, but there is a bit _more of 
everything_ you can count.

All in all as a D replacement C++ seems a bit lacking, unless you 
want a particular domain-specific library that only exists in 
C++. I'm sure with a bit more effort, it could be a bit more 
attractive to the vast masses of D programmers.
Nov 09 2020
prev sibling next sibling parent realhet <real_het hotmail.com> writes:
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:

 Hi all,

 my question would be about using D or not using D.


Here are some things you will NOT get in D:
youtube -> Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- 
Scott Meyers

For example, you will not get neurosis from it, or badly infected 
wounds someone mentioned earlier :D

I also like the fast compile times, and the compile time 
programming, the ability that you can program D in D if you wish.
Nov 09 2020
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:

 I haven't looked into the newest C++. In theory, they might 
 have added something helpful in the past years.


I guess you could say that the latest version of C++ allows you 
to write code that is a little bit less verbose than before. C++ 
itself won't really change drastically because of backwards 
compatibility. In my opinion it is not a suitable language for 
hobbyists, as you need to spend a lot of time with it (measured 
in years) to become proficient... and basically, if you don't use 
C++ on a regular basis, there are details that are easy to 
forget. D has some of those issues too, but D can be used more 
like a high level language.
Nov 11 2020
prev sibling next sibling parent reply hgriffin <grif greenmail.com> writes:
C++ is a really overloaded with features language. The burden of 
backward compatibility and source compatibility with C doesn't 
make it any better. But right now it's the only right choice for 
development. There are plenty of libraries for many common tasks, 
a big community and the most important thing - C++ is evolving. 
Evolution is not as fast as we would want, but it's here.
On the other side, D is really pleasant to work with, it has many 
good features and it can be a really convenient tool for small 
projects. But at the same time it's just not mature and not 
suitable for serious development. If you choose it, you'll face 
with lots of issues without a solution. Nobody from the D 
community would help you other than "just don't use const", "we 
haven't developed a concensus yet", "we can't convince Walter", 
etc. You can look at the D's evolution history and approximate it 
into the future. Years go by, nothing's changing. It's 
stagnating. The biggest D's problem is poor management and it's 
not going to change in any foreseeable time.
Nov 12 2020
parent reply Godnyx <rempas tutanota.com> writes:
On Thursday, 12 November 2020 at 09:35:10 UTC, hgriffin wrote:

 C++ is a really overloaded with features language. The burden 
 of backward compatibility and source compatibility with C 
 doesn't make it any better. But right now it's the only right 
 choice for development. There are plenty of libraries for many 
 common tasks, a big community and the most important thing - 
 C++ is evolving. Evolution is not as fast as we would want, but 
 it's here.
 On the other side, D is really pleasant to work with, it has 
 many good features and it can be a really convenient tool for 
 small projects. But at the same time it's just not mature and 
 not suitable for serious development. If you choose it, you'll 
 face with lots of issues without a solution. Nobody from the D 
 community would help you other than "just don't use const", "we 
 haven't developed a concensus yet", "we can't convince Walter", 
 etc. You can look at the D's evolution history and approximate 
 it into the future. Years go by, nothing's changing. It's 
 stagnating. The biggest D's problem is poor management and it's 
 not going to change in any foreseeable time.


Hi! Can you be more specific about the problems someone is gonna 
face with D that can't be fixed? This is very important for me 
because I'm planning to use D for development in the near (I wish 
near) future and I want to know what's going on. So yeah some 
examples will be appreciated!
Dec 19 2020
parent reply frame <frame86 live.com> writes:
On Saturday, 19 December 2020 at 09:06:33 UTC, Godnyx wrote:

 Hi! Can you be more specific about the problems someone is 
 gonna face with D that can't be fixed? This is very important 
 for me because I'm planning to use D for development in the 
 near (I wish near) future and I want to know what's going on. 
 So yeah some examples will be appreciated!


It's not the problem mentioned but I had to struggle with DLLs 
and D's Variant-type. The problem is that Variant uses TypeInfo 
which does not pass DLL boundaries correctly so that int != int 
in runtime even it's in fact a simple int.

If you need to exchange unknown data between a DLL and your 
application you need to get a workaround and cannot use that 
elsewhere settled nice feature. But it's a Windows specific issue 
- it works as expected on other systems.
Dec 23 2020
parent reply evilrat <evilrat666 gmail.com> writes:
On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with DLLs 
 and D's Variant-type. The problem is that Variant uses TypeInfo 
 which does not pass DLL boundaries correctly so that int != int 
 in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use that 
 elsewhere settled nice feature. But it's a Windows specific 
 issue - it works as expected on other systems.


Which is basically same as in C++, despite the fact it does have 
real working SO/DLL runtime's many large projects have their own 
RTTI implementation. LLVM has its own RTTI because standard type 
info is "inefficient", Unreal Engine has its own, IIRC Qt too has 
its own, etc...

Same thing with D Variant, some people say it is "inefficient"... 
so we ended up having multiple libraries.

Not saying anything about how good or bad all this, just the 
facts.
Dec 23 2020
parent reply RSY <rsy_881 gmail.com> writes:
On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with DLLs 
 and D's Variant-type. The problem is that Variant uses 
 TypeInfo which does not pass DLL boundaries correctly so that 
 int != int in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use that 
 elsewhere settled nice feature. But it's a Windows specific 
 issue - it works as expected on other systems.


 Which is basically same as in C++, despite the fact it does 
 have real working SO/DLL runtime's many large projects have 
 their own RTTI implementation. LLVM has its own RTTI because 
 standard type info is "inefficient", Unreal Engine has its own, 
 IIRC Qt too has its own, etc...

 Same thing with D Variant, some people say it is 
 "inefficient"... so we ended up having multiple libraries.

 Not saying anything about how good or bad all this, just the 
 facts.


C++ you need to write duplicate code (.h and .cpp)

C++ you need to care about header include order

C++ you need to forward declare everything you gonna use if it is 
not included before

C++ you need to waste time waiting for compile

C++ you need to fight to get proper reflection


D is much more superior to C++ in my opinion, proper package 
manager, great compile time, great module system, great interop 
with C and C++

You can use GC, you can disable it, you can use malloc, it suits 
all your need!

Can't find a lib? use a C or C++ one, that is what makes D so 
much powerfull, you don't have to give up on other ecosystem, you 
can embrace them in your project
Dec 24 2020
next sibling parent sighoya <sighoya gmail.com> writes:
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 You can use GC, you can disable it, you can use malloc, it 
 suits all your need!


Not to forget the availability of refcounted (shared) and unique 
ptr too in D.
Dec 25 2020
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with 
 DLLs and D's Variant-type. The problem is that Variant uses 
 TypeInfo which does not pass DLL boundaries correctly so that 
 int != int in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use that 
 elsewhere settled nice feature. But it's a Windows specific 
 issue - it works as expected on other systems.


 Which is basically same as in C++, despite the fact it does 
 have real working SO/DLL runtime's many large projects have 
 their own RTTI implementation. LLVM has its own RTTI because 
 standard type info is "inefficient", Unreal Engine has its 
 own, IIRC Qt too has its own, etc...

 Same thing with D Variant, some people say it is 
 "inefficient"... so we ended up having multiple libraries.

 Not saying anything about how good or bad all this, just the 
 facts.


 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if it 
 is not included before

 C++ you need to waste time waiting for compile


Fixed with C++20 modules.

I am already playing with the experimental support on VC++.


 C++ you need to fight to get proper reflection


Coming in C++23, and partially available already with a mix of 
type traits and constexpr.


I am all good for D vs C++, but one needs to update their 
knowledge specially when the audience is up to date with latest 
ISO C++'s capabilities.
Dec 30 2020
next sibling parent reply RSY <rsy_881 gmail.com> writes:
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote:

 On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with 
 DLLs and D's Variant-type. The problem is that Variant uses 
 TypeInfo which does not pass DLL boundaries correctly so 
 that int != int in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use that 
 elsewhere settled nice feature. But it's a Windows specific 
 issue - it works as expected on other systems.


 Which is basically same as in C++, despite the fact it does 
 have real working SO/DLL runtime's many large projects have 
 their own RTTI implementation. LLVM has its own RTTI because 
 standard type info is "inefficient", Unreal Engine has its 
 own, IIRC Qt too has its own, etc...

 Same thing with D Variant, some people say it is 
 "inefficient"... so we ended up having multiple libraries.

 Not saying anything about how good or bad all this, just the 
 facts.


 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if it 
 is not included before

 C++ you need to waste time waiting for compile


 Fixed with C++20 modules.

 I am already playing with the experimental support on VC++.


 C++ you need to fight to get proper reflection


 Coming in C++23, and partially available already with a mix of 
 type traits and constexpr.


 I am all good for D vs C++, but one needs to update their 
 knowledge specially when the audience is up to date with latest 
 ISO C++'s capabilities.


and you still have the predeclaration issue, since the whole 
process is done 1 way

and this is the summary of the whole C++ has X, but it is either 
half backed, or just plain bloated

you can't say c++ will have module without saying it is 
implemented poorly, you still have the dirty and ugly quirks

D module system remains superior because the whole experience is 
just plain superior and more sane
Dec 30 2020
parent RSY <rsy_881 gmail.com> writes:
On Thursday, 31 December 2020 at 07:07:04 UTC, RSY wrote:

 On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto 
 wrote:

 On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with 
 DLLs and D's Variant-type. The problem is that Variant uses 
 TypeInfo which does not pass DLL boundaries correctly so 
 that int != int in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use 
 that elsewhere settled nice feature. But it's a Windows 
 specific issue - it works as expected on other systems.


 Which is basically same as in C++, despite the fact it does 
 have real working SO/DLL runtime's many large projects have 
 their own RTTI implementation. LLVM has its own RTTI because 
 standard type info is "inefficient", Unreal Engine has its 
 own, IIRC Qt too has its own, etc...

 Same thing with D Variant, some people say it is 
 "inefficient"... so we ended up having multiple libraries.

 Not saying anything about how good or bad all this, just the 
 facts.


 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if 
 it is not included before

 C++ you need to waste time waiting for compile


 Fixed with C++20 modules.

 I am already playing with the experimental support on VC++.


 C++ you need to fight to get proper reflection


 Coming in C++23, and partially available already with a mix of 
 type traits and constexpr.


 I am all good for D vs C++, but one needs to update their 
 knowledge specially when the audience is up to date with 
 latest ISO C++'s capabilities.


 and you still have the predeclaration issue, since the whole 
 process is done 1 way

 and this is the summary of the whole C++ has X, but it is 
 either half backed, or just plain bloated

 you can't say c++ will have module without saying it is 
 implemented poorly, you still have the dirty and ugly quirks

 D module system remains superior because the whole experience 
 is just plain superior and more sane


And you can't say C++23 will have Y therfore it is a reasonable 
choice TODAY

No, it's either you have it or you don't, everyone can implement 
Z, even Rust borrow checker, that doesn't make language 0 
relevant when you compare solutions TODAY

And even more when you take into account that D is interopable 
with both C/C++

Invalidating D, just because X Y Z will have K and have poorly 
implemented N, is very unfortunate, BAD, and plain SAD, because 
you just don't care about what D has to offer when you take into 
account the whole feature set
Dec 30 2020
prev sibling parent reply RSY <rsy_881 gmail.com> writes:
On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote:

 On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote:

 It's not the problem mentioned but I had to struggle with 
 DLLs and D's Variant-type. The problem is that Variant uses 
 TypeInfo which does not pass DLL boundaries correctly so 
 that int != int in runtime even it's in fact a simple int.

 If you need to exchange unknown data between a DLL and your 
 application you need to get a workaround and cannot use that 
 elsewhere settled nice feature. But it's a Windows specific 
 issue - it works as expected on other systems.


 Which is basically same as in C++, despite the fact it does 
 have real working SO/DLL runtime's many large projects have 
 their own RTTI implementation. LLVM has its own RTTI because 
 standard type info is "inefficient", Unreal Engine has its 
 own, IIRC Qt too has its own, etc...

 Same thing with D Variant, some people say it is 
 "inefficient"... so we ended up having multiple libraries.

 Not saying anything about how good or bad all this, just the 
 facts.


 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if it 
 is not included before

 C++ you need to waste time waiting for compile


 Fixed with C++20 modules.

 I am already playing with the experimental support on VC++.


 C++ you need to fight to get proper reflection


 Coming in C++23, and partially available already with a mix of 
 type traits and constexpr.


 I am all good for D vs C++, but one needs to update their 
 knowledge specially when the audience is up to date with latest 
 ISO C++'s capabilities.


It's like the story with the GC

You want everyone to like D because it has a GC despite it being 
not updated in ages, and proved to not scale well

You do the same with modules and reflections now, D is clearly 
better but for some reasons you don't want people to believe 
that, worse you want people to see them as inferior to the poor 
C++ one, because you clearly didn't mention any of that poor 1 
phase compilation model

What is your goal here? you for sure don't want D to take off
Dec 30 2020
next sibling parent reply RSY <rsy_881 gmail.com> writes:
C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if it 
 is not included before

 C++ you need to waste time waiting for compile


Fixed with C++20 modules.


---


He said fixed with c++20 modules, when you still have to 
predeclare everything, as it is was a better solution

LOL, i can't believe it, bad worm
Dec 30 2020
parent reply RSY <rsy_881 gmail.com> writes:
On Thursday, 31 December 2020 at 07:23:17 UTC, RSY wrote:

 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if it 
 is not included before

 C++ you need to waste time waiting for compile


 Fixed with C++20 modules.


 ---


 He said fixed with c++20 modules, when you still have to 
 predeclare everything, as it is was a better solution

 LOL, i can't believe it, bad worm



```
export module app;

export int main()
{
     say_hi();
}


void say_hi()
{
     printf("hi\n");
}
```


//  error C3861: 'say_hi': identifier not found

Ohhhh it doesn't compile, it doesn't know what say_hi is, wow 
great c++ module system

Clearly supperior to D /s
Dec 30 2020
parent reply RSY <rsy_881 gmail.com> writes:
Sorry for the spam, but this is because of people like him that 
people like me (i discovered D recently) that can't be aware of 
why D is a great language

They diminish all arguments that makes D better than alternatives


You guys have to help me fight that kind of behavior, because it 
doesn't help D, as if it was their goal, do they want to make 
sure D doesn't eat specific market share, so some other language 
can? fishy fishy
Dec 30 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote:

 Sorry for the spam, but this is because of people like him that 
 people like me (i discovered D recently) that can't be aware of 
 why D is a great language

 They diminish all arguments that makes D better than 
 alternatives


 You guys have to help me fight that kind of behavior, because 
 it doesn't help D, as if it was their goal, do they want to 
 make sure D doesn't eat specific market share, so some other 
 language can? fishy fishy


I have found that these kinds of language wars often get nowhere. 
Just use D and be happy and let others use C++ and let them be 
happy. But they should be aware that C++ *as a language* has a 
long way to go before it gets all the features etc that D has. 
Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, 
but not for me.
Dec 31 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote:

 On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: 
 nowhere. Just use D and be happy and let others use C++ and let 
 them be happy. But they should be aware that C++ *as a 
 language* has a long way to go before it gets all the features 
 etc that D has. Maybe 2023, maybe 2027, who knows. Maybe that's 
 fine for them, but not for me.


Which features are you most concerned about? I think the feature 
set is quite similar. D is less verbose and is easier to use for 
high level programming, but the clang++ and g++ have fewer bugs 
and quirks than the D compilers. The biggest difference is that 
C++ cannot change much, but D can!  D really ought to make more 
of that advantage... More streamlining even if it breaks stuff.
Dec 31 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 31 December 2020 at 11:29:55 UTC, Ola Fosheim 
Grostad wrote:

 On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote:

 On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote: 
 nowhere. Just use D and be happy and let others use C++ and 
 let them be happy. But they should be aware that C++ *as a 
 language* has a long way to go before it gets all the features 
 etc that D has. Maybe 2023, maybe 2027, who knows. Maybe 
 that's fine for them, but not for me.


 Which features are you most concerned about? I think the 
 feature set is quite similar. D is less verbose and is easier 
 to use for high level programming, but the clang++ and g++ have 
 fewer bugs and quirks than the D compilers. The biggest 
 difference is that C++ cannot change much, but D can!  D really 
 ought to make more of that advantage... More streamlining even 
 if it breaks stuff.


I was a bit unclear. I meant features as in built in language 
constructs etc, not necessarily like keywords and so on.

Hmm, regarding features I'd like in C++, maybe better 
metaprogramming and fewer keywords? Haven't thought about that

https://github.com/AnthonyCalandra/modern-cpp-features
Dec 31 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 18:13:40 UTC, Imperatorn wrote:

 I was a bit unclear. I meant features as in built in language 
 constructs etc, not necessarily like keywords and so on.


You mean like associative arrays and dynamic arrays? If so then I 
guess people have different taste, I think it was a mistake to 
make those builtins...

I find code harder to read when symbols (e.g. "!") have so many 
meanings in D. I am creating my own experimental unicode-syntax 
now where each symbol has only one meaning... kinda like a 
prototype for testing the idea of using the full unicode charset 
for programming. So not necessarily a D specific issue, but D is 
a nice testbed for experimenting as it has so many features.


 Hmm, regarding features I'd like in C++, maybe better 
 metaprogramming and fewer keywords? Haven't thought about that


I've never run into meta programming problems that I cannot deal 
with in C++ in way that works out ok in the end, but sometimes 
you have to search the web. Fortunately there are many "recipes" 
for big languages... without that... uhm. Then C++ would be a 
very difficult thing to handle :-D.

What I don't like about C++ is that things get verbose, but 
verbosity has some advantages when programs get very large 
because then you need more context to understand what is going on 
and where things are coming from.

It isn't obvious that something that is good for a medium sized 
program will be good for a very large program (e.g. "where did 
this symbol come from?"). You won't really find out until you've 
tried... but most D programs are small, so. No need to worry 
about that...
Dec 31 2020
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote:

 On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote:

 Sorry for the spam, but this is because of people like him 
 that people like me (i discovered D recently) that can't be 
 aware of why D is a great language

 They diminish all arguments that makes D better than 
 alternatives


 You guys have to help me fight that kind of behavior, because 
 it doesn't help D, as if it was their goal, do they want to 
 make sure D doesn't eat specific market share, so some other 
 language can? fishy fishy


 But they should be aware that C++ *as a language* has a long 
 way to go before it gets all the features etc that D has. Maybe 
 2023, maybe 2027, who knows. Maybe that's fine for them, but 
 not for me.


Au contraire; I find that C++ has modernised relatively 
successful and has a lot of great proposals in the pipeline. Of 
course they may all get rejected, but even if only some of them 
get accepted, C++ starts to have a leg up on D in my opinion.

It could take a few years indeed, but what will D do in that same 
time window?
Dec 31 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe 
wrote:

 It could take a few years indeed, but what will D do in that 
 same time window?


What would you like to see?
Dec 31 2020
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe 
 wrote:

 It could take a few years indeed, but what will D do in that 
 same time window?


 What would you like to see?


For shared to mean something.
Stackless coroutines.
Compile-time lifetime management, i.e. better ways to define 
ownership.
Dec 31 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe 
wrote:

 On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim 
 Grøstad wrote:

 What would you like to see?


 For shared to mean something.
 Stackless coroutines.
 Compile-time lifetime management, i.e. better ways to define 
 ownership.


I second that. At least some way to know whether a pointer takes 
ownership (GC/RC) or just is an auxiliary reference.
Dec 31 2020
parent reply RSY <rsy_881 gmail.com> writes:
On Thursday, 31 December 2020 at 19:57:53 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe 
 wrote:

 On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim 
 Grøstad wrote:

 What would you like to see?


 For shared to mean something.
 Stackless coroutines.
 Compile-time lifetime management, i.e. better ways to define 
 ownership.


 I second that. At least some way to know whether a pointer 
 takes ownership (GC/RC) or just is an auxiliary reference.


i agree with this, C++ has GC, smart pointer and even some 
facilities for ownership via various move semantic

that is an area where D could improve, but that would be catch up 
with C++..

one big move would be to finally put the allocators out of 
std.experimental, and finally embrace this everywhere (just like 
ziglang)
Jan 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:

 one big move would be to finally put the allocators out of 
 std.experimental, and finally embrace this everywhere (just 
 like ziglang)


I am bit torn on this, the less the compiler knows about 
allocation strategies, the less opportunity there are for the 
compiler to be smart about allocations. So, those things ought to 
be language constructs, not library constructs.

At least if D is going to stay in the lane of high level 
programming. (Zig is firmly staking ground in the manual-labour 
department, as far as I can tell.)
Jan 01 2021
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 1 January 2021 at 15:12:43 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote:

 one big move would be to finally put the allocators out of 
 std.experimental, and finally embrace this everywhere (just 
 like ziglang)


 I am bit torn on this, the less the compiler knows about 
 allocation strategies, the less opportunity there are for the 
 compiler to be smart about allocations. So, those things ought 
 to be language constructs, not library constructs.

 At least if D is going to stay in the lane of high level 
 programming. (Zig is firmly staking ground in the manual-labour 
 department, as far as I can tell.)


Slightly off but also on topic but, has there been any general 
consensus yet around standard pointer types (e.g. shared_ptr) and 
standard allocator-aware data structures, or just in general any 
discussions around non-GC memory management as part of 
Phobos/core parts of D outside of "use/write a library"?

(And for completely off-topic: What are the plans for 
std.experimental packages right now? Is std.experimental.logging 
just going to sit there until the end of time?)
Jan 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 1 January 2021 at 16:23:45 UTC, SealabJaster wrote:

 Slightly off but also on topic but, has there been any general 
 consensus yet around standard pointer types (e.g. shared_ptr) 
 and standard allocator-aware data structures, or just in 
 general any discussions around non-GC memory management as part 
 of Phobos/core parts of D outside of "use/write a library"?


I don't know anything about any official positions other than the 
fact that Walter dislikes having more than one pointer type and 
is working on some kind of "liveness" verification for a C-style 
free/malloc regime, which is rather rare in other languages these 
days. Not really sure how that fits with modern code bases.

Isn't there some work on move-semantics to make C++ interfacing 
better? But shared_ptr is only for C++ interop, perhaps? Or is it 
meant for D-code?

To me it looks like things are a bit up-in-the-air at the moment.

And well, having many options that are incompatible would not be 
good for library interop, so choices have to be made to avoid 
"tower of Babel".

*shrugs*
Jan 01 2021
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 1 January 2021 at 16:45:16 UTC, Ola Fosheim Grøstad 
wrote:

 I don't know anything about any official positions other than 
 the fact that Walter dislikes having more than one pointer type 
 and is working on some kind of "liveness" verification for a 
 C-style free/malloc regime, which is rather rare in other 
 languages these days. Not really sure how that fits with modern 
 code bases.

 Isn't there some work on move-semantics to make C++ interfacing 
 better? But shared_ptr is only for C++ interop, perhaps? Or is 
 it meant for D-code?

 To me it looks like things are a bit up-in-the-air at the 
 moment.


Unsurprising answers unfortunately :(

As for the move-semantics, I know that DIP 1014 was accepted, but 
I don't know anything beyond that (haven't really looked into it 
at all tbh).


 And well, having many options that are incompatible would not 
 be good for library interop, so choices have to be made to 
 avoid "tower of Babel".


This is a concern of mine, especially when D touts about the GC 
being optional, but I do have doubts about any ground being made 
on this front, either in discussions, decisions, or 
implementations, within the next year or two.

Meanwhile I believe C++ (keep in mind I very rarely touch or look 
at C++) already has a standard allocator interface that parts of 
the STL (and I assume libraries, when/if they care) are able to 
use? I'm unaware of the issues it might have in C++, but that's 
mostly because of my lack of use and knowledge of the language. 
It has standard pointer types, etc.

I wonder what problems D faces in comparison to C++ and other 
languages in this regard, since it's been in a limbo, fragmented 
state for a while now.
Jan 01 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote:

 Meanwhile I believe C++ (keep in mind I very rarely touch or 
 look at C++) already has a standard allocator interface that 
 parts of the STL (and I assume libraries, when/if they care) 
 are able to use? I'm unaware of the issues it might have in 
 C++, but that's mostly because of my lack of use and knowledge 
 of the language. It has standard pointer types, etc.


So, C++ had the same issues as D prior to C++11, that you had 
many many different options, but none of them were standard... 
Which was ok if you used one big framework, but if you wanted to 
mix libraries... yuck. Since C++11 things are looking better 
although it obviously takes time for frameworks/libraries to 
catch up.

In C++ everything is up to the library/programmer so there is 
basically no way for the compiler to be particularly clever with 
heap allocations, although it can be clever with values (e.g. 
stack allocations).  So, that is an area where D could be bold 
make the compiler smart, and do better than C++, but that takes 
some courage.

C++ smart pointers do allow for custom allocators, but then the 
owning pointers will have an extra field for referencing it, 
which is used for deallocation. I suspect most people don't use 
it, but it might be important for creating nice C++ wrappers for 
C libraries?


 I wonder what problems D faces in comparison to C++ and other 
 languages in this regard, since it's been in a limbo, 
 fragmented state for a while now.


Mostly a lack of strategic decision making? Just map out the 
various alternatives and pick a combination that is "wholesome".

(Do you want to be a bird and fly or a fish that can swim? Being 
neither bird nor fish isn't working in the long run, I don't 
think so.)
Jan 01 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 31 December 2020 at 14:56:37 UTC, Sebastiaan Koppe 
wrote:

 On Thursday, 31 December 2020 at 09:57:01 UTC, Imperatorn wrote:

 On Thursday, 31 December 2020 at 07:32:31 UTC, RSY wrote:

 [...]


 But they should be aware that C++ *as a language* has a long 
 way to go before it gets all the features etc that D has. 
 Maybe 2023, maybe 2027, who knows. Maybe that's fine for them, 
 but not for me.


 Au contraire; I find that C++ has modernised relatively 
 successful and has a lot of great proposals in the pipeline. Of 
 course they may all get rejected, but even if only some of them 
 get accepted, C++ starts to have a leg up on D in my opinion.

 It could take a few years indeed, but what will D do in that 
 same time window?


That's true, but until that happens D is superior. Time will tell 
😊
Dec 31 2020
prev sibling next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote:

 It's like the story with the GC

 You want everyone to like D because it has a GC despite it 
 being not updated in ages, and proved to not scale well


Fun fact: the c++ GC Oilpan ( used in Chrome ) has more features 
than the one in D...
Dec 30 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote:

 On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto 
 wrote:

 On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote:

 On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote:

 [...]


 C++ you need to write duplicate code (.h and .cpp)

 C++ you need to care about header include order

 C++ you need to forward declare everything you gonna use if 
 it is not included before

 C++ you need to waste time waiting for compile


 Fixed with C++20 modules.

 I am already playing with the experimental support on VC++.


 C++ you need to fight to get proper reflection


 Coming in C++23, and partially available already with a mix of 
 type traits and constexpr.


 I am all good for D vs C++, but one needs to update their 
 knowledge specially when the audience is up to date with 
 latest ISO C++'s capabilities.


 It's like the story with the GC

 You want everyone to like D because it has a GC despite it 
 being not updated in ages, and proved to not scale well

 You do the same with modules and reflections now, D is clearly 
 better but for some reasons you don't want people to believe 
 that, worse you want people to see them as inferior to the poor 
 C++ one, because you clearly didn't mention any of that poor 1 
 phase compilation model

 What is your goal here? you for sure don't want D to take off


It would be nice to see D taking off, I just happen not to be 
blind to the competition.

That is the beauty of being an enterprise polyglot consultant, I 
get to pick what customers want, and they want eco-systems and 
platforms.

Which not only use GC in domains that D fails to, also get to 
catch up with almost every feature that made D a better choice 10 
years ago.

Blind advocacy won't get new users.
Jan 01 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:

 Hi all,

 my question would be about using D or not using D. Is the 
 newest C++ iteration any good compared to D?

 [...]


https://ibb.co/syQRs9v
Dec 29 2020
parent reply Rekel <paultjeadriaanse gmail.com> writes:
On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:

 https://ibb.co/syQRs9v


I hope I'm not the only one that thinks 'designers and std lib 
writers unable to name anything correctly' is kind of ironic.
And don't get me started on documentation return values.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 14:17:38 UTC, Rekel wrote:

 On Tuesday, 29 December 2020 at 16:13:50 UTC, Imperatorn wrote:

 https://ibb.co/syQRs9v


 I hope I'm not the only one that thinks 'designers and std lib 
 writers unable to name anything correctly' is kind of ironic.
 And don't get me started on documentation return values.


Most of the statements are wrong too...

"Forgot null terminator": that is C, not C++.

"undecidable grammer": wrong, not context free != undecidable

"can't execute arbitrary functions at compile time": same as D, 
more or less

"4732 features, but not a single one you actually want": wrong 
again, C++20 has features that people would like to see in D

"unsatisfying standard library": not really, unless you need to 
avoid exceptions

"template metaprogramming only capable of being understood by 
mensa member": some aspects of C++20 metaprogramming is easier 
than D

"multiple-inheritance hell": no idea what this means, MI is 
usually used for the same as D interfaces

"iterators": and ranges...

Anyway, bashing C++ does not get D anywhere. At best it makes D 
users look uninformed.
Dec 30 2020
parent reply sighoya <sighoya gmail.com> writes:
On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim 
Grøstad wrote:

 Most of the statements are wrong too...
 "4732 features, but not a single one you actually want": wrong 
 again, C++20 has features that people would like to see in D


Could you elaborate a bit more, please? I'm interested.


 "unsatisfying standard library": not really, unless you need to 
 avoid exceptions

 "template metaprogramming only capable of being understood by 
 mensa member": some aspects of C++20 metaprogramming is easier 
 than D


That would me interest, too!


 "multiple-inheritance hell": no idea what this means, MI is 
 usually used for the same as D interfaces


Just to say, I think not including multiple inheritance was a 
mistake for Java and all its descendants, though not a big one.

Multiple inheritance needs just a good convention, that's all.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 18:24:41 UTC, sighoya wrote:

 On Wednesday, 30 December 2020 at 14:41:28 UTC, Ola Fosheim 
 Grøstad wrote:

 Most of the statements are wrong too...
 "4732 features, but not a single one you actually want": wrong 
 again, C++20 has features that people would like to see in D


 Could you elaborate a bit more, please? I'm interested.


Some people in the D community has for a long time wanted 
stack-less coroutines. This is now available in C++20, and maybe 
D can borrow the C++ implementation for LDC? That is an 
interesting possibility for sure.


 "template metaprogramming only capable of being understood by 
 mensa member": some aspects of C++20 metaprogramming is easier 
 than D


 That would me interest, too!


The main addition for C++20 is concepts. Basically wrapping up 
ugly tests in a simple template parameter type specifier so that 
you can specify that a template parameter MUST support Addition 
or be a Stack or whatever you want to require with very simple 
syntax. (It also makes it easier to specify tests.)

Btw, did D ever get to add nested template parameters? I know 
people asked for it a long time ago, but cannot remember if that 
was resolved somehow?


 Just to say, I think not including multiple inheritance was a 
 mistake for Java and all its descendants, though not a big one.

 Multiple inheritance needs just a good convention, that's all.


I almost never use multiple inheritance myself, but if you don't 
use it, it does not affect you at all? So how could it be a 
problem to have the option? *shrugs*
Dec 30 2020
parent reply sighoya <sighoya gmail.com> writes:
On Wednesday, 30 December 2020 at 18:45:03 UTC, Ola Fosheim 
Grøstad wrote:

 Some people in the D community has for a long time wanted 
 stack-less coroutines. This is now available in C++20, and 
 maybe D can borrow the C++ implementation for LDC? That is an 
 interesting possibility for sure.


Hmm, I don't know much about them, but it seems they are a 
restriction to stackful coroutines, maybe a keyword addition like 
 stackless to prohibit nested suspension does the trick?


 The main addition for C++20 is concepts. Basically wrapping up 
 ugly tests in a simple template parameter type specifier so 
 that you can specify that a template parameter MUST support 
 Addition or be a Stack or whatever you want to require with 
 very simple syntax. (It also makes it easier to specify tests.)


In my eyes, adding proper support for opImplicitCoercion enables 
the reuse of interfaces as typeclasses, yielding more potential 
for idiomatic development than utilizing C++ concepts alone.


 Btw, did D ever get to add nested template parameters? I know 
 people asked for it a long time ago, but cannot remember if 
 that was resolved somehow?


Oh, what's this? Did you mean true Higher Kinded Types (HKT)

```
fun(R,S,T:R=>S)
```

That would be great, but they're simply arguing to use alias 
symbols instead. The downside with aliases is however a more 
restricted type inference:

https://github.com/dlang/DIPs/blob/bf5157d3dc29a591826e22d188448fbc04ca81b2/DIPs/DIP1023.md
https://forum.dlang.org/thread/dnyqxmgdazczwmmvayjx forum.dlang.org?page=4



 I almost never use multiple inheritance myself, but if you 
 don't use it, it does not affect you at all? So how could it be 
 a problem to have the option? *shrugs*


It's right, at least theoretically, practically you are often 
forced to use the feature in order to utilize the functionality 
you need.

But the more general point against this was the clash of fields 
and methods. However, this is akin to the problem with generic 
specialization, and likewise it can be solved by simply defining 
a new default instance, that's it.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 19:24:19 UTC, sighoya wrote:

 In my eyes, adding proper support for opImplicitCoercion 
 enables the reuse of interfaces as typeclasses, yielding more 
 potential for idiomatic development than utilizing C++ concepts 
 alone.


Not sure what you mean? A D interface is a dynamic runtime 
feature?



 Btw, did D ever get to add nested template parameters? I know 
 people asked for it a long time ago, but cannot remember if 
 that was resolved somehow?


 Oh, what's this? Did you mean true Higher Kinded Types (HKT)

 ```
 fun(R,S,T:R=>S)
 ```



Sort of, in C++ it would be something like this

template<template<typename> class OuterName>
void myfunction(OuterName<int> x){ stuff(); }



 That would be great, but they're simply arguing to use alias 
 symbols instead. The downside with aliases is however a more 
 restricted type inference:


That is clearly a type unification bug. An alias isn't an alias 
if it interferes with type unification!
Dec 30 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 30 December 2020 at 19:51:07 UTC, Ola Fosheim 
Grøstad wrote:

 [snip]

 Sort of, in C++ it would be something like this

 template<template<typename> class OuterName>
 void myfunction(OuterName<int> x){ stuff(); }

 [snip]


You mean like this

struct Foo(T)
{
     T x;
}

void foo(T : Foo!V, V)(T x) {
     import std.stdio: writeln;
     writeln("here");
}

void main() {
     Foo!int x;
     foo(x);
}
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 20:42:49 UTC, jmh530 wrote:

 You mean like this

 struct Foo(T)
 {
     T x;
 }

 void foo(T : Foo!V, V)(T x) {



Not quite, "Foo" would be a template parameter, so something like 
this (which does not work, but maybe there is some other way to 
express it?):


struct Foo(T)
{
     T x;
}


void foo(T)(T!int x) {
     import std.stdio: writeln;
     writeln("here");
}

void main() {
     Foo!int x;
     foo(x);
}
Dec 30 2020
parent reply sighoya <sighoya gmail.com> writes:
On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim 
Grøstad wrote:

(which does not work, but maybe there is some other
 way to express it?):


See: 
https://forum.dlang.org/thread/ooxzbrmbrzpsefirosor forum.dlang.org?page=1
Dec 30 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 21:17:25 UTC, sighoya wrote:

 On Wednesday, 30 December 2020 at 21:12:43 UTC, Ola Fosheim 
 Grøstad wrote:

(which does not work, but maybe there is some other
 way to express it?):


 See: 
 https://forum.dlang.org/thread/ooxzbrmbrzpsefirosor forum.dlang.org?page=1


Ok, so basically just add alias:

void foo(alias T)(T!int x) {

Ok. :)
Dec 30 2020