Skip to main content
gamedev.net
🔒 Locked

[C] namespace simulation

Started by dcosborn Oct 30, 2004 at 9:47 PM 1 replies 750+ views
Original Post
dcosborn
dcosborn
I've been working on a library and game in C and Python. I'm hoping to release the library sometime and I'm trying to figure out a flexible method of supporting namespaces so users won't have name clashing problems. One solution I'm considering is wrapping my global functions in a macro that prefixes them with the namespace. This way, the namespace can be changed if necessary. Anyways, here's the concept:
// _config.h
#ifndef CORE_NAMESPACE
#define CORE_NAMESPACE core_
#endif
#define CORE_WRAP(a) CORE_NAMESPACE##a
It involves writing CORE_WRAP(...) around everything I export from the library including both functions and types. I've been using it for the python wrapper (edit: this is C code I'm referring to) around the library and it definitely reduces readability so I'm not sure if I like it. So before I go in and start wrapping all my functions via copy/paste, is this a "Good Idea"? [Edited by - dcosborn on October 30, 2004 10:41:36 PM]
psamty10
psamty10
If you're planning on exporting various C APIs to Python, be aware that every C module you export already lives in its own namespace. For eg., if you export a DLL such as Graphics.dll, every function in it needs to be referred to as Graphics.funcname from Python (unless you import using "from Graphics import *", which is a bad idea to begin with). So if you're only talking about code in C, you can either make sure that names don't clash within the C module, or compile it as C++ and make use of namespaces.
dcosborn
dcosborn
Yeah, I considered using C++ but there are specific reasons why I've been avoiding it in this project.

I want to encourage the library to be used from C as well as from Python so I need to ensure the C interface doesn't encourage clashing while keeping it as clean and flexible as possible. If it was just a Python library I'd be much less stringent. Anyways, I went ahead and made the necessary changes to the headers. Its definitely not pretty, but it does the job. Now to do the source... [dead]

edit: Ok I'm thinking maybe its not a good idea because whenever someone redefines the namespace, they're being either non-standard (when a user changes it) or non-backwards-compatible (when I change the default namespace definition during a revision). The only good reasons I can think of to redefine the namespace are when the user doesn't want to have to prefix everything with "core_" (not all that important) or when someone makes derivative version with a different name (not likely). So maybe its an unecessary complication. I hate being undecided about these things. [rolleyes]

[Edited by - dcosborn on October 30, 2004 10:34:09 PM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.