Jump to page: 1 25  
Page
Thread overview
November 10
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?
November 10
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.
November 09
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."
November 10
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.
November 10
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.
November 11
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.


November 12
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.

December 19
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!
December 23
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.

December 23
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.
« First   ‹ Prev
1 2 3 4 5