On Tuesday, November 17, 2015 20:25:30 user123ABCabc via Digitalmars-d-learn
wrote:
> On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
> > if (typeid(a) == typeid(b)) return a.opEquals(b);
>
> Wow this is terrible to compare two objects in D. The line I
> quoted means that two
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
On 11/17/2015 12:40 AM, MichaelZ wrote:
> In http://dlang.org/operatoroverloading.html#eqcmp it is
stated that
>
> "If opEquals is not specified, the compiler provides a
default version
> that does member-wise comparison."
>
>
On 11/17/15 3:25 PM, user123ABCabc wrote:
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I quoted
means that two TypeInfoClass are likely to be allocated, right ?
On 11/17/2015 12:40 AM, MichaelZ wrote:
> In http://dlang.org/operatoroverloading.html#eqcmp it is stated that
>
> "If opEquals is not specified, the compiler provides a default version
> that does member-wise comparison."
>
> However, doesn't this only apply to structs, and not objects?
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I
quoted means that two TypeInfoClass are likely to be allocated,
right ?
But usually when comparing objects one
In http://dlang.org/operatoroverloading.html#eqcmp it is stated
that
"If opEquals is not specified, the compiler provides a default
version that does member-wise comparison."
However, doesn't this only apply to structs, and not objects?
The default behaviour of opEquals for objects seems
