From -3058283132666605580
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,fddfa855dc41ba0d
X-Google-Attributes: gid109fba,public
X-Google-Thread: f78e5,fddfa855dc41ba0d
X-Google-Attributes: gidf78e5,public
From: JdeBP@jba.co.uk (Jonathan de Boyne Pollard)
Subject: Re: Namespaces, naming conflicts
Date: 1995/06/16
Message-ID: <3rsjj5$9cp@silver.jba.co.uk>#1/1
X-Deja-AN: 104608823
references: <3r79jk$3se@nms.telepost.no> <DA379D.Jr6@online.tmx.com.au> <1995Jun15.073234.11397@gsi.fr>
followup-to: comp.lang.c++,comp.std.c++
organization: JBA Software Products, Studley, England.
reply-to: JdeBP%utopium@jba.co.uk
newsgroups: comp.lang.c++,comp.std.c++

Roman.Stawski (Roman.Stawski@gsi.fr) wrote:
: Why not use the nested namespace mechanism to resolve conflicting 
: namespaces?
:
: 	namespace MS {
: 		#include <msodbc.h>
: 	}
:
: 	namespace WATCOM {
: 		#include <watodbc.h>
: 	}
:
: 	...
: 	MS::ODBC::Connect() ;
: 	// or
: 	WATCOM::ODBC::Connect() ;

Because your code will compile to calls to functions named MS::ODBC::xxxx,
whereas the libraries provided by the vendor will contain functions named 
ODBC::xxxx.  Your program will then not link.

The whole point of namespaces is to get around name conflicts between
libraries, and if vendors choose to take similar function libraries and
give them exactly the same namespace name as those from other vendors then
we are right back at square one again, only with longer names this time.