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 example I have created f1 and f2
using two strings that have the same contents and lengths, but the pointers are
different, because they are generated at run-time (normally the compiler uses a
pool of shared string literals), so the equality fails.
I have asked Walter to fix this problem with strings and arrays probably three
years ago or more, it's not a new problem :-)
All right, you mean string literals are interned? Explaining why the case below
works...
struct S {string s;}
unittest {
// plainly equal members
string s01 = "hello"; string s02 = "hello";
assert ( S(s01) == S(s02) );
}
... because s01 & s02 are actually the same, unique, piece of data in memory
(thus pointers are equal indeed)?
I'm ok to write another bug report as you asked. But since you've asked for
this already, and there is bug#3433 on a very similar topic supposedly closed
as well, I fear it's useless, don't you?
And if we fix string, then the case of regular arrays becomes inconsistent.
The code issue about clear semantics, I guess, is that the case above works
*due to* an implementation detail. The rest is just annoying (need to write
opequals to get expected semantics in 99% cases, probably), but /not/ inconsistent.
Denis
--
_________________
vita es estrany
spir.wikidot.com
