>>> Use LDC (D1), you will note a significant improvement over DMD.
>>>
>> Unless you're on windows.
>>
>
> Yep, second big problem.
And unless you're using CodeBlocks (like me at the moment) for
development ...
Use LDC (D1), you will note a significant improvement over DMD.
Unless you're on windows.
Yep, second big problem.
"bearophile" wrote in message
news:hkpiai$2kt...@digitalmars.com...
> Scorn:
>> The only things i figured out so far is that functions across modules do
>> not seem to get inlined (i don't know if this is the case in general)
>> which would be really bad. Another thing which i believe is that
>>
bearophile schrieb:
> Scorn:
>> The only things i figured out so far is that functions across modules do
>> not seem to get inlined (i don't know if this is the case in general)
>> which would be really bad. Another thing which i believe is that
>> functions / methods which contain ref parameters a
Use LDC (D1), you will note a significant improvement over DMD.
I believe that, but... D1.
Also LDC doesn't seem to get much attention (development-wise) recently.
Scorn:
> The only things i figured out so far is that functions across modules do
> not seem to get inlined (i don't know if this is the case in general)
> which would be really bad. Another thing which i believe is that
> functions / methods which contain ref parameters are never inlined at
> all
Yes, I intentionally duped the string to make sure they're not using the
same memory. I was thinking of something like a transitive ==.
Overload opEquals.
On 2/8/10 13:48, Trass3r wrote:
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to compare
the members. If I use "is" to compare the structs it could use "is" to
compare them members.
Structs are compared *bitwise*
On 2/8/10 14:58, Pelle Månsson wrote:
On 02/08/2010 01:48 PM, Trass3r wrote:
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to compare
the members. If I use "is" to compare the structs it could use "is" to
compare
Trass3r schrieb:
> Would be interesting.
Yes, this would be very interesting indeed. A list of the rules which
dmd uses internally for inlining functions and methods similiar to this
(which is for .NET)
http://blogs.msdn.com/ericgu/archive/2004/01/29/64717.aspx
would be really nice. Sure you ca
Would be interesting.
I believe the question was *why* things are this way. I think it's weird.
It's common behavior. In the end structs are just a way to map a memory
range to some variable tuple.
If you really need == for all members you can always overload opEquals!!
On 02/08/2010 01:48 PM, Trass3r wrote:
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to compare
the members. If I use "is" to compare the structs it could use "is" to
compare them members.
Structs are compared *b
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to compare
the members. If I use "is" to compare the structs it could use "is" to
compare them members.
Structs are compared *bitwise*!
When you dup your pointer
Am Mon, 08 Feb 2010 12:19:12 +0100
schrieb Jacob Carlborg :
> struct String
> {
> char[] data;
> }
>
> void main ()
> {
> auto foo = String("foo");
> auto bar = String("foo".dup);
>
> assert(bar == foo);
> }
>
> Why isn't == used to compare the struct members in the code
struct String
{
char[] data;
}
void main ()
{
auto foo = String("foo");
auto bar = String("foo".dup);
assert(bar == foo);
}
Why isn't == used to compare the struct members in the code above? I
mean, if I compare the structs with == it could also use == to compar
Don Wrote:
> Wow, seems like you and the compiler are at war...
>
I had an even more horrid dmd crash some time ago, removing a circular
selective import seemed to fix it. But I'm not sure and can't replicate it any
more :(
>
> Please put this into bugzilla. Title "ICE(interpret.c): mixin non
strtr wrote:
strtr Wrote:
enum { E };
void _mixin() {
writefln( E.stringof );
}
void func() {
mixin(_mixin);
}
Assertion failure: '!dim || (parameters && (parameters->dim == dim))' on line
140 in file 'interpret.c'
At least I got a line number this time :)
Wow, seems like yo
18 matches
Mail list logo
