Preferred method of defining functions declared in namespaces

[Ivan]

When a function is declared in a namespace, for example:

namespace Mine
{
void f();
}

there are two alternatives for defining the function. You can either
qualify the function name with the namespace name:

void Mine::f()
{
// ...
}

or you can reopen the namespace:

namespace Mine
{
void f()
{
// ...
}
}

In C++PL 3rd (section 8.2.9.3), where this example comes from,
Stroustrup recommends the first form. His rationale is that, if you
inadvertently mismatch the name or signature, the compiler will catch
the error with the first form, but not the second. In other words,
this triggers a compile error (no ff() declared in Mine):

void Mine::ff() // oops, I meant f()
{
// ...
}

but this does not; it adds a new function instead:

namespace Mine
{
void ff()
{
// ...
}
}

I do not find this rationale very convincing, because you will still
get a link error when you try to call f(). (Also, the rationale only
applies to non-member functions. With members, you would get a
compile error with either form.) However, perhaps I have missed
something.

The second form has the benefit that it is less verbose in the usual
case where many functions are being defined in the same namespace.
Also, it avoids cluttering the function definition.

Which would you consider the preferred form? And is it the same for
both members and non-members?

Ivan Johnson


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Michael]

{ reformatted; please limit your lines to 70 characters -mod }

On Monday, May 7, 2012 3:49:58 AM UTC-5, Ivan wrote:
> I do not find this rationale very convincing, because you will still
> get a link error when you try to call f().

*Somebody* will get a link error, but it might not be you (the author)
-- because your code might not call Mine::f(). Bjarne's syntax
ensures that the namespace author will always get the compilation
error.

Of course, the opposite situation is also a problem: You could forget
to put the namespace qualifier on the function definition. Then
you're back to depending on a linker error. So neither is foolproof.

Myself, I agree with Bjarne for similar reasons -- there is no
confusion between a declaration and a definition. As a small bonus,
the definitions are also fully self-contained, improving readability.


Mike

[FredK]

{ Please limit your quoting to the minimum needed to establish context
-mod }

Not necessarily. What if you created f() somewhere, but forgot that
you did. Then you create it again, misnaming it ff(), this time with
slightly different functionality than the original. It links fine, you
run the program, and you can't figure out why it doesn't calculate
thinbgs properly. You put a breakpoint in ff, run it in a debugger,
and now you're really confused, because the program never reaches the
breakpoint!

> The second form has the benefit that it is less verbose in the usual
> case where many functions are being defined in the same namespace.
> Also, it avoids cluttering the function definition.
>
> Which would you consider the preferred form? And is it the same for
> both members and non-members?
>

[jack....@perkinelmer.com]

On May 7, 4:49 am, Ivan <ivan_j_john...@msn.com> wrote:
> namespace Mine
> {
> void ff()
> {
> // ...
> }
>
> }
>

This gets my vote.

> I do not find this rationale very convincing, because you will still
> get a link error when you try to call f(). (Also, the rationale only
> applies to non-member functions. With members, you would get a
> compile error with either form.) However, perhaps I have missed
> something.
>

At work we discourage the using namespace syntax.
So the call would be Mine::f() which gives a compiler error.

If the namespace is long and it's tedious to type in then use:
using Mine::f();

[Gene Bushuyev]

On May 7, 1:49 am, Ivan <ivan_j_john...@msn.com> wrote:
> When a function is declared in a namespace, for example:

> I do not find this rationale very convincing, because you will still
> get a link error when you try to call f(). (Also, the rationale only
> applies to non-member functions. With members, you would get a
> compile error with either form.) However, perhaps I have missed
> something.

Finding an error at compile time instead of link time should be pretty
convincing rationale of itself: it's earlier; it's straightforward,
unlike linker errors. In fact if the function is a template you'll
never notice an error until the function is instantiated. Then there
are sometimes unsanitary macros which would redefine the names in
different ways: you may be baffled to see that everything is spelled
correctly in your code, but the linker still complains the function
being undefined.

Another advantage of qualified function definitions is being easily
searchable, which is important when dealing with large code base.