On Friday, 11 April 2014 at 15:54:36 UTC, Jacob Carlborg wrote:
> On 2014-04-11 15:53, monarch_dodra wrote:
>
>> Yeah. It'd say those wouldn't compile anyway, but I guess something as
>> trivial as:
>> //----
>> class A
>> {...}
>> A a;
>> a.doit;
>> //----
>> Would compile for both languages, but give different results.
>>
>> Fine.
>
> Unless "doit" is non-virtual in both versions.

Why? The D version would just go from "object.Error Access Violation" to "AssertError null this".

And in release, you'd still (highly probably) still get the Access Violation.

"monarch_dodra"  wrote in message news:ktbdlcaqahsqmwkiddvc@forum.dlang.org...

> Why? The D version would just go from "object.Error Access Violation" to "AssertError null this".
>
> And in release, you'd still (highly probably) still get the Access Violation.

Sadly I've encountered C++ code that deliberately calls member functions on null class pointers. 

On Friday, 11 April 2014 at 12:38:14 UTC, Daniel Murphy wrote:
> "monarch_dodra"  wrote in message news:rftskgfoeuvyeuvrusei@forum.dlang.org...
>
>> *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.
>
> These expectations will lead to disappointment.

Why everyone here seems to confuse portion with copy and paste?
Of course C++ code that is just copy and pasted will not work or not work as expected.
But I think (hope) that one of the advantage of D is that it allow to easily PORT C/C++ code.
If this is not the case and was really not intended then it is probably better to use C++14 instate.
Other advantage of D could be easy interconnection of C/C++ libraries and D...

On Friday, April 11, 2014 17:00:50 Remo wrote:
> On Friday, 11 April 2014 at 12:38:14 UTC, Daniel Murphy wrote:
> > "monarch_dodra" wrote in message news:rftskgfoeuvyeuvrusei@forum.dlang.org...
> > 
> >> *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.
> > 
> > These expectations will lead to disappointment.
> 
> Why everyone here seems to confuse portion with copy and paste?
> Of course C++ code that is just copy and pasted will not work or
> not work as expected.
> But I think (hope) that one of the advantage of D is that it
> allow to easily PORT C/C++ code.
> If this is not the case and was really not intended then it is
> probably better to use C++14 instate.
> Other advantage of D could be easy interconnection of C/C++
> libraries and D...

How easy it is to port C++ to D depends on what the code does. Some styles of code and types of operations will port over very easily, whereas others would require a fair bit of refactoring. For the most part, the changes that you'd be forced to make would be for the better, but if a lot of your code is doing stuff that doesn't port easily, then it could be painful to port.

Personally, I'd probably rewrite the code in D and just use the C++ as a reference rather than trying to really port it.

- Jonathan M Davis

On 2014-04-11 18:05, monarch_dodra wrote:

> Why? The D version would just go from "object.Error Access Violation" to
> "AssertError null this".

Hmm, I was pretty sure it wouldn't assert.

> And in release, you'd still (highly probably) still get the Access
> Violation.

No, in release mode it's possible to call non-virtual methods on null references.

-- 
/Jacob Carlborg

On Friday, 11 April 2014 at 20:36:12 UTC, Jacob Carlborg wrote:
> On 2014-04-11 18:05, monarch_dodra wrote:
>
>> Why? The D version would just go from "object.Error Access Violation" to
>> "AssertError null this".
>
> Hmm, I was pretty sure it wouldn't assert.
>
>> And in release, you'd still (highly probably) still get the Access
>> Violation.
>
> No, in release mode it's possible to call non-virtual methods on null references.

Right, the call will succeed, but if the function accesses any class members, it will access violation *there*. Hence the "highly likely".

On Saturday, April 12, 2014 02:26:54 Daniel Murphy wrote:
> "monarch_dodra"  wrote in message news:ktbdlcaqahsqmwkiddvc@forum.dlang.org...
> 
> > Why? The D version would just go from "object.Error Access Violation" to "AssertError null this".
> > 
> > And in release, you'd still (highly probably) still get the Access
> > Violation.
> 
> Sadly I've encountered C++ code that deliberately calls member functions on null class pointers.

I've never seen code that it did it on purpose, but I've certainly seen code that did it on accident. And what's really fun is when it's non-virtual, because that won't segfault on the call - only when it does something inside the function which causes the this pointer to be dereferenced (e.g accessing a member variable or virtual member function). _That_ can really confuse people when it happens. At one point at work, we had a class that was never instantiated but worked great (it really didn't need to be a class at all, just free functions, as it didn't actually have any member variables). Fortunately, I'd seen the problem before and could explain to the others once I remembered, but no one else on the team had ever seen anything like it and all found it quite surprising. _I_ was certainly shocked by it when I originally ran into it - though it all makes sense when you look at what the compiler needs to do when calling a function.

- Jonathan M Davis

On 2014-04-11 22:48, monarch_dodra wrote:

> Right, the call will succeed, but if the function accesses any class
> members, it will access violation *there*. Hence the "highly likely".

Yeah, right.

-- 
/Jacob Carlborg

On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
> E.g. it could look like this (alternative a new keyword "explicit" could be introduced, but introduction of new keywords is usually avoided if possible, AFAIK):
sorry for not reading the whole post and necroposting, but please, please, please vote for new keywords! please, stop suggesting obscure features that cannot be logicaly deducted! '@explicit' attribute can work fine here, and 'this(void)' is impossible to understand without carefull *studying* the documentation. and it is really easy to miss when reading the code.

People, why you hates ctors for structs ?

"Default ctor" - simple a workaround.
Just allow ctors with structs and it's all.