Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Naming Conventions
Keywords: renaming symbols
Message-ID: <70185@microsoft.UUCP>
Date: 23 Jan 91 20:11:46 GMT
References: <60352@microsoft.UUCP> <CIMSHOP!DAVIDM.91Jan9105408@uunet.UU.NET> <278D1767.505@tct.uucp> <61785@brunix.UUCP> <556@taumet.com> <1568@tcs.tcs.com> <62211@brunix.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 34

In article <62211@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
|It would be nice if we could use this mechanism right now to solve the
|prolems that have been mentioned:
|
|    class MotifClasses {
|      public:
|      #include "motif.h"
|    };
|
|    class OpenViewsClasses {
|      public:
|      #include "openviews.h"
|    };
|
|But then the mangled names generated from the .h files wouldn't match the
|mangled names present in the .o files.  Sigh.

It would seem that we need linkers that allow renaming of classes etc
at link time.  One way to "automate" this would be if you could tell
the linker to imply a libname:: extension to the classes implemented
in that lib.  Thus, assuming two libraries aren't named the same
[and you _can_ rename them by changing the name of the file containing
the library] you could resolve the conflicts.

But, name conflicts are only a small part of the conflicts that occur
when trying to use libraries from multiple vendors.  A bigger problem
is the discord that results from trying to use libraries of different
programming style and intent.  Also memory management schemes tend to
conflict.

I agree that a good, simple way to resolve name conflicts is going to
be necessary.  But, we also need to figure out some way to get to a 
consensus of a good, standard, base set of C++ libraries for people
to build on.  [However, I can imagine no way to do this.]