December 12, 2006
Alexander Panek wrote:
> Ivan Senji wrote:
>> Boris Kolar wrote:
>>> PS: I really appreciate all the work that has been put in D. D is going
>>> to be a much needed successor of C++. I don't see D as competitor to
>>> Java or C# (I think that when using .NET or JVM is an option, D would
>>> be a terrible choice), but it sure can rock the non-VM world!
>>
>> Why not? I think that D could rock the .NET world too. I always wished
>> (and still do) for a d.net implementation.
> 
> ..NET is not the solution for all problems. 

Naturally. That is why we are here (using D).

> There will be other library approaches that maybe even perform better and use features of D that make it like .NET on steroids. I bet after some time of an official, fixed D 1.0 specification, there will some libraries pop up that may serve needs like .NET or J2EE and what not do, also.

I sure hope so.
What I was trying to say programming in .NET is sometimes required and in those cases i would prefer D rather than C# or (even worse) VB.

> 
> Apart from that.. hey, you're posting this in the official D newsgroup ;) .

Is that a problem? :)
December 12, 2006
Jarrett Billingsley wrote:
<snip>
> Yes, I guess that's true.  But if a simple addition i.e.
> 
> x = a + b;
> 
> Compiled to
> 
> mov _TEMP1, a
> mov _TEMP2, b
> add _TEMP1, _TEMP2
> mov x, _TEMP1
> 
> Instead of
> 
> mov x, a
> add x, b
> 
> It'd still be semantically correct, but would it make sense?

Almost. I could see it generate the following code (with optimizations turned off):
  mov _TEMP, a
  add _TEMP, b
  mov x, _TEMP
where a, b and x are memory locations and _TEMP is a register. On x86, you can't add the contents of two memory locations, at least one of the values needs to be in a register.
With optimizations on, of course, the variables might be stored in registers instead of memory. If so, your proposed code would be legal.
December 12, 2006
Ivan Senji wrote:
> Alexander Panek wrote:
>> Ivan Senji wrote:
>>> Boris Kolar wrote:
>>>> PS: I really appreciate all the work that has been put in D. D is going
>>>> to be a much needed successor of C++. I don't see D as competitor to
>>>> Java or C# (I think that when using .NET or JVM is an option, D would
>>>> be a terrible choice), but it sure can rock the non-VM world!
>>>
>>> Why not? I think that D could rock the .NET world too. I always wished
>>> (and still do) for a d.net implementation.
>>
>> ..NET is not the solution for all problems. 
> 
> Naturally. That is why we are here (using D).

Exacteley!

> 
>> There will be other library approaches that maybe even perform better and use features of D that make it like .NET on steroids. I bet after some time of an official, fixed D 1.0 specification, there will some libraries pop up that may serve needs like .NET or J2EE and what not do, also.
> 
> I sure hope so.
> What I was trying to say programming in .NET is sometimes required and in those cases i would prefer D rather than C# or (even worse) VB.
> 

Are you, actually, talking about a D -> MSIL compiler, so it can be run inside the VM and a .NET implementation in D, for that purpose? Or do you mean something /similar/ to C# + .NET? If so, I agree. Something like that has to be in D. :) I hope this will pop up

>>
>> Apart from that.. hey, you're posting this in the official D newsgroup ;) .
> 
> Is that a problem? :)

Of course not. Was just a side-kick regarding your "I want .NET in D" statement :) .

Kind regards,
Alex
December 13, 2006
Stewart Gordon wrote:
> Walter Bright wrote:
>> I don't think that'll work. He'll wind up being forced to set all the fields.
> Doesn't follow - there might not be any to set other than those that are
> an inherent part of the assignment operation.

But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.
December 13, 2006
Pragma wrote:
> That's better, but look at what's really happening here.  Inlining and compiler optimization aside, the 'constructor' here creates a Foo on the stack which is then returned and *copied* to the destination 'f'.

That problem was solved 15 years ago (for C and C++). I admit that due to sloth I had failed to implement the solution yet in dmd, but it is implemented now and will go out in the next update. There will be NO extra copies.

For whatever the merits of opCall vs this(), efficiency is NOT a problem with either, and is not a reason to choose one or the other. The generated code is the same.

Under the hood, they are the same. Both take a hidden pointer to where the result is stored. The rest is window dressing.
December 13, 2006
Don thanks for clarifying the reason, I didn't know about the function pointers still using 'b' after bool replaced bit. It all now makes a lot more sense as to the why change happened the way it did.

David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

"Don Clugston" <dac@nospam.com.au> wrote in message news:elho1o$t1d$1@digitaldaemon.com...
> David L. Davis wrote:
>> Walter in dmd v0.176 you improved name mangling, but I've found one very confusing change...is it your intension to reuse the "b" which used to mean "bit," to now mean a "bool" instead of "x?"
>
>> For example, one function "real vdb(real, real, real, real, real, real,
>> bool = false)" used in my financial D dll,
>> before dmd v0.148 was released when the "bool" data type was added
>> (replacing the "bit" data type) the function's mangled name was
>> "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the
>> "bit" data type become an alias to bool and all the "b" (for "bit") were
>> replaced with "x" (for "bool"), thus the funtion's mangled name changed
>> to become "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has
>> been replaced by "b," is this a mistake on your part, or have you decided
>> to use a "b" as meaning a "bool" (discarding "x")?
>
> Between 0.148 and 0.175, function pointers used 'b' for 'bool', but the functions themselves used 'x'. It was a bit inconsistent.


December 13, 2006
Walter Bright wrote:
> Under the hood, they are the same. Both take a hidden pointer to where the result is stored. The rest is window dressing.

That means you can't return the result in a register :o).

Andrei
December 13, 2006
Alexander Panek wrote:
> Ivan Senji wrote:
>> I sure hope so.
>> What I was trying to say programming in .NET is sometimes required and
>> in those cases i would prefer D rather than C# or (even worse) VB.
>>
> 
> Are you, actually, talking about a D -> MSIL compiler, so it can be run inside the VM and a .NET implementation in D, for that purpose? Or do you mean something /similar/ to C# + .NET? If so, I agree. Something like that has to be in D. :) I hope this will pop up

Actually I really was talking about a D->MSIL compiler for those cases when you just have to use .net and would still prefer other benefits of D. But the other thing would be great too.

> 
>>>
>>> Apart from that.. hey, you're posting this in the official D newsgroup ;) .
>>
>> Is that a problem? :)
> 
> Of course not. Was just a side-kick regarding your "I want .NET in D" statement :) .

:P
December 13, 2006
Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> Under the hood, they are the same. Both take a hidden pointer to where the result is stored. The rest is window dressing.
> 
> That means you can't return the result in a register :o).

That talk can stay on comp.lang.c++.moderated, thank you very much ;-)


Sean
December 13, 2006
Walter Bright wrote:
> Stewart Gordon wrote:
>> Walter Bright wrote:
>>> I don't think that'll work. He'll wind up being forced to set all the fields.
>> Doesn't follow - there might not be any to set other than those that are
>> an inherent part of the assignment operation.
> 
> But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.

Exactly.  *If* there are other fields that shouldn't be set.  Do you even understand a word of what Chris is proposing?

The programmer would have a choice - opAssign returning void to modify in-place the object referenced by the lvalue, or returning a new object that will be assigned to the lvalue.  What is this precluding?

Stewart.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19