On Friday, 2 November 2012 at 22:02:04 UTC, Nick Sabalausky wrote:
> So whenever D is a viable option, I always go for it because I find it to be vastly superior, even to C++11 (which is merely "slightly less crappy than old C++", IMO). And then when I *have* to use C++, I do so while wishing I was doing it in D.

 I remember trying to read and learn C++ years and years ago. Got a headache just trying to read & understand it (2005ish). It felt like it wasn't consistent with C, it was ugly, friend functions never quite made sense, the default 'streams' library should have been written differently (It was originally an example class correct?)

 Let's see what else. Headers, document twice, virtual has to be explicitly declared so inheritance is more limited. Constructors had to be the same name as the class, just a bunch of things that didn't quite seem like they fit right.

 Reading/learning how the STL works they based everything off pointers (which makes some sense) but rather than make a new type and work on that they tried to make that backwards compatible with C, so to use iterators you simulate a pointer.

 I can understand it's limitations on systems back when memory and drive space was scarce, but we're way past that now.

 "Polish a turd, it's still a turd!" -- Peanut

On Fri, 02 Nov 2012 14:53:05 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
> > I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features.
> 
> 
> No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations.

Things I'm not entirely certain about:

No IFTI? No polysemous literals? No finally?

On Friday, 2 November 2012 at 22:47:20 UTC, Nick Sabalausky wrote:
>
> No proper modules. No properties. Slow compilation. No reference
> semantics for classes. No scope guards. Little default initialization.
> Goofy ptr and func-ptr declaration syntax. Goofy rules about what
> is/isn't virtual. Lots of undefined behavior. Forward declarations.
>
> Things I'm not entirely certain about:
>
> No IFTI? No polysemous literals? No finally?

The number one thing I hate the most about D is that because it is so good, the few things that are not so good (or missing) REALLY stand out and make you 10x more upset about them than you should be.

With C++, you learn to accept all the crap and not complain about it so much.

--rt

On 11/02/2012 10:53 PM, Walter Bright wrote:
> On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
>> I said the gap is getting thinner, not that is gone. It got foreach,
>> some form
>> of CTFE, static assert, lambda to mention a few new features.
>
>
> No ranges. No purity. No immutability. No modules. No dynamic closures.
> No mixins. Little CTFE. No slicing. No delegates. No shared. No template
> symbolic arguments. No template string arguments. No alias this.

No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests.

... in no particular order, afaik, and to name a few. :o)

On 11/02/2012 11:47 PM, Nick Sabalausky wrote:
> On Fri, 02 Nov 2012 14:53:05 -0700
> Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
>>> I said the gap is getting thinner, not that is gone. It got
>>> foreach, some form of CTFE, static assert, lambda to mention a few
>>> new features.
>>
>>
>> No ranges. No purity. No immutability. No modules. No dynamic
>> closures. No mixins. Little CTFE. No slicing. No delegates. No
>> shared. No template symbolic arguments. No template string arguments.
>> No alias this.
>
> No proper modules. No properties. Slow compilation.  No reference
> semantics for classes. No scope guards. Little default initialization.
> Goofy ptr and func-ptr declaration syntax. Goofy rules about what
> is/isn't virtual. Lots of undefined behavior. Forward declarations.
>
> Things I'm not entirely certain about:
>
> No IFTI?

IFTI is there.

> No polysemous literals?

If I understand the term right, then 0 is polysemous.

> No finally?
>

Good catch.

Also: No scope guards. No exception root type. No exception chaining, ...

On 11/03/2012 12:05 AM, Rob T wrote:
> With C++, you learn to accept all the crap and not complain about it so much.

Well, it's not so much you learn to accept all the crap as, it's a sufficiently standard tool and so universally adopted, that accepting the crap is often a worthwhile trade for the stuff you get in return (interoperability, range of developers out there who can help you, number of useful libraries ...).

But in my case it's definitely a resigned rather than eager compromise.

I'm currently working on a simulation involving a bipartite graph, which is proving quite a bit of fun, but in the back of my head right now is a little voice going, "Hey, I bet at some point you're going to need one of the general-purpose graph libraries out there and I bet that's going to make it more convenient to do this in C++."  And another voice going "Arrgh no God please don't make me."

Now that said, the question that started this thread seems an apt one and is one I'd been wondering about myself.  I don't have the expertise to write it personally, but I'd be really happy to see an in-depth article comparing C++11 and D, not a paean to one or the other, but a careful description of the advantages and disadvantages of each (preferably supported by code examples).

On Friday, 2 November 2012 at 22:47:20 UTC, Nick Sabalausky wrote:

> No polysemous literals?

Since when D has polysemous literals? Link please.

On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
> On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
>> I said the gap is getting thinner, not that is gone. It got foreach, some form
>> of CTFE, static assert, lambda to mention a few new features.


> No ranges.

Boost.Range


> No purity.

Yeah :(


> No immutability.

Hmm const objects do it sorta-kinda... ok maybe not lol


> No modules.

Apparently these are being considered for the next version!


> No dynamic closures.

Hmm? std::function works just fine with lambdas


> No mixins.

I don't _quite_ miss these ;)


> Little CTFE.

Yeah. :\


> No slicing.

You can sorta-kinda emulate these with iterators.

On the plus side, there's no ambiguity as to value vs. reference semantics in C++.


> No delegates.

std::function?


> No shared.

I don't think many people find themselves using shared in D unfortunately.


> No template symbolic arguments.

I'm not sure I know what this is referring to. Do you mean aliases?


> No template string arguments.

Ah I really miss this in C++...


> No alias this.

While alias this is nice, I don't seem to need it as often in C++ as you'd imagine.

It would come in handy sometimes, to be sure, but it's not a deal breaker IMO.

Regarding delegates - I think deal is that none of this C++ stuff can automatically capture local function context with delegate, so there are no _real_ delegates.

On Saturday, 3 November 2012 at 02:08:13 UTC, Mehrdad wrote:
> On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
>> On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
>>> I said the gap is getting thinner, not that is gone. It got foreach, some form
>>> of CTFE, static assert, lambda to mention a few new features.
>
>
>> No ranges.
>
> Boost.Range
>
>
>> No purity.
>
> Yeah :(
>
>
>> No immutability.
>
> Hmm const objects do it sorta-kinda... ok maybe not lol
>
>
>> No modules.
>
> Apparently these are being considered for the next version!
>
>
>> No dynamic closures.
>
> Hmm? std::function works just fine with lambdas
>
>
>> No mixins.
>
> I don't _quite_ miss these ;)
>
>
>> Little CTFE.
>
> Yeah. :\
>
>
>> No slicing.
>
> You can sorta-kinda emulate these with iterators.
>
> On the plus side, there's no ambiguity as to value vs. reference semantics in C++.
>
>
>> No delegates.
>
> std::function?
>
>
>> No shared.
>
> I don't think many people find themselves using shared in D unfortunately.
>
>
>> No template symbolic arguments.
>
> I'm not sure I know what this is referring to. Do you mean aliases?
>
>
>> No template string arguments.
>
> Ah I really miss this in C++...
>
>
>> No alias this.
>
> While alias this is nice, I don't seem to need it as often in C++ as you'd imagine.
>
> It would come in handy sometimes, to be sure, but it's not a deal breaker IMO.

On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
> Regarding delegates - I think deal is that none of this C++ stuff can automatically capture local function context with delegate, so there are no _real_ delegates.



I don't understand what you mean...

std::function<int(int)> make_adder(int a)
{
	return [=](int b) { return a + b; };
}