Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!ge-dab.ge.com!tarpit!tous!alfred!fang!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Summary: Problem, Real, Herring, Red
Keywords: Sun, C++, qsort(), bsearch(), and un-prototypes
Message-ID: <473@mole-end.UUCP>
Date: 21 Jan 91 08:57:12 GMT
References: <3069@lupine.NCD.COM> <1990Dec26.160636.15566@clear.com> <3339@lupine.NCD.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 33

> +Second, the real conflict isn't between  void*  and  XYZ*  and it has
> +nothing to do with MI. ...  ... it's a herring that has gone beyond red ...
 
> 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.

A real problem, yes.  To the question at hand?  A distraction, a false trail,
a wrong tree, a red herring.  The question at hand is interesting on its own.

 
> +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++.

I think that *their datatypes* are poor candidates for incorporation into
the program.  But if you can write code to deal with arbitrary binary data
of abitrary size, and then can take the risk of it being, or not being,
valid object-bits when you look at it as an object, you can certainly code
it.

Really, the only language for which handling arbitrary blocks of data (and
sometimes trusting them to be a valid pointer or object or whatever) is not
a messy case to handle PROPERLY is assembler, and that's because everything
in assembler is messy; no single case is messy on its own.  OK, LISP will
do.  But LISP is an assembler too; an assembler for a hypothetical machine,
'tis true, but an assembler nonetheless.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile