Mirror of forum.nim-lang.org

489 :: Shouldn't system.cmp have the same behaviour as nimrod comparisons?

• gradha (orginal) [2014-07-05T12:01:57+02:00] view original

  Due to system.cmp being more efficient than the generic version (it calls C strcmp) comparisons in Nimrod land are different than in C, since Nimrod allows strings to have embedded zero. The following test:

  
  import algorithm
  
  const
    a = "a"
    b = "a\0b"
  
  when isMainModule:
    for t in [a, b]: echo "len ", t.len
    var a1= [a, b, a]
    echo "Starting  : ", repr(a1)
    sort(a1, system.cmp)
    echo "system.cmp: ", repr(a1)
    sort(a1) do (x,y: string) -> int:
      if x == y: result = 0
      elif x < y: result = -1
      else: result = +1
    echo "nimrod    : ", repr(a1)
  Run

  Generates the following output:

  
  len 1
  len 3
  Starting  : [0x1024f80a0"a", 0x1024f80c8"a", 0x1024f80f0"a"]
  
  system.cmp: [0x1024f80a0"a", 0x1024f80c8"a", 0x1024f80f0"a"]
  
  nimrod    : [0x1024f80a0"a", 0x1024f80f0"a", 0x1024f80c8"a"]
  Run

  It confirms that sorting using system.cmp will have a different result than using Nimrod comparison. The last comparison moves the third item to the second position since its length is shorter despite all items starting with the same prefix.

  Shouldn't the Nimrod behaviour prevail? Or maybe a new native system.nimcmp implemented for sorting which is not as optimal but allows nimrod strings to contain embedded zeros?

---