Odd "Check_VIOLATION" failed test case in Eiffel

Question

The main issue from the below picture is that when "check Result end" statement is added it automatically fails and displays "CHECK_VIOLATION" error in debugger.

Also, the HASH_TABLE doesn't store all items given to it but I fixed that by switching HASH_TABLE[G, INTEGER] instead of using the current HASH_TABLE[INTEGER, G]

My main problem is why does it throw Check_violation always and fail whenever a "check result end" statement is seen? Maybe the HAS[...] function is bad?

Currently any test case feature with "check result end" makes it false and throw CHECK_VILOATION

code:

class
  MY_BAG[G -> {HASHABLE, COMPARABLE}]
inherit
  ADT_BAG[G]

create
  make_empty, make_from_tupled_array

convert
   make_from_tupled_array ({ARRAY [TUPLE [G, INTEGER]]})

feature{NONE} -- creation

    make_empty
     do
        create table.make(1)
     end

    make_from_tupled_array (a_array: ARRAY [TUPLE [x: G; y: INTEGER]])
     require else
        non_empty: a_array.count >= 0
        nonnegative: is_nonnegative(a_array)
      do

        create table.make(a_array.count)

        across a_array as a
            loop
                 table.force (a.item.y, a.item.x)

            end
      end

feature -- attributes

  table: HASH_TABLE[INTEGER, G]
  counter: INTEGER

testing code:

  t6: BOOLEAN
    local
        bag: MY_BAG [STRING]
    do
        comment ("t6:repeated elements in contruction")
        bag := <<["foo",4], ["bar",3], ["foo",2], ["bar",0]>> -- test passes
        Result := bag ["foo"] = 5 -- test passes
        check Result end  -- test fails (really weird but as soon as check statement comes it fails)
        Result := bag ["bar"] = 3
        check Result end
        Result := bag ["baz"] = 0


    end

Maybe I don't understand your code correctly, but I am in the impression that Result := bag ["foo"] = 5 should be Result := bag ["foo"] = 6 (because 4 + 2 = 6). — Louis M, Mar 17 '16 at 02:36
It is supposed to fail the only one that passes is "Result := bag ["bar"] = 3 — geforce, Mar 17 '16 at 02:39
But this does show me it should be HASH_TABLE[INTEGER,G] instead of mine which is HASH_TABLE[G, INTEGER] however still doesn't fix my problem — geforce, Mar 17 '16 at 02:41

Alexander Kogtenkov · Accepted Answer · 2016-03-18T06:56:43.503

Most probably ADT_BAG stands for an abstraction of a multiset (also called a bag) that allows to keep items and to tell how many items equal to the given one are there (unlike a set, where at most one item may be present). If so, it is correct to use HASH_TABLE [INTEGER, G] as a storage. Then its keys are the elements and its items are the elements numbers.

So, if we add the same element multiple times, its count should be increased. In the initialization line we add 4 elements of "foo", 3 elements of "bar", 2 elements of "foo" again, and 0 elements of "bar" again. As a result we should have a bag with 6 elements of "foo" and 3 elements of "bar". Also there are no elements "baz".

According to this analysis, either initialization is incorrect (numbers for "foo" should be different) or the comparison should be done for 6 instead of 5.

As to the implementation of the class MY_BAG the idea would be to have a feature add (or whatever name specified in the interface of ADT_BAG) that

Checks if there are items with the given key.
If there are none, adds the new element with the given count.
Otherwise, replaces the current element count with the sum of the current element count and the given element count.

For simplicity the initialization procedure would use this feature to add new items instead of storing items in the hash table directly to process repeated items correctly.

Why does ["bar", 0] make the total "bar" count to 2 elements? Shouldnt it stay 3 elements since count is 0? — geforce, Mar 17 '16 at 19:35
@GeForce, you are right, there is a typo in the answer, I'll correct it. — Alexander Kogtenkov, Mar 18 '16 at 06:55

Odd "Check_VIOLATION" failed test case in Eiffel

1 Answers1