• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
random_thinker

anonymous namespaces : should they be used?

17 posts in this topic

In Modern C++ Design (Alexandrescu), an example implementation of an object factory wraps a concrete object creator function and an ID in an anonymous namespace, to hide it from the rest of the programme. This practice, although effective, just seems inherently strange to me, but maybe this is a lack of experience on my part. Instinctively, I do not see why this could not be wrapped in a class instead, which is one of the purposes of a class or struct, to encapsulate and isolate the data and methods. Is it somehow safer to use anonymous namespaces? Is it more efficient when compared to alternatives? Are there situations where there is no choice? Any views? --random Edit--here is a simple example that illustrates my concern:
#include <iostream.h>

namespace
{
	int local; // should not collide with other files
}

void func()
{
	local = 2;
}

int main()
{
	local = 1;
	cout<< "local=" << local << endl;
	func();
	cout<< "local=" << local << endl;
	return 0;
}

// results in
local=1
local=2
Is there any difference between unnamed namespaces and globals? [Edited by - random_thinker on September 11, 2007 5:48:23 AM]
0

Share this post


Link to post
Share on other sites
Anonymous namespaces and global variables are completely orthogonal concepts. Anonymous namespaces restrict an identifier to a single file, while global variables allow global access through a given identifier. You can have a global variable in an anonymous namespace (usable in that file only) or at file scope (usable in all files), just like you can have a class or function in an anonymous namespace.

The advantages of anonymous namespaces are that you don't have link-time collisions (because your identifiers are restricted to a single file) and don't pollute headers with implementation details (like a static class member or nested class would).
1

Share this post


Link to post
Share on other sites
So in the above code, in theory, if I separated the anonymous namespace to another file, I should get an error when I try to compile?

--random
0

Share this post


Link to post
Share on other sites
Quote:
Original post by random_thinker
So in the above code, in theory, if I separated the anonymous namespace to another file, I should get an error when I try to compile?


To another translation unit, yes. However, the main purpose is (as mentioned before) related to linking, not compiling.
0

Share this post


Link to post
Share on other sites
Oh I see...so then this code:


// contents of main.cpp
#include <iostream>

int nfunc();
int func()
{
return 1;
}

int main()
{
using namespace std;

cout<< "local=" << func() << endl;
cout<< "local=" << nfunc() << endl;
return 0;
}

// contents of nspace.cpp
namespace
{
int func()
{
return 2;
}
}

int nfunc()
{
return func();
}


Will return:

local=1
local=2

and the linker will not see the symbol func() twice. I guess that unnamed namespaces are a good practice where needed.

thx!

--random
0

Share this post


Link to post
Share on other sites
Quote:
Original post by random_thinkerIs there any difference between unnamed namespaces and globals?


Well, "globals" are namespace-level names in the global namespace. The global namespace is a namespace just like any other. It has no spcial properties and participates in overload resolution just like any other namespace.

That means names in an anonymous namespace, in the current namespace, in the global namespace, and in any namespaces currently in scope due to a "using" directive all participate equally in name resolution.

The big difference is when it comes to name conflicts. With a regular namespace (a named namespace or the global namespace) you can always disambiguate by fully qualifying the name with the namespace (eg. ::func1() for a global variable). You cannot do this with the anonymous namespace. There is no way to disambiguate names declared in an anonymous namespace.

Like many tools, this gives you increased power (of protection) at a known cost (inability to disambiguate).

Me, I've learned to use anonymous namespaces frequently. I've been burned too many times having to support an undocumented API. C-with-classes programmers, although evidently in the majority, are not altogether the bunch leading the human race forwards.
0

Share this post


Link to post
Share on other sites
So let me see if I understand the use...in a practical sense, where a class or other operation needs certain supporting classes, functions and data that are not to be used by any other part of the programme, then these can be wrapped in an unnamed namespace within the same translation unit, and these will be found within that translation unit during the compile phase, but will not be found by the linker. Is that correct?

--random
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
The advantages of anonymous namespaces are that you don't have link-time collisions (because your identifiers are restricted to a single file) and don't pollute headers with implementation details (like a static class member or nested class would).


Interesting. I never mucked around with anonymous namespaces. How is it different from declaring the variable static, which also limits its scope to a single file?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by legalize
Interesting. I never mucked around with anonymous namespaces. How is it different from declaring the variable static, which also limits its scope to a single file?


It also works with classes and structures, for instance defining two distinct Visitor classes in two different files without the linker doing strange things with them (the sad part about these collisions is that you don't get a 'multiple definition' error, but rather the behaviour of the binary is erratic).
0

Share this post


Link to post
Share on other sites
Definitions inside a anonymous namespace can still have external linkage, while they don't cause name collisions at link time. This is important for template types which require names with external linkage for certain template parameters.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by legalize
Quote:
Original post by ToohrVyk
The advantages of anonymous namespaces are that you don't have link-time collisions (because your identifiers are restricted to a single file) and don't pollute headers with implementation details (like a static class member or nested class would).


Interesting. I never mucked around with anonymous namespaces. How is it different from declaring the variable static, which also limits its scope to a single file?


Well, anonymous namespaces are supposed to be used in favour of this use of "static", or so I thought until recently. But one thread made me question this, as they don't seem to map to each other completely. Read more here.

[edit:]

Quote:
Original post by SiCrane
Definitions inside a anonymous namespace can still have external linkage, while they don't cause name collisions at link time. This is important for template types which require names with external linkage for certain template parameters.


Ok, thanks that explains it. [smile]
0

Share this post


Link to post
Share on other sites
Quote:
Well, anonymous namespaces are supposed to be used in favour of this use of "static", or so I thought until recently. But one thread made me question this, as they don't seem to map to each other completely. Read more here.

[edit:]

Quote:
Original post by SiCrane
Definitions inside a anonymous namespace can still have external linkage, while they don't cause name collisions at link time. This is important for template types which require names with external linkage for certain template parameters.


Ok, thanks that explains it. [smile]


Stroustrup specifically forbids the use of static at global or file scope (only recommending it for class/struct or function scope), and recommends the use of unnamed namespaces instead.

As I usually ask Si, do you have a simple example of unnamed namespace (external linkage) combined with template usage? I learn more from studying your examples than a month's worth of class time.

--random
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Quote:
Original post by legalize
Interesting. I never mucked around with anonymous namespaces. How is it different from declaring the variable static, which also limits its scope to a single file?


It also works with classes and structures, for instance defining two distinct Visitor classes in two different files without the linker doing strange things with them (the sad part about these collisions is that you don't get a 'multiple definition' error, but rather the behaviour of the binary is erratic).


This would be true of functions, classes and structures declared static as well, so I don't think that's the defining difference.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Definitions inside a anonymous namespace can still have external linkage, while they don't cause name collisions at link time. This is important for template types which require names with external linkage for certain template parameters.


OK, I can see the difference here, but I don't see the value yet... I consider myself pretty proficient in C++, but I haven't yet become a "meta programming" guru with all the template stuff. Hell, its been a hard enough slog to get my coworkers to use the standard library...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by legalize
This would be true of functions, classes and structures declared static as well, so I don't think that's the defining difference.


You cannot declare a class or structure as static.
0

Share this post


Link to post
Share on other sites
Ok, let's pretend you want to embed a string as a non-type template parameter.

template <const char * string>
std::string bar(void) {
return string;
};

int main(int, char **) {
std::cout << bar<"Hello">(); // this is illegal; string literals have internal linkage
return 0;
}

So one way to get that to compile is to declare a const char array with external linkage.

extern const char message[] = "Hello";

int main(int, char **) {
std::cout << bar<message>();
return 0;
}

However, now you've got an exported symbol message that could cause collisions with other translation units, so if you stick it in an anonymous namespace you eliminate the possible collision.
0

Share this post


Link to post
Share on other sites
Right...so...


// File 'Main.cpp'
template <const char * string>
std::string bar(void)
{
return string;
};

namespace
{
extern const char message[] = "Hello";
}

int main(int, char **)
{
std::cout << bar<message>() << std::endl;
return 0;
}

// File 'World.cpp"
extern const char message[] = " World";


after build and execution, results in:

Hello

I see....

Thx,

--random
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Quote:
Original post by legalize
This would be true of functions, classes and structures declared static as well, so I don't think that's the defining difference.


You cannot declare a class or structure as static.


Ah, good point. You can create a static instance of a class or struct, but you can't limit its visibility to a single compilation unit without making it "nameless" and static, i.e.


static struct
{
int foo;
int bar;
} foobar;
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0