View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2006
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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
Re: DMD 0.177 release
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.
7 8 9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home