On 02/03/2011 07:00 PM, Steven Schveighoffer wrote:
On Thu, 03 Feb 2011 12:52:28 -0500, spir wrote:
Side-questions: is it written somewhere dmd interns string literals? If yes,
where? Is this supposed to be part of D's spec or an implementation aspect of
dmd?
String literals are immutable,
On Thu, 03 Feb 2011 12:52:28 -0500, spir wrote:
Side-questions: is it written somewhere dmd interns string literals? If
yes, where? Is this supposed to be part of D's spec or an implementation
aspect of dmd?
String literals are immutable, which means the compiler is free to re-use
them
On 02/03/2011 02:27 PM, Steven Schveighoffer wrote:
On Wed, 02 Feb 2011 11:35:50 -0500, spir wrote:
On 02/02/2011 04:20 PM, Lars T. Kyllingstad wrote:
I think the compiler does a bitwise comparison in this case, meaning that
it compares the arrays' pointers instead of their data. Related bu
On Wed, 02 Feb 2011 11:35:50 -0500, spir wrote:
On 02/02/2011 04:20 PM, Lars T. Kyllingstad wrote:
I think the compiler does a bitwise comparison in this case, meaning
that
it compares the arrays' pointers instead of their data. Related bug
report:
Thank you, Lars.
In fact, I do not rea
On 02/03/2011 09:09 AM, Lars T. Kyllingstad wrote:
On Wed, 02 Feb 2011 17:35:50 +0100, spir wrote:
On 02/02/2011 04:20 PM, Lars T. Kyllingstad wrote:
On Wed, 02 Feb 2011 15:55:53 +0100, spir wrote:
Hello,
What are the default semantics for '==' on structs?
I ask this because I was forced t
On Wed, 02 Feb 2011 17:35:50 +0100, spir wrote:
> On 02/02/2011 04:20 PM, Lars T. Kyllingstad wrote:
>> On Wed, 02 Feb 2011 15:55:53 +0100, spir wrote:
>>
>>> Hello,
>>>
>>> What are the default semantics for '==' on structs?
>>>
>>> I ask this because I was forced to write opEquals on a struct to
> The bug report is about arrays too, of course. I will write this bug report.
http://d.puremagic.com/issues/show_bug.cgi?id=5519
Bye,
bearophile
spir:
> And if we fix string, then the case of regular arrays becomes inconsistent.
The bug report is about arrays too, of course. I will write this bug report.
Bye,
bearophile
On 02/02/2011 08:20 PM, bearophile wrote:
spir:
Do you know more about why/how the above fails?
It's simple. A string (or array) is a 2-words long struct that contains a
pointer to the data and a size_t length. Default struct equality just compares
the bits of those two fields. In the above
On 02/02/2011 07:41 PM, spir wrote:
On 02/02/2011 07:05 PM, bearophile wrote:
spir:
* The issue reported is about '==' on structs not using member opEquals when
defined, instead performing bitwise comparison. This is not my case: Lexeme
members are plain strings and an uint. They should just b
spir:
> Do you know more about why/how the above fails?
It's simple. A string (or array) is a 2-words long struct that contains a
pointer to the data and a size_t length. Default struct equality just compares
the bits of those two fields. In the above example I have created f1 and f2
using two
On 02/02/2011 07:09 PM, bearophile wrote:
Lars is right, the == among structs is broken still:
If necessary please open a new bug report, this is an important bug.
Bye,
bearophile
Right, reduced the bug cases I found to:
struct S {string s;}
unittest {
// concat
string s1 = "he"; st
On 02/02/2011 07:09 PM, bearophile wrote:
Lars is right, the == among structs is broken still:
If necessary please open a new bug report, this is an important bug.
Right, i'll do it when (hopefully) I understand more about the details of
why/how '==' fails in my case.
Denis
--
On 02/02/2011 07:05 PM, bearophile wrote:
spir:
* The issue reported is about '==' on structs not using member opEquals when
defined, instead performing bitwise comparison. This is not my case: Lexeme
members are plain strings and an uint. They should just be compared as is.
Bitwise comparison
> Lars is right, the == among structs is broken still:
If necessary please open a new bug report, this is an important bug.
Bye,
bearophile
On 02/02/2011 05:49 PM, Andrej Mitrovic wrote:
What is Ordinal defined as? If it's a uint, I get the expected results:
alias uint Ordinal;
struct Lexeme {
string tag;
string slice;
Ordinal index;
}
void main()
{
auto lex1 = Lexeme("a","b",1);
auto lex2 = Lexeme("a","b",1)
spir:
> * The issue reported is about '==' on structs not using member opEquals when
> defined, instead performing bitwise comparison. This is not my case: Lexeme
> members are plain strings and an uint. They should just be compared as is.
> Bitwise comparison should just work fine.
> Also, thi
What is Ordinal defined as? If it's a uint, I get the expected results:
alias uint Ordinal;
struct Lexeme {
string tag;
string slice;
Ordinal index;
}
void main()
{
auto lex1 = Lexeme("a","b",1);
auto lex2 = Lexeme("a","b",1);
assert(lex1 == lex2);
assert(lex1 == Lexeme
On 02/02/2011 04:20 PM, Lars T. Kyllingstad wrote:
On Wed, 02 Feb 2011 15:55:53 +0100, spir wrote:
Hello,
What are the default semantics for '==' on structs?
I ask this because I was forced to write opEquals on a struct to get
expected behaviour. This struct is basically:
struct Lexeme {
On Wed, 02 Feb 2011 15:55:53 +0100, spir wrote:
> Hello,
>
> What are the default semantics for '==' on structs?
>
> I ask this because I was forced to write opEquals on a struct to get
> expected behaviour. This struct is basically:
>
> struct Lexeme {
> string tag;
> string slice;
>
Hello,
What are the default semantics for '==' on structs?
I ask this because I was forced to write opEquals on a struct to get expected
behaviour. This struct is basically:
struct Lexeme {
string tag;
string slice;
Ordinal index;
}
Equal Lexeme's compare unequal using default '=
21 matches
Mail list logo
