Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: Naming Conventions
Keywords: renaming symbols
Message-ID: <62211@brunix.UUCP>
Date: 22 Jan 91 20:21:34 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>
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 63

In article <1568@tcs.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes:
>     Unfortunately, it is often the case that one is using existing C
>libraries from new C++ code.  For example, I'm at this instant trying to
>rationalize no less than three definitions of a boolean type: HP OpenViews,
>Motif, and our own internal library.  It isn't too bad, since only the
>OpenViews code and our own library have an actual symbol clash.  They both
>define the types "boolean," whereas Motif defines "Boolean."
>
>     So in my case, it's just a matter of changing our code.  If it'd been
>Motif and OpenViews code which conflicted, I wouldn't have been able to
>modify the code, so there'd be #defines wrapping the include statements of
>their header files.  Yeah, I know, pretty gross.  Has anyone thought of a
>better solution for this problem?

I don't know how to solve this problem, but I think when nested classes are
more widely available, big libraries should come out as a single class
(used to demarcate a name space) with all the "real" classes nested inside:

    class Motif {
      public:
        class realMotifClass1 { ... };
        class realMotifClass2 { ... };
        ...
    };

    class OpenViews {
      public:
        class realOpenViewsClass1 { ... };
        class realOpenViewsClass2 { ... };
        ...
    };

This should reduce name conflicts substantially: Motif::boolean is quite
different than OpenViews::boolean.  On the other hand, this makes
coding applications using the libraries more cumbersome:

    Motif::realMotifClass1 object1(x, y, z);
    object1.function1(Motif::true);

    OpenViews::realOpenViewsClass1 object2;
    object1.function2(OpenViews::true);

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.

Scott


-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."