OSLib Namespace for C++

[Alexander Thoukydides]

One solution to some of the problems raised by using a namespace for OSLib would be same as that used for standard C library files within the standard C++ library, i.e. to have two sets of header files.

The main contents of the existing header files would be placed in hew header files, e.g.

	// _header.h (used directly by new software)
	#ifndef _header_H
	#define _header_H

	#ifdef __cplusplus
	#	ifndef __CC_NORCROFT
	#		define NAMESPACE_OSLIB
	#	endif
	#	ifdef NAMESPACE_OSLIB
			namespace OSLib {
	#	endif
			extern "C" {
	#endif

	// Contents of original header file...

	#ifdef __cplusplus
			}
	#	ifdef NAMESPACE_OSLIB
			}
	#	endif
	#endif

The original header files could then be rewritten as:

	// header.h (used directly by existing software)
	#ifndef header_H
	#define header_H

	#include "_header.h"

	#ifdef __cplusplus
	#	ifdef NAMESPACE_OSLIB
			using namespace OSLib;
	#	endif
	#endif

	#endif

This would maintain full binary compatibility with existing source code, and would enable software aware of the namespace to use it properly just by including a different header file.

However, I'm not sure that this is worth the effort. Using a namespace and then appending a non-local using-directive like this only offers a benefit if linkage with C code is not required, i.e. extern "C" directives are not used. In this case *different* source files can include different header files that define the same name for different purposes, and the namespaces will be included as part of the symbol names to ensure correct linkage.

However, for OSLib it is necessary to specify "C" linkage (as in the above exampe), thereby preventing the symbol names from being affected by the namespace. This means that only type definitions will be protected by the namespace - OSLib defines constants as macros so they aren't affected by namespaces, and the raw names of SWI veneers still need to be unique to prevent clashes during linking.

My personal feeling is that adding a namespace to OSLib doesn't offer sufficient advantages to outweigh the additional complications.

Alex

---------------------------------------
From: Tony van der Hoff <OSLib at mk-net.demon.co.uk>
Subject: OSLib Namespace for C++
Date: 29/05/2000 5:25:11 pm
---------------------------------------
I propose to introduce an OSLib namespace for use with g++. CFront doesn't support namespaces, and it needs to be introduced in a backwards-compatible way.

The way I propose to do it is to bracket all declarations in the headers between 

  #if defined NAMESPACE_OSLIB
    namespace OSLib {
  #endif
   .
   .
   .
  #if defined NAMESPACE_OSLIB
    }
  #endif

Anyone wanting to use the namespace would define NAMESPACE_OSLIB before including any OSLib headers. Unfortunately this requires proactive involvement by the user, and on the basis that namespaces are a good thing, that's a shame.

It would be nice to make this definition automatic, based on 
  #if defined __CPLUSPLUS && !defined __CC_NORCROFT
    #define NAMESPACE_OSLIB
  #endif
but that would not be backwards compatible. I doubt that any serious applications have yet been written using OSLib and g++, given the bool problem, but nonetheless, I don't think we can afford to do it.

Stroustrup suggests appending the headers with 
  using namespace OSLib;
thus making it global, but that seems to me to defeat the objective of a namespace.

Comments anyone?
-- 
Tony van der Hoff         |  Mailto:tony at mk-net.demon.co.uk
                          |  Mailto:avanderhoff at iee.org
Buckinghamshire, England  |  http:www.mk-net.demon.co.uk