Placing functions from .lib in a namespace?

[Leon]

Hi all.

For my application I'm using a third-party library which is supplied as a
library file (.lib) and an associated header file to prototype the functions
defined in the library. Important is that the library is already compiled.

Now, this library defines only functions, and they are declared in the
global namespace. Since this is rather ugly and inconvenient, I want to
place these functions in their own namespace.

Is it possible to change the fully qualified names of these functions if
they're already compiled, or maybe is there another way to get these
functions in their own namespace?

Thanks,
Leon.

 

[Jeff Schwab]

Hi all.

For my application I'm using a third-party library which is supplied as a
library file (.lib) and an associated header file to prototype the functions
defined in the library. Important is that the library is already compiled.

Now, this library defines only functions, and they are declared in the
global namespace. Since this is rather ugly and inconvenient, I want to
place these functions in their own namespace.

Is it possible to change the fully qualified names of these functions if
they're already compiled, or maybe is there another way to get these
functions in their own namespace?

I've usually gotten away with this:

namespace Acme
{
#include "acme_headers.h"
}

Acme::func( );

If that doesn't work, try:

namespace Acme
{
#include "acme_headers.h"
}

using namespace Acme;

func( );

It's just a band-aid, of course, but at least it's explicit.

 

[Pete Becker]

I've usually gotten away with this:

namespace Acme
{
#include "acme_headers.h"
}

Acme::func( );

If that doesn't work, try:

namespace Acme
{
#include "acme_headers.h"
}

using namespace Acme;

func( );

It's just a band-aid, of course, but at least it's explicit.

Can't work. Acme::func is a different function from ::func. The library
defines 'extern "C" func", so calls to Acme::func won't link.

Even if you can recompile the library this probably won't work: the
behavior of a program that includes any standard headers inside a
namespace declaration is undefined, and chances are good that
"acme_headers.h" will do just that.

 

[Pete Becker]

Hi all.

For my application I'm using a third-party library which is supplied as a
library file (.lib) and an associated header file to prototype the functions
defined in the library. Important is that the library is already compiled.

Now, this library defines only functions, and they are declared in the
global namespace. Since this is rather ugly and inconvenient, I want to
place these functions in their own namespace.

Is it possible to change the fully qualified names of these functions if
they're already compiled, or maybe is there another way to get these
functions in their own namespace?

Nope. If you like busywork, though, you could write wrapper functions
inside a namespace that call the global ones in the library. But you
really haven't accomplished anything: the globals are still global.
Don't fight the library. Use it the way it's written, or rewrite it.

 

[Leon]

I've usually gotten away with this:

namespace Acme
{
#include "acme_headers.h"
}

Acme::func( );

If that doesn't work, try:

namespace Acme
{
#include "acme_headers.h"
}

using namespace Acme;

func( );

It's just a band-aid, of course, but at least it's explicit.

Hmm, ok, but if I'm correct this construction will produce link errors,
since the functions are now prototyped in the Acme namespace, but still
defined in the global namespace (since that's where they were defined when
the .lib was compiled).
When linking, the compiler will not be able to find the definitions for
Acme::func(), only for ::func() ?

Or am I missing something here?

Cheers,
Leon.

 

[Alf P. Steinbach]

Can't work. Acme::func is a different function from ::func. The library
defines 'extern "C" func", so calls to Acme::func won't link.

Not necessarily. I participated in a discussion about this many
years ago, and just as an investigation wrote some simple applications
using the Windows API placed in a namespace. Linking wasn't a problem,
but all the macro definitions in the header files were...

In short it's a maintainance nightmare, even where it can be made
to work.

And for header files of the size of the Windows API, say, there's no
practical way to put everything in a namespace at once; instead, if
one chooses to do this thing it's necessary to add more and more (e.g.
macro workarounds) as the need arises.

Even if you can recompile the library this probably won't work: the
behavior of a program that includes any standard headers inside a
namespace declaration is undefined, and chances are good that
"acme_headers.h" will do just that.

Yep.

One non-standard workaround (with formally undefined effect) is to
include the basic C library headers before including the library
header(s). For the Windows API using one particular vendor's headers
that turned out to be just a handful of C library headers. I think it
was four.

Not that I recommend the approach, of course.

 

[Pete Becker]

Not necessarily. I participated in a discussion about this many
years ago, and just as an investigation wrote some simple applications
using the Windows API placed in a namespace. Linking wasn't a problem,
but all the macro definitions in the header files were...

I don't see how that could work. Except, perhaps, with a broken
compiler. The point of typesafe linking is that

int f();

can't be mistaken for

namespace wrapper
{
int f();
}

If a compiler generates the same name for both there's something wrong.

 

[Pete Becker]

Hmm, ok, but if I'm correct this construction will produce link errors,
since the functions are now prototyped in the Acme namespace, but still
defined in the global namespace (since that's where they were defined when
the .lib was compiled).
When linking, the compiler will not be able to find the definitions for
Acme::func(), only for ::func() ?

Or am I missing something here?

Nope. I suspect he was answering a different question. If you can
rebuild the library, then wrapping the headers in a namespace might
work. It's still a bad idea, though.

 

[Alf P. Steinbach]

I don't see how that could work. Except, perhaps, with a broken
compiler. The point of typesafe linking is that

int f();

can't be mistaken for

namespace wrapper
{
int f();
}

If a compiler generates the same name for both there's something wrong.

You're right that the compiler I used was seriously broken... ;-)

On the other hand, I'm not so sure that there's necessarily something
wrong when f is declared 'extern "C"', since that syntactic device is
there precisely in order to be able to link with non-type-safe C functions
(in effect, much simpler name mangling, perhaps just an underscore).

Right now I don't have access to any C++ compiler, nor my old
code, so unfortunately I cannot check whether e.g. MSVC 7.1 still supports
the hack, but I very much suspect that it does, and I suspect (but am
not at all 100% sure) that any conforming compiler must so long as
standard headers are not placed into a namespace.

But again, just in case someone Googles and finds just this posting,
that technique is not something I'd recommend...

 

[Pete Becker]

On the other hand, I'm not so sure that there's necessarily something
wrong when f is declared 'extern "C"', since that syntactic device is
there precisely in order to be able to link with non-type-safe C functions
(in effect, much simpler name mangling, perhaps just an underscore).

Well, that's a surprise: apparently defining an extern "C" function
inside a namespace is equivalent to defining it in the global namespace.
I don't see any support for that in the standard, but the compilers I
tried it with seem to do that, so I'm probably overlooking something.

 

[Jeff Schwab]

Nope. I suspect he was answering a different question. If you can
rebuild the library, then wrapping the headers in a namespace might
work. It's still a bad idea, though.

I believe I was answering the right question. This approach really has
worked for me, even when I couldn't recompile the existing library. I
don't have an explanation, though.

 

[tom_usenet]

Well, that's a surprise: apparently defining an extern "C" function
inside a namespace is equivalent to defining it in the global namespace.
I don't see any support for that in the standard, but the compilers I
tried it with seem to do that, so I'm probably overlooking something.

7.5/6 says that an extern "C" declaration refers to the same function
regardless of the namespace it appears in.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

 

[Pete Becker]

7.5/6 says that an extern "C" declaration refers to the same function
regardless of the namespace it appears in.

Thanks.