Xref: utzoo comp.lang.c++:11158 comp.std.c++:532
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Keywords: Sun, C++, qsort(), bsearch(), and un-prototypes
Message-ID: <3339@lupine.NCD.COM>
Date: 12 Jan 91 21:33:37 GMT
References: <3069@lupine.NCD.COM> <1990Dec26.160636.15566@clear.com> <465@mole-end.UUCP>
Followup-To: comp.lang.c++
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 45

In article <465@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:
+> >Both qsort() and bsearch() require a pointer to a function which [takes]
+> >two parameters of type pointer-to-void.  ... that the function ... will
+> >almost immediately cast [them to] pointer-to-T is utterly irrelevant.
+ 
...
+Second, the real conflict isn't between  void*  and  XYZ*  and it has nothing
+to do with MI.  NOTHING, NOTHING, NOTHING, NOTHING.  NO THING.  NOT A THING IN
+THIS WORLD.  NOTHING.  The MI problem occurs when you have pointers that are
+stored as  derived*  and interpreted as base* .  That problem *COULD* occur
+here, but it's not an essential part of the problem.  In other words, it's a
+herring that has gone beyond red and is well on its way to scarlet.

As you say, that problem can occur in the context under discussion, and
I think that it is a real problem and not a red herring.

+What is probably DISASTROUS is to use the ellipsis in declaring  qsort() .
+If  qsort() 's argument is of the form   int (*cmpr_fun)( ... )  the function
+may get called (and under some MS-DOS compilers, *WILL* get called) with an
+entirely different calling sequence, such that the function will misunderstand
+its arguments and even its call/return sequence.
...
+In other words, Sun Microsystems has indeed made a horrible mistake.

OK.  We are in agreement about that.  Doug L. ?  Where are you where we need
you?

Will this be fixed in a future release?

+Templates can provide a better solution...

Again, we agree.

+But templates don't answer the problem completely.  What happens if you
+have something like a database engine that has to handle whatever types and
+sizes are thrown at it without recompilation? ...

Perhaps such things are bad candidates for being coded in a quasi-
strongly-typed language like C++.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.