Author Topic: priority of built-in function vs coded function...  (Read 1597 times)

0 Members and 1 Guest are viewing this topic.

ribarm

  • Gator
  • Posts: 3279
  • Marko Ribar, architect
priority of built-in function vs coded function...
« on: December 23, 2023, 03:39:27 AM »
Hi all,
I have a question : Recently I've coded function (_vl-sort) to which I changed it's name to match built-in (vl-sort)... My question is : will coded (vl-sort) take priority over built-in (vl-sort) on all places where it occurs, or will built-in (vl-sort) win over coded version in this cases... The point is that I've coded it because I don't know how do Object Arx handle (vl-sort), so I left it coded in case that translation from LISP to ARX is possible...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1453
  • Marco
Re: priority of built-in function vs coded function...
« Reply #1 on: December 23, 2023, 04:14:11 AM »
I didn't understand your question well but I'll tell you what Tony Tanzillo wrote many years ago (maybe 23):
Code: [Select]
If you search this newsgroup (nda: Autodesk old NG), you'll find a much more powerful sorting function along with a good discussion on why (vl-sort) can be very dangerous.
For that reason, I suggest you replace the built-in vl-sort with this:

(defun vl-sort (lst func)
   (mapcar
     '(lambda (x) (nth x lst))
      (vl-sort-i lst func)
   )
)

This will ensure that (vl-sort) does not removeelements that it sees as equal.

ribarm

  • Gator
  • Posts: 3279
  • Marko Ribar, architect
Re: priority of built-in function vs coded function...
« Reply #2 on: December 23, 2023, 04:33:11 AM »
Thanks, just forgot ab (vl-sort-i)... I just don't know ab ObjectArx... It seems that (vl-sort-i) is much faster than my (_vl-sort), so I'll revise my codes...
Thanks again... This topic is for now closed...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube