Prev: templates and default parameters
Next: UTF-8 messages in exceptions ?
From: Daniel Krügler on 21 Jul 2010 21:28
On 22 Jul., 03:00, Daniel James <dan...(a)me.invalid> wrote:
> In article <c59b7f44-af05-45ca-a4b2-
>
> 822f5dfee...(a)y11g2000yqm.googlegroups.com>, Daniel Kr�gler wrote:
> > In general it is a bad idea to use unnamed namespaces
> > within a (shared) header file, because this can easily lead to
> > violations of the ODR, especially if the definition is not
> > (inline) within the header.
>
> No, that should not happen.
>
> It is normally quite OK to define objects with the same name and signature in an anonymous namespace in different compilation units, and the anonymous namespace mechanism ensures that these refer to *different* objects whose names cannot be confused.
> (What actually happens under the covers in implementations with which I am familiar is that the names are mangled in some way that is unique to the compilation unit.)
>

The violation of the ODR occurs, if *different*
translation units *use* the (different) functions
from the same header, but only *one* translation
unit defines it. My intention was to describe this
situation.

> > In case of extern "C" functions this cannot happen, because all
> > of these functions will refer to the same entity.
>
> With extern "C" the names cannot be mangled, so the ODR *is* violated.

I was referring to the same situation as above,
but now the argumentation inverted because
of the special property of C-linkage functions
with external name linkage:

If multiple translations units use the same
external C-linkage function, but only *and*
exactly *one* translation unit defines it, it
is OK. Example:

// A.h:
namespace A {
extern "C" void foo(); // Declared, not defined.
}

// A.cpp:
#include <A.h>

// Use foo(), but don't define it.

// B.h:
namespace B {
extern "C" void foo(); // Declared, not defined.
}

// B.cpp:
#include <B.h>

extern "C" void foo() {}

This is OK, because exactly one definition exists.

I didn't want to imply that you cannot construct a
program that violates ODR due to external C-
linkage functions After rereading my sentence in
the embedded context, I agree that it can be
interpreted in this way.

Thanks for pointing this out & Greetings from Bremen,

Daniel Kr�gler



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

From: Daniel Krügler on 21 Jul 2010 23:37
On 22 Jul., 02:59, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
wrote:
> If I correctly understand your intention, the external
> linkage is not needed for the actual program functionality,
> and a static extern "C" function should also work, right?

A "static extern "C"" function does not exist, I meant a
C-linkage function with a name of internal linkage, of-course.
This error in my terminology does not affect the remainder
of my previous posting, though.

Greetings from Bremen,

Daniel Kr�gler


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

From: Chris Vine on 22 Jul 2010 08:57
On Thu, 22 Jul 2010 08:37:36 CST
Daniel Krügler <daniel.kruegler(a)googlemail.com> wrote:
> On 22 Jul., 02:59, Daniel Krügler <daniel.krueg...(a)googlemail.com>
> wrote:
> > If I correctly understand your intention, the external
> > linkage is not needed for the actual program functionality,
> > and a static extern "C" function should also work, right?
>
> A "static extern "C"" function does not exist, I meant a
> C-linkage function with a name of internal linkage, of-course.
> This error in my terminology does not affect the remainder
> of my previous posting, though.

Yes, that works fine, but it also causes any other translation units
which include the header to give a (harmless) warning that there is a
static function without a definition.

I think your proposal of a helper class which is a friend is the way to
go. It hides everything within the implementation file.

Chris



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

From: Daniel James on 23 Jul 2010 23:18
In article <24f8h7-6qe.ln1(a)cvinex--nospam--x.freeserve.co.uk>, Chris
Vine wrote:
> I require a function which must have a C linkage specification (it
> is a callback from a C library) to be a friend of a class in order
> to have access to protected member functions of the class: it forms
> part of the class implementation.

Leaving aside the discussion about anonymous namespaces and returning
to the original question ... have you considered making the callback a
static member of the class itself?

--
Cheers,
Daniel.
Mods: Note that my sending address is invalid to discourage spammers.
I can be reached using djusenet at sonadata in the dot co dot uk tld.




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

From: Francis Glassborow on 24 Jul 2010 23:31
Daniel James wrote:
> In article <24f8h7-6qe.ln1(a)cvinex--nospam--x.freeserve.co.uk>, Chris
> Vine wrote:
>> I require a function which must have a C linkage specification (it
>> is a callback from a C library) to be a friend of a class in order
>> to have access to protected member functions of the class: it forms
>> part of the class implementation.
>
> Leaving aside the discussion about anonymous namespaces and returning
> to the original question ... have you considered making the callback a
> static member of the class itself?
>

Note that to do that you need to get up to some trickery to ensure that
the callback has C linkage.

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

First  |  Prev  | 
Pages: 1 2 3 4
Prev: templates and default parameters
Next: UTF-8 messages in exceptions ?