Path: utzoo!utgpu!watmath!uunet!mcvax!ukc!strath-cs!nott-cs!ucl-cs!T.Day
From: T.Day@ucl-cs.UUCP
Newsgroups: gnu.g++.lib.bug
Subject: Need to overload _gsort in e.g Int.Vec.o, Double.Vec.o
Message-ID: <353@ucl-cs.UUCP>
Date: 27 Jul 89 15:50:13 GMT
Sender: T.Day@ucl-cs.UUCP
Lines: 32

From: Tim Day <T.Day@uk.ac.ucl.cs>

I recently put Int.Vec.o and Double.Vec.o into a library
(I prefer Int, Double, Ostream etc to int, double, ostream....
these are all done with typedefs in a common .h file)

However, when I attempted to link with the library from a program
which uses both classes, I had problems with multiple versions
of _gsort.

Int.Vec.cc contains: gsort (Int *, int, IntComparator)
Double.Vec.cc contains: gsort (Double *, int, DoubleComparator)

Since the arguments are all builtin types, I have to put in an 
"overload gsort" to force g++ to call the routines
_gsort_PSI_SI_PFSI$SI_SI_
_gsort_PDF_SI_PFSI$DF_DF_

The question is, should the libg++ prototype sources contain overloads to
prevent this sort of thing happening ?  

I'm unlikely to want to call routines used internally by libg++ from plain C,
so the argument type info in the function name isn't any kind of problem.
+-----------------------------------------------------------------------------+
Tim Day                           | Meet every second in life as challenge;
Department of Photogrammetry      | Respond fully to whatever happens
UCL, Gower St., London  WC1E 6BT  |  without anxiety, or complaint, or clinging
+-----------------------------------------------------------------------------+
P.S Actually I think the need to overload builtins-only functions is a
hideous asymmetry in the treatment of builtins and classes.  C++ syle function
names should be the default unless the function is included within the scope
of an extern "C" {...} or similar, but that's another story....