Next Previous Contents

2. Namespace rules

There are some languages which are fairly C compatible and can make use of the #includes and the native calling interface without an intermediate wrapper. They have some keywords we should not touch (NOT AT ALL - even, if the code is never exported). The same applies for some functions/ variables of some common libraries.

We have violated this rule in the past, so the cases where this has happened are marked with an old_name -> new_name entry to help porting old applications which suddenly break.

All names on the left side of such rules and all other mentioned below are to be avoided.

Please report all other namespace conflicts you encounter, so we can fix it.

2.1 Objective C

self

-> slf (done)

super

o.k.

nil

o.k.

Class

o.k.

SEL

o.k.

IMP

o.k.

BOOL

o.k.

Object

o.k.

NS*

o.k.

YES

used in SVGAlib. Probably o.k. - not our problem.

NO

used in SVGAlib. See YES.

id

used throughout the source ... particularly EvStack.

2.2 C++

inline

C reserved word. o.k.

const

C reserved word. o.k.

catch

o.k.

delete

o.k.

dynamic_cast

o.k.

explicit

o.k.

false

o.k.

friend

o.k.

mutable

o.k.

namespace

o.k.

new

o.k. (once used in display.c, but that' in the kernel patch, so ...)

operator

o.k.

protected

o.k.

public

o.k.

static_cast

o.k.

template

o.k.

throw

o.k.

true

o.k.

typeid

o.k.

typename

o.k.

using

o.k.

this

o.k.

try

o.k.

bool

defined in system.h - doesn't seem to be used except in util/ggiset*. go to ggi_bool ? Drop it ?

class

EvStack uses this. Should we allow C++ there ? (->clss)

private

-> priv (still used in kernel drivers ... well - they aren't C++)

virtual

-> virt

2.3 GlibC

index

-> ggiindex (done)

2.4 Others

ggi_sint, ggi_uint

???

real

These are commonly used for about anything ... Maybe prefix with ggi


Next Previous Contents