Why equality check for instance of Struct/Class are different?












1















I don't understand the difference between struct and class equality check. Since both Struct and Class gets their #hash from Kernel but they seem to behave differently.



I know that instance.hash will produce a different result for each class instance. Struct instance has different ancestors [Customer, Struct, Enumerable, Object, Kernel, BasicObject] compare to Class instance [Foo, Object, Kernel, BasicObject]. What really caused each Class instance to have a different hash number to othe



Customer = Struct.new(:name, :phone, :address) do

end

class Foo
def initialize(the_name, phone, address)
@name = the_name
@phone = phone
@address = address
end
end


str_a = Customer.new('bond', 'ring', 'address')
str_b = Customer.new('bond', 'ring', 'address')

foo_a = Foo.new('bond', 'ring', 'address')
foo_b = Foo.new('bond', 'ring', 'address')

p str_a == str_b #true
p foo_a == foo_b #false

p str_a.hash # 4473040617195177332
p str_b.hash # 4473040617195177332
p foo_a.hash # -3118151143418428190
p foo_b.hash # -1042397847400824657

p str_a.method(:hash).owner #Kernel
p foo_a.method(:hash).owner #Kernel


both Struct and Class use Kernel for its hash_number generation. Why do a different instance of Class produce different hash int but Struct instance would produce the same hash int?










share|improve this question





























    1















    I don't understand the difference between struct and class equality check. Since both Struct and Class gets their #hash from Kernel but they seem to behave differently.



    I know that instance.hash will produce a different result for each class instance. Struct instance has different ancestors [Customer, Struct, Enumerable, Object, Kernel, BasicObject] compare to Class instance [Foo, Object, Kernel, BasicObject]. What really caused each Class instance to have a different hash number to othe



    Customer = Struct.new(:name, :phone, :address) do

    end

    class Foo
    def initialize(the_name, phone, address)
    @name = the_name
    @phone = phone
    @address = address
    end
    end


    str_a = Customer.new('bond', 'ring', 'address')
    str_b = Customer.new('bond', 'ring', 'address')

    foo_a = Foo.new('bond', 'ring', 'address')
    foo_b = Foo.new('bond', 'ring', 'address')

    p str_a == str_b #true
    p foo_a == foo_b #false

    p str_a.hash # 4473040617195177332
    p str_b.hash # 4473040617195177332
    p foo_a.hash # -3118151143418428190
    p foo_b.hash # -1042397847400824657

    p str_a.method(:hash).owner #Kernel
    p foo_a.method(:hash).owner #Kernel


    both Struct and Class use Kernel for its hash_number generation. Why do a different instance of Class produce different hash int but Struct instance would produce the same hash int?










    share|improve this question



























      1












      1








      1








      I don't understand the difference between struct and class equality check. Since both Struct and Class gets their #hash from Kernel but they seem to behave differently.



      I know that instance.hash will produce a different result for each class instance. Struct instance has different ancestors [Customer, Struct, Enumerable, Object, Kernel, BasicObject] compare to Class instance [Foo, Object, Kernel, BasicObject]. What really caused each Class instance to have a different hash number to othe



      Customer = Struct.new(:name, :phone, :address) do

      end

      class Foo
      def initialize(the_name, phone, address)
      @name = the_name
      @phone = phone
      @address = address
      end
      end


      str_a = Customer.new('bond', 'ring', 'address')
      str_b = Customer.new('bond', 'ring', 'address')

      foo_a = Foo.new('bond', 'ring', 'address')
      foo_b = Foo.new('bond', 'ring', 'address')

      p str_a == str_b #true
      p foo_a == foo_b #false

      p str_a.hash # 4473040617195177332
      p str_b.hash # 4473040617195177332
      p foo_a.hash # -3118151143418428190
      p foo_b.hash # -1042397847400824657

      p str_a.method(:hash).owner #Kernel
      p foo_a.method(:hash).owner #Kernel


      both Struct and Class use Kernel for its hash_number generation. Why do a different instance of Class produce different hash int but Struct instance would produce the same hash int?










      share|improve this question
















      I don't understand the difference between struct and class equality check. Since both Struct and Class gets their #hash from Kernel but they seem to behave differently.



      I know that instance.hash will produce a different result for each class instance. Struct instance has different ancestors [Customer, Struct, Enumerable, Object, Kernel, BasicObject] compare to Class instance [Foo, Object, Kernel, BasicObject]. What really caused each Class instance to have a different hash number to othe



      Customer = Struct.new(:name, :phone, :address) do

      end

      class Foo
      def initialize(the_name, phone, address)
      @name = the_name
      @phone = phone
      @address = address
      end
      end


      str_a = Customer.new('bond', 'ring', 'address')
      str_b = Customer.new('bond', 'ring', 'address')

      foo_a = Foo.new('bond', 'ring', 'address')
      foo_b = Foo.new('bond', 'ring', 'address')

      p str_a == str_b #true
      p foo_a == foo_b #false

      p str_a.hash # 4473040617195177332
      p str_b.hash # 4473040617195177332
      p foo_a.hash # -3118151143418428190
      p foo_b.hash # -1042397847400824657

      p str_a.method(:hash).owner #Kernel
      p foo_a.method(:hash).owner #Kernel


      both Struct and Class use Kernel for its hash_number generation. Why do a different instance of Class produce different hash int but Struct instance would produce the same hash int?







      ruby struct equality class-instance-variables






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 1 at 0:42









      anothermh

      3,29831632




      3,29831632










      asked Dec 31 '18 at 23:22









      MorboRe'MorboRe'

      597




      597
























          1 Answer
          1






          active

          oldest

          votes


















          3














          I believe the answer you're looking for is found in the Struct documentation



          Equality—Returns true if other has the same struct subclass 
          and has equal member values (according to Object#==).


          Your example has equal member values for str_a and str_b, and they have the same subclass (Customer), so they are equal when compared with ==



          Contrast this with the Object documentation



          Equality — At the Object level, == returns true only if 
          obj and other are the same object. Typically, this method is
          overridden in descendant classes to provide class-specific meaning.


          In your example, foo_a and foo_b are not the same object (because they're not the same instance)



          If you're seeking why these are different, I didn't really answer that question. Just that the behavior is as intended per the docs. They don't actually have the same ID:



          pry >> Bar = Struct.new(:name) do; end
          => Bar < Struct
          pry >> x = Bar.new
          => #<Struct:Bar:0x7f8ebca47610
          name = nil

          pry >> y = Bar.new
          => #<Struct:Bar:0x7f8ebca14058
          name = nil

          pry >> x.name = "foo"
          => "foo"
          pry >> y.name = "foo"
          => "foo"
          pry >> x
          => #<Struct:Bar:0x7f8ebca47610
          name = "foo"

          pry >> y
          => #<Struct:Bar:0x7f8ebca14058
          name = "foo"


          But, you'll note comparison is based on attributes, rather than the object ID:



          pry >> x == y
          => true


          Even though the object id's are different:



          pry >> x.__id__
          => 70125513489160
          pry >> y.__id__
          => 70125513383980





          share|improve this answer


























          • I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

            – MorboRe'
            Dec 31 '18 at 23:47











          • I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

            – MorboRe'
            Dec 31 '18 at 23:53






          • 1





            They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

            – Holger Just
            Jan 1 at 11:49











          • @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

            – Jay Dorsey
            Jan 2 at 14:08











          • interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

            – MorboRe'
            Jan 3 at 9:50













          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992097%2fwhy-equality-check-for-instance-of-struct-class-are-different%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          I believe the answer you're looking for is found in the Struct documentation



          Equality—Returns true if other has the same struct subclass 
          and has equal member values (according to Object#==).


          Your example has equal member values for str_a and str_b, and they have the same subclass (Customer), so they are equal when compared with ==



          Contrast this with the Object documentation



          Equality — At the Object level, == returns true only if 
          obj and other are the same object. Typically, this method is
          overridden in descendant classes to provide class-specific meaning.


          In your example, foo_a and foo_b are not the same object (because they're not the same instance)



          If you're seeking why these are different, I didn't really answer that question. Just that the behavior is as intended per the docs. They don't actually have the same ID:



          pry >> Bar = Struct.new(:name) do; end
          => Bar < Struct
          pry >> x = Bar.new
          => #<Struct:Bar:0x7f8ebca47610
          name = nil

          pry >> y = Bar.new
          => #<Struct:Bar:0x7f8ebca14058
          name = nil

          pry >> x.name = "foo"
          => "foo"
          pry >> y.name = "foo"
          => "foo"
          pry >> x
          => #<Struct:Bar:0x7f8ebca47610
          name = "foo"

          pry >> y
          => #<Struct:Bar:0x7f8ebca14058
          name = "foo"


          But, you'll note comparison is based on attributes, rather than the object ID:



          pry >> x == y
          => true


          Even though the object id's are different:



          pry >> x.__id__
          => 70125513489160
          pry >> y.__id__
          => 70125513383980





          share|improve this answer


























          • I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

            – MorboRe'
            Dec 31 '18 at 23:47











          • I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

            – MorboRe'
            Dec 31 '18 at 23:53






          • 1





            They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

            – Holger Just
            Jan 1 at 11:49











          • @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

            – Jay Dorsey
            Jan 2 at 14:08











          • interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

            – MorboRe'
            Jan 3 at 9:50


















          3














          I believe the answer you're looking for is found in the Struct documentation



          Equality—Returns true if other has the same struct subclass 
          and has equal member values (according to Object#==).


          Your example has equal member values for str_a and str_b, and they have the same subclass (Customer), so they are equal when compared with ==



          Contrast this with the Object documentation



          Equality — At the Object level, == returns true only if 
          obj and other are the same object. Typically, this method is
          overridden in descendant classes to provide class-specific meaning.


          In your example, foo_a and foo_b are not the same object (because they're not the same instance)



          If you're seeking why these are different, I didn't really answer that question. Just that the behavior is as intended per the docs. They don't actually have the same ID:



          pry >> Bar = Struct.new(:name) do; end
          => Bar < Struct
          pry >> x = Bar.new
          => #<Struct:Bar:0x7f8ebca47610
          name = nil

          pry >> y = Bar.new
          => #<Struct:Bar:0x7f8ebca14058
          name = nil

          pry >> x.name = "foo"
          => "foo"
          pry >> y.name = "foo"
          => "foo"
          pry >> x
          => #<Struct:Bar:0x7f8ebca47610
          name = "foo"

          pry >> y
          => #<Struct:Bar:0x7f8ebca14058
          name = "foo"


          But, you'll note comparison is based on attributes, rather than the object ID:



          pry >> x == y
          => true


          Even though the object id's are different:



          pry >> x.__id__
          => 70125513489160
          pry >> y.__id__
          => 70125513383980





          share|improve this answer


























          • I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

            – MorboRe'
            Dec 31 '18 at 23:47











          • I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

            – MorboRe'
            Dec 31 '18 at 23:53






          • 1





            They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

            – Holger Just
            Jan 1 at 11:49











          • @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

            – Jay Dorsey
            Jan 2 at 14:08











          • interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

            – MorboRe'
            Jan 3 at 9:50
















          3












          3








          3







          I believe the answer you're looking for is found in the Struct documentation



          Equality—Returns true if other has the same struct subclass 
          and has equal member values (according to Object#==).


          Your example has equal member values for str_a and str_b, and they have the same subclass (Customer), so they are equal when compared with ==



          Contrast this with the Object documentation



          Equality — At the Object level, == returns true only if 
          obj and other are the same object. Typically, this method is
          overridden in descendant classes to provide class-specific meaning.


          In your example, foo_a and foo_b are not the same object (because they're not the same instance)



          If you're seeking why these are different, I didn't really answer that question. Just that the behavior is as intended per the docs. They don't actually have the same ID:



          pry >> Bar = Struct.new(:name) do; end
          => Bar < Struct
          pry >> x = Bar.new
          => #<Struct:Bar:0x7f8ebca47610
          name = nil

          pry >> y = Bar.new
          => #<Struct:Bar:0x7f8ebca14058
          name = nil

          pry >> x.name = "foo"
          => "foo"
          pry >> y.name = "foo"
          => "foo"
          pry >> x
          => #<Struct:Bar:0x7f8ebca47610
          name = "foo"

          pry >> y
          => #<Struct:Bar:0x7f8ebca14058
          name = "foo"


          But, you'll note comparison is based on attributes, rather than the object ID:



          pry >> x == y
          => true


          Even though the object id's are different:



          pry >> x.__id__
          => 70125513489160
          pry >> y.__id__
          => 70125513383980





          share|improve this answer















          I believe the answer you're looking for is found in the Struct documentation



          Equality—Returns true if other has the same struct subclass 
          and has equal member values (according to Object#==).


          Your example has equal member values for str_a and str_b, and they have the same subclass (Customer), so they are equal when compared with ==



          Contrast this with the Object documentation



          Equality — At the Object level, == returns true only if 
          obj and other are the same object. Typically, this method is
          overridden in descendant classes to provide class-specific meaning.


          In your example, foo_a and foo_b are not the same object (because they're not the same instance)



          If you're seeking why these are different, I didn't really answer that question. Just that the behavior is as intended per the docs. They don't actually have the same ID:



          pry >> Bar = Struct.new(:name) do; end
          => Bar < Struct
          pry >> x = Bar.new
          => #<Struct:Bar:0x7f8ebca47610
          name = nil

          pry >> y = Bar.new
          => #<Struct:Bar:0x7f8ebca14058
          name = nil

          pry >> x.name = "foo"
          => "foo"
          pry >> y.name = "foo"
          => "foo"
          pry >> x
          => #<Struct:Bar:0x7f8ebca47610
          name = "foo"

          pry >> y
          => #<Struct:Bar:0x7f8ebca14058
          name = "foo"


          But, you'll note comparison is based on attributes, rather than the object ID:



          pry >> x == y
          => true


          Even though the object id's are different:



          pry >> x.__id__
          => 70125513489160
          pry >> y.__id__
          => 70125513383980






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 31 '18 at 23:47

























          answered Dec 31 '18 at 23:33









          Jay DorseyJay Dorsey

          1,84211014




          1,84211014













          • I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

            – MorboRe'
            Dec 31 '18 at 23:47











          • I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

            – MorboRe'
            Dec 31 '18 at 23:53






          • 1





            They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

            – Holger Just
            Jan 1 at 11:49











          • @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

            – Jay Dorsey
            Jan 2 at 14:08











          • interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

            – MorboRe'
            Jan 3 at 9:50





















          • I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

            – MorboRe'
            Dec 31 '18 at 23:47











          • I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

            – MorboRe'
            Dec 31 '18 at 23:53






          • 1





            They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

            – Holger Just
            Jan 1 at 11:49











          • @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

            – Jay Dorsey
            Jan 2 at 14:08











          • interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

            – MorboRe'
            Jan 3 at 9:50



















          I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

          – MorboRe'
          Dec 31 '18 at 23:47





          I meant why are the hash int are different for same-valued-Class-instances but same hash int for Struct instances with the same value?

          – MorboRe'
          Dec 31 '18 at 23:47













          I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

          – MorboRe'
          Dec 31 '18 at 23:53





          I thought the behavior is odd since both Struct and Class inherits #hash from Kernel but they act differently.

          – MorboRe'
          Dec 31 '18 at 23:53




          1




          1





          They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

          – Holger Just
          Jan 1 at 11:49





          They are not the same methods. Struct#hash is a different (overwritten) method from Kernel#hash to take into account the different equality rules. Note that an object's hash is not strictly used for object equality usually but to identify a key for an object to be used e.g. as a key in a Hash object. If two objects have the same hash value, they will use the same "slot" in a Hash object.

          – Holger Just
          Jan 1 at 11:49













          @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

          – Jay Dorsey
          Jan 2 at 14:08





          @MorboRe' the link & explanation posted by Holger is the answer to your hash question specifically. If you toggle source you can see that they're building the hash from (what looks like) the member values. This aligns with why equality is calculated differently (that's how it's meant to work, because it calculates the hash based on values )

          – Jay Dorsey
          Jan 2 at 14:08













          interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

          – MorboRe'
          Jan 3 at 9:50







          interesting, I tried Struct.new("N").method(:hash).owner to find out the owner of the #hash method then got return value as Kernel. I ran some test with instance methods from some customized Class but the result of that turns out to be my last modified Class. Therefore I assume #owner returns the last overridden Class as the result. Since Struct inherits from Emuerable. I guess #hash was redefined there because the equality test for Emuerable works the same way. thx for explanation

          – MorboRe'
          Jan 3 at 9:50






















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992097%2fwhy-equality-check-for-instance-of-struct-class-are-different%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Monofisismo

          Angular Downloading a file using contenturl with Basic Authentication

          Olmecas