Updated:
I created a project that can 100% reproduce the problem.
1. DLL Project
I named this DLL project TestDLL
The most important codes:
AddC.h:
#pragma once
class CTestDLL;
#include <string>
using namespace std;
//use AddC somewhere inside the DLL internally
class AddC{
private:
string _fake_string_ = "_fake_string_";
void _fake_method_();
public:
void add2Result(CTestDLL* test);
};
AddC.cpp:
#include "pch.h"
#include "AddC.h"
#include "TestDLL.h"
void AddC::_fake_method_()
{
_fake_string_ = "_fake_string_in_fake_method_";
}
void AddC::add2Result(CTestDLL * test)
{
test->result += 1;
}
TestDLL.h:
#ifdef TESTDLL_EXPORTS
#define TESTDLL_API __declspec(dllexport)
#else
#define TESTDLL_API __declspec(dllimport)
#endif
#include "AddC.h"
class TESTDLL_API CTestDLL {
public:
CTestDLL(void);
void test();
int getResult();
private:
friend class AddC;
private:
AddC addc;
int result=0;
};
TestDLL.cpp:
#include "pch.h"
#include "framework.h"
#include "TestDLL.h"
CTestDLL::CTestDLL(){
result = 0;
return;
}
void CTestDLL::test(){
auto _this = this;
addc.add2Result(_this);
}
int CTestDLL::getResult(){
return this->result;
}
2. SimpleTestApplication Project
The TestApplication has only two code files.
dll.hpp:
#pragma once
class AddC{};
class CTestDLL {
public:
CTestDLL(void);
void test();
int getResult();
private:
int result = 0;
AddC addc;
};
app.cpp:
#include "dll.hpp"
#include <iostream>
using namespace std;
#pragma comment(lib, "TESTDLL.lib")
int main(){
CTestDLL test;
test.test();
test.test();
test.test();
cout << test.getResult() << endl;
return 0;
}
The testApplication compile and link successfully.
But,But.When the main function exits, the program throws an exception that the stack was corrupted.
The key point is 'fake string_' variable in AddC.
But I don't how to do.
Previous:
Like this on a dll project:
class B;
class C;
class __declspec(dllexport) A{
private:
friend class B;
friend class C;
}
And I compiled the dll project;
Use .dll,.lib and the following header file on a simple console project:
dll.hpp:
class __declspec(dllimport) A{
private:
friend class B;
friend class C;
}
The main func:
#include "dll.hpp"
#pragma comment(lib, "dll.lib")
int main(){
A a;
return 0;
}
It compiled successfully.But the program threw an exception when running:
Run-Time Check Failure #2 - Stack around the variable 'a' was corrupted.
Who can help me?
#selbie's suggestion regarding the factory function / method creating is the cleanest way to go (would prevent you from ending in situations like this), and design-wise it makes the most sense, but it's not mandatory (after all there are lots of .dlls out there exporting classes).
What jumped into my eye, was the fact that (in both scenarios) a header file was present in the application that was (somewhat) duplicating the (main) one in the .dll. Every .dll comes with its own header file(s), and those are the ones that should be used by its clients (apps or other dlls). They are both maintained by the dll creators, and when updates come, they are both in sync. Doing otherwise is not scalable (each app creating its own header file version), makes no sense, and I don't know why would anyone do something like that.
With this in mind, I recreated the environment (both scenarios), doing things the right way, and everything worked fine, then I worked my way to your (wrong) way, trying to identify the culprit.
Example (numbered the 2 scenarios: 00 and 01):
DllExport.h:
#pragma once
#if defined(_WIN32)
# if defined(DLL_STATIC)
# define DLL_EXPORT_API
# else
# if defined(DLL_EXPORTS)
# define DLL_EXPORT_API __declspec(dllexport)
# else
# define DLL_EXPORT_API __declspec(dllimport)
# endif
# endif
#else
# define DLL_EXPORT_API
#endif
Scenario 00:
AddC.hpp:
#pragma once
#include <string>
using namespace std;
class CTestDLL;
//use AddC somewhere inside the DLL internally
class AddC {
private:
string _fake_string_ = "_fake_string_";
void _fake_method_();
public:
void add2Result(CTestDLL *pTest);
};
TestDLL.hpp:
#pragma once
#include <DllExport.h>
#include <AddC.hpp>
class DLL_EXPORT_API CTestDLL {
public:
CTestDLL();
void test();
int getResult();
private:
friend class AddC;
private:
AddC addc;
int result = 0;
};
dll:
AddC.cpp:
#include "AddC.hpp"
#include "TestDLL.hpp"
void AddC::_fake_method_()
{
_fake_string_ = "_fake_string_in_fake_method_";
}
void AddC::add2Result(CTestDLL *pTest)
{
pTest->result += 1;
}
TestDLL.cpp:
#define DLL_EXPORTS
#include <TestDLL.hpp>
CTestDLL::CTestDLL()
{
result = 0;
return;
}
void CTestDLL::test()
{
auto _this = this;
addc.add2Result(_this);
}
int CTestDLL::getResult()
{
return this->result;
}
app:
dll.hpp:
#pragma once
#define _WRONG_INNER_CLASS
#if defined(_WRONG_INNER_CLASS)
class AddC {};
#else
# include <AddC.hpp>
#endif
#define _WRONG_IMPORT_DIRECTIVE
#if defined(_WRONG_IMPORT_DIRECTIVE)
# define CLASS_IMPORT_API
#else
# define CLASS_IMPORT_API __declspec(dllimport)
#endif
class CLASS_IMPORT_API CTestDLL {
public:
CTestDLL();
void test();
int getResult();
private:
int result = 0;
AddC addc;
};
main.cpp:
#include <iostream>
#include <cstdio>
#define _DUPLICATE_DLL_HEADER_FILE
#if defined (_DUPLICATE_DLL_HEADER_FILE)
# include <dll.hpp>
#else
# include <TestDll.hpp>
#endif
#pragma comment(lib, "dll.lib")
using std::cout;
using std::endl;
int main()
{
CTestDLL test;
test.test();
test.test();
test.test();
cout << test.getResult() << endl;
printf("Done.\n");
return 0;
}
Scenario 01:
dll.hpp:
#pragma once
#include <DllExport.h>
class DLL_EXPORT_API A {
private:
friend class B;
friend class C;
};
dll:
dll.cpp:
#define DLL_EXPORTS
class B;
class C;
#include <dll.hpp>
app:
AppDll.hpp:
#pragma once
#define CLASS_IMPORT_API __declspec(dllimport)
class CLASS_IMPORT_API A {
private:
friend class B;
friend class C;
};
main.cpp:
#include <cstdio>
#define _DUPLICATE_DLL_HEADER_FILE
#if defined (_DUPLICATE_DLL_HEADER_FILE)
# include "AppDll.hpp"
#else
# include <dll.hpp>
#endif
#pragma comment(lib, "dll.lib")
int main()
{
A a;
printf("Done.\n");
return 0;
}
Project structure:
Results:
Scenario 00:
There were 2 mistakes:
Class AddC redefinition
Missing import directive for CTestDll
In dll.hpp there are 2 _WRONG* macros. If both are commented, it will work
Scenario 01:
I couldn't reproduce the crash (with / without friends)
Note: Tested with VStudio 2022 and MSSDK 10.0.22000.0
I have these three source files:
test.h
#ifndef __TESTH
#define __TESTH
#ifdef __cplusplus
#define EXTERNC extern "C"
#else
#define EXTERNC
#endif
typedef struct {
uint8_t value;
} my_struct;
EXTERNC void initialise();
EXTERNC void load(my_struct**);
#endif
test.cpp:
#include <cstdint>
#include "test.h"
my_struct test;
void initialise() {
test.value = 200;
}
void load(my_struct** struct_ptr) {
*struct_ptr = &test;
}
main.cpp:
#include <cstdint>
#include <iostream>
#include "test.h"
my_struct *test;
int main() {
initialise();
load(&test);
while (true) {
std::cout << test->value << std::endl;
}
}
When I compile it, the linker gives me an error telling me that test has been defined multiple times (first defined in test.cpp).
Why? To me it seems like it doesn't leave the scope of test.cpp.
And when I remove the definition of test in main.cpp, it gives me an undefined error!
Thank you for taking the time out of your day to help me.
I think you would need to scope test.cpp's test variable to that file only, assuming your test pointer in main.cpp is different than test in test.cpp
namespace {
my_struct test;
}
See here
Instead of writing each function in " extern "C" {} ", can I write entire header file inside that block.
extern "C"
{
#include "myCfile.h"
}
I have tried this but Its not working at all, why it is not working ?
if we have to use 100 C functions in a c++ project, do we need provide all the functions in a
extern block, is there any other simple way ?
Ex:
extern "C"
{
void fun1();
void fun2();
void fun3();
void fun4();
void fun5();
.
.
.
.
fun100();
}
Is there any other simple way, like extern "C" { myCfunctions.h } ???
#include simply includes the specified header at the location of the #include. Whether it's valid depends on what "myCfile.h" contains. In particular, including any standard library headers in such a context is not valid, and may well break on commonly used implementations.
The usual way to handle this is to make the header itself safe to use from C++. A C-only header might contain
#ifndef H_MYCFILE
#define H_MYCFILE
#include <stddef.h>
void mycfunc1(void);
void mycfunc2(int i);
void mycfunc3(size_t s);
#endif
Adapting this to make it safe to use from C++:
#ifndef H_MYCFILE
#define H_MYCFILE
#include <stddef.h>
#ifdef __cplusplus
extern "C" {
#endif
void mycfunc1(void);
void mycfunc2(int i);
void mycfunc3(size_t s);
#ifdef __cplusplus
}
#endif
#endif
With such a header, you wouldn't be able to safely put the entire header in an extern "C" block. However, that header itself can make sure not to put #include <stddef.h> in an extern "C" block, but still to put all function declarations in a single extern "C" block, avoiding having to repeat it for each one.
You are doing something wrong.
Because
extern "C" { myCfunctions.h }
should work. See below sample program.
Lets go by example code.
ctest1.c
#include<stdio.h>
void ctest1(int *i)
{
printf("This is from ctest1\n"); // output of this is missing
*i=15;
return;
}
ctest2.c
#include<stdio.h>
void ctest2(int *i)
{
printf("This is from ctest2\n"); // output of this is missing
*i=100;
return;
}
ctest.h
void ctest1(int *);
void ctest2(int *);
Now lets make c library from that
gcc -Wall -c ctest1.c ctest2.c
ar -cvq libctest.a ctest1.o ctest2.o
Now lets make cpp based file which will use this c apis
prog.cpp
#include <iostream>
extern "C" {
#include"ctest.h"
}
using namespace std;
int main()
{
int x;
ctest1(&x);
std::cout << "Value is" << x;
ctest2(&x);
std::cout << "Value is" << x;
}
Now lets compile this c++ program with C library
g++ prog.cpp libctest.a
Output is :
Value is15Value is100
We have a large project with C and C++ code.
For every C++ implementation, apart from the C++ header, we usually have provide a C-header to allow functionality to be available for .c files, also.
So, most of our files look like so:
foo.hpp:
class C {
int foo();
};
foo.h:
#ifdef __cplusplus
extern "C" {
typedef struct C C; // forward declarations
#else
class C;
#endif
int foo( C* ); // simply exposes a member function
C* utility_function( C* ); // some functionality *not* in foo.hpp
#ifdef __cplusplus
}
#endif
foo.cpp:
int C::foo() { /* implementation here...*/ }
extern "C"
int foo( C *p ) { return p->foo(); }
extern "C"
C* utility_function ( C* ) { /* implementation here...*/ }
QUESTION:
Suppose I wanted to add a namespace to the class like so:
foo.hpp:
namespace NS {
class C {
int foo();
};
}
what is the best scheme to follow in the C-headers?
I have considered a few options, but I'm looking for the most elegant, safe and easy to read. Is there a standard way you use?
Here are the options I've considered:
(I've ommitted the extern "C" constructs for simplicity)
Option 1: fool the compiler by adding some code in each header:
foo.h
#ifdef __cplusplus
namespace NS { class C; } // forward declaration for C++
typedef NS::C NS_C;
#else
struct NS_C; // forward declaration for C
#endif
int foo( NS_C* );
NS_C* utility_function( NS_C* );
this adds some complexity to the header, but keeps the implementations unchanged.
Option 2: Wrap the namespace with a C-struct:
Keeps the header simple but makes the implementation more complex:
foo.h
struct NS_C; // forward declaration of wrapper (both for C++ and C)
int foo( NS_C* );
NS_C* utility_function( NS_C* );
foo.cpp
namespace NS {
int C::foo() { /* same code here */ }
}
struct NS_C { /* the wrapper */
NS::C *ptr;
};
extern "C"
int foo( NS_C *p ) { return p->ptr->foo(); }
extern "C"
NS_C *utility_function( NS_C *src )
{
NS_C *out = malloc( sizeof( NS_C ) ); // one extra malloc for the wrapper here...
out->ptr = new NS::C( src->ptr );
...
}
are these the only schemes? Are there any hidden disadvantages in any of these?
I find it easier to factor code in a way so that foo.h only contains the bare minimum of C++ specifics while foo.hpp takes care of the gritty bits.
The file foo.h contains the C API and should not be included directly from C++ code:
#ifndef NS_FOO_H_
#define NS_FOO_H_
// an incomplete structure type substitutes for NS::C in C contexts
#ifndef __cplusplus
typedef struct NS_C NS_C;
#endif
NS_C *NS_C_new(void);
void NS_C_hello(NS_C *c);
#endif
The file foo.hpp contains the actual C++ API and takes care of including foo.h into C++ files:
#ifndef NS_FOO_HPP_
#define NS_FOO_HPP_
namespace NS {
class C {
public:
C();
void hello();
};
}
// use the real declaration instead of the substitute
typedef NS::C NS_C;
extern "C" {
#include "foo.h"
}
#endif
The implementation file foo.cpp is written in C++ and thus includes foo.hpp, which also pulls in foo.h:
#include "foo.hpp"
#include <cstdio>
using namespace NS;
C::C() {}
void C::hello() {
std::puts("hello world");
}
C *NS_C_new() {
return new C();
}
void NS_C_hello(C *c) {
c->hello();
}
If you do not want to make the C API available to C++ code, you could move the relevant parts from foo.hpp to foo.cpp.
As an example for use of the C API a basic file main.c:
#include "foo.h"
int main(void)
{
NS_C *c = NS_C_new();
NS_C_hello(c);
return 0;
}
This example has been tested with the MinGW edition of gcc 4.6.1 using the following compiler flags:
g++ -std=c++98 -pedantic -Wall -Wextra -c foo.cpp
gcc -std=c99 -pedantic -Wall -Wextra -c main.c
g++ -o hello foo.o main.o
The code assumes that the types NS::C * and struct NS_C * have compatible representation and alignment requirements, which should be the case virtually everywhere, but as far as I know is not guaranteed by the C++ standard (feel free to correct me if I'm wrong here).
From a C language perspective, the code actually invokes undefined behaviour as you're technically calling a function through an expression of incompatible type, but that's the price for interoperability without wrapper structures and pointer casts:
As C doesn't know how to deal with C++ class pointers, the portable solution would be to use void *, which you should probably wrap in a structure to get back some level of type safety:
typedef struct { void *ref; } NS_C_Handle;
This would add unnecessary boilerplate on platforms with uniform pointer representation:
NS_C_Handle NS_C_new() {
NS_C_Handle handle = { new C() };
return handle;
}
void NS_C_hello(NS_C_Handle handle) {
C *c = static_cast<C *>(handle.ref);
c->hello();
}
On the other hand, it would get rid of the #ifndef __cplusplus in foo.h, so it's actually not that bad, and if you care about protability, I'd say go for it.
I don't fully understand what you're trying to do, but this may help:
If you want it still accessible by C then do this:
void foo();
namespace ns {
using ::foo;
}
Or use a macro:
#ifdef __cplusplus
#define NS_START(n) namespace n {
#define NS_END }
#else
#define NS_START(n)
#define NS_END
#endif
NS_START(ns)
void foo();
NS_END
Your header is all messed up.
You probably want something more like:
struct C;
#ifdef __cplusplus
extern "C" {
#else
typedef struct C C;
#endif
/* ... */
#ifdef __cplusplus
}
#endif
Is there a way to (ab)use the C preprocessor to emulate namespaces in C?
I'm thinking something along these lines:
#define NAMESPACE name_of_ns
some_function() {
some_other_function();
}
This would get translated to:
name_of_ns_some_function() {
name_of_ns_some_other_function();
}
Another alternative would be to declare a struct to hold all your functions, and then define your functions statically. Then you'd only have to worry about name conflicts for the global name struct.
// foo.h
#ifndef FOO_H
#define FOO_H
typedef struct {
int (* const bar)(int, char *);
void (* const baz)(void);
} namespace_struct;
extern namespace_struct const foo;
#endif // FOO_H
// foo.c
#include "foo.h"
static int my_bar(int a, char * s) { /* ... */ }
static void my_baz(void) { /* ... */ }
namespace_struct const foo = { my_bar, my_baz }
// main.c
#include <stdio.h>
#include "foo.h"
int main(void) {
foo.baz();
printf("%d", foo.bar(3, "hello"));
return 0;
}
In the above example, my_bar and my_baz can't be called directly from main.c, only through foo.
If you have a bunch of namespaces that declare functions with the same signatures, then you can standardize
your namespace struct for that set, and choose which namespace to use at runtime.
// goo.h
#ifndef GOO_H
#define GOO_H
#include "foo.h"
extern namespace_struct const goo;
#endif // GOO_H
// goo.c
#include "goo.h"
static int my_bar(int a, char * s) { /* ... */ }
static void my_baz(void) { /* ... */ }
namespace_struct const goo = { my_bar, my_baz };
// other_main.c
#include <stdio.h>
#include "foo.h"
#include "goo.h"
int main(int argc, char** argv) {
namespace_struct const * const xoo = (argc > 1 ? foo : goo);
xoo->baz();
printf("%d", xoo->bar(3, "hello"));
return 0;
}
The multiple definitions of my_bar and my_baz don't conflict, since they're defined statically, but the underlying functions are still accessible through the appropriate namespace struct.
When using namespace prefixes, I normally add macros for the shortened names which can be activated via #define NAMESPACE_SHORT_NAMES before inclusion of the header. A header foobar.h might look like this:
// inclusion guard
#ifndef FOOBAR_H_
#define FOOBAR_H_
// long names
void foobar_some_func(int);
void foobar_other_func();
// short names
#ifdef FOOBAR_SHORT_NAMES
#define some_func(...) foobar_some_func(__VA_ARGS__)
#define other_func(...) foobar_other_func(__VA_ARGS__)
#endif
#endif
If I want to use short names in an including file, I'll do
#define FOOBAR_SHORT_NAMES
#include "foobar.h"
I find this a cleaner and more useful solution than using namespace macros as described by Vinko Vrsalovic (in the comments).
You could use the ## operator:
#define FUN_NAME(namespace,name) namespace ## name
and declare functions as:
void FUN_NAME(MyNamespace,HelloWorld)()
Looks pretty awkward though.
I use the struct-based approach, with two refinements: I add substructures to create hierarchical namespaces, and I define some simple macros when I want to simplify namespaces' path.
Let's take a Foobar library as an example.
foobar.h
#ifndef __FOOBAR_H__
#define __FOOBAR_H__
// definition of the namespace's hierarchical structure
struct _foobar_namespace {
struct {
void (*print)(char *s);
} text;
struct {
char *(*getDateString)(void);
} date;
};
// see the foobar.c file
// it must be the only one defining the FOOBAR macro
# ifndef FOOBAR
// definition of the namespace global variable
extern struct _foobar_namespace foobar;
# endif // FOOBAR
#endif // __FOOBAR_H__
foobar.c
// the FOOBAR macro is needed to avoid the
// extern foobar variable declaration
#define FOOBAR
#include "foobar.h"
#include "foobar_text.h"
#include "foobar_date.h"
// creation of the namespace global variable
struct _foobar_namespace foobar = {
.text = {
.print = foobar_text__print
},
.date = {
.getDateString = foobar_date__getDateString
}
};
Then, it's possible to use the namespace:
#include "foobar.h"
void main() {
foobar.text.print("it works");
}
But there is not so much difference between foobar_text__print() and foobar.text.print(). I think the second one is more readable, but it's questionable. So it become really useful by defining some macros to simplify these namespaces:
#include "foobar.h"
#define txt foobar.text
#define date foobar.date
void main() {
char *today = date.getDateString();
txt.print(today);
}
This kind of hierarchical namespaces is fast to define, easy to understand, and decrease code verbosity.
Just for fun, here are the files for foobar.text code:
foobar_text.h
#ifndef __FOOBAR_TEXT_H__
#define __FOOBAR_TEXT_H__
void foobar_text__print(char *s);
#endif // __FOOBAR_TEXT_H__
foobar_text.c
#include <stdio.h>
#include "foobar_text.h"
void foobar_text__print(char *s) {
printf("%s\n", s);
}
I came up with the following scheme :
(header)
// NS_PREFIX controls the prefix of each type and function declared in this
// header, in order to avoid name collision.
#define NS_PREFIX myprefix_
// Makes a string from argument (argument is not macro-expanded).
#define stringify(arg) #arg
// Concatenation that macro-expands its arguments.
#define concat(p1, p2) _concat(p1, p2) // Macro expands the arguments.
#define _concat(p1, p2) p1 ## p2 // Do the actual concatenation.
// Append the namespace prefix to the identifier.
#define ns(iden) concat(NS_PREFIX, iden)
// header content, for instance :
void ns(my_function)(int arg1, ns(t) arg2, int arg3);
// Allow implementation files to use namespacing features, else
// hide them from the including files.
#ifndef _IMPL
#undef NS_PREFIX
#undef ns
#undef stringify
#undef concat
#undef _concat
#endif // _IMPL
(implementation)
#define _IMPL
#include "header.h"
#undef __IMPL
I wrote up a tutorial on how to get the advantage of namespaces and/or templates using C.
Namespaces and templates in C
Namespaces and templates in C (using Linked Lists)
For the basic namespace, one can simply prefix the namespace name as a convention.
namespace MY_OBJECT {
struct HANDLE;
HANDLE *init();
void destroy(HANDLE * & h);
void do_something(HANDLE *h, ... );
}
can be written as
struct MY_OBJECT_HANDLE;
struct MY_OBJECT_HANDLE *my_object_init();
void my_object_destroy( MY_OBJECT_HANDLE * & h );
void my_object_do_something(MY_OBJECT_HANDLE *h, ... );
A second approach that I have needed that uses the concept of namespacing and templates is to use the macro concatenation and include. For example, I can create a
template<T> T multiply<T>( T x, T y ) { return x*y }
using template files as follows
multiply-template.h
_multiply_type_ _multiply_(multiply)( _multiply_type_ x, _multiply_type_ y);
multiply-template.c
_multiply_type_ _multiply_(multiply)( _multiply_type_ x, _multiply_type_ y) {
return x*y;
}
We can now define int_multiply as follows. In this example, I'll create a int_multiply.h/.c file.
int_multiply.h
#ifndef _INT_MULTIPLY_H
#define _INT_MULTIPLY_H
#ifdef _multiply_
#undef _multiply_
#endif
#define _multiply_(NAME) int ## _ ## NAME
#ifdef _multiply_type_
#undef _multiply_type_
#endif
#define _multiply_type_ int
#include "multiply-template.h"
#endif
int_multiply.c
#include "int_multiply.h"
#include "multiply-template.c"
At the end of all of this, you will have a function and header file for.
int int_multiply( int x, int y ) { return x * y }
I created a much more detailed tutorial on the links provided. Hopefully this helps someone!
An approach similar to the accepted answer is the following:
// inclusion guard
#ifndef FOOBAR_H_
#define FOOBAR_H_
// long names
void foobar_some_func(int);
void foobar_other_func();
// qualified names
#ifdef FOOBAR_SHORT_NAMES
extern struct _foobar {
void (*some_func)(int);
void (*other_func)();
} foobar;
#endif
#endif
this header file shall come with a .c file:
#include "foobar.h"
struct _foobar foobar = {
foobar_some_func;
foobar_other_func;
};
when using the functions,
foobar.some_func(10);
foobar.other_func();
You can use a helper #define macro:
#include <stdio.h>
#define ns(x) gargantua_ ## x
struct ns(stats) {
int size;
};
int ns(get_size)(struct ns(stats) *st) {
return st->size;
}
void ns(set_size)(struct ns(stats) *st, int sz) {
st->size = sz;
}
int main(void) {
struct ns(stats) stats = {0};
ns(set_size)(&stats, 3);
printf("size=%d\n", ns(get_size)(&stats));
return 0;
}
Running it through the preprocessor gives you:
struct gargantua_stats {
int size;
};
int gargantua_get_size(struct gargantua_stats *st) {
return st->size;
}
void gargantua_set_size(struct gargantua_stats *st, int sz) {
st->size = sz;
}
int main(void) {
struct gargantua_stats stats = {0};
gargantua_set_size(&stats, 3);
printf("size=%d\n", gargantua_get_size(&stats));
return 0;
}
One can use prefixes for file function names, like in stb single-file public domain libraries for C/C++: "as a moderately sane way of namespacing the filenames and source function name".
Examples:
stb_image_write.h ( file name )
STBI_THREAD_LOCAL ( name )
static void *stbi__malloc_mad4(int a, int b, int c, int d, int add)
here is an example that builds off above approaches and combines them for both funcs and structures to create pseudo-namespaces NAMESPACE1 and NAMESPACE2. the benefit of this over having a structure that holds functions is that the structure-holding-functions approach requires a standardized structure across multiple pseudo-namespaces, and this is not always possible (either at all, or without a lot of work that arguably does not improve the code) or desirable.
Not sure if the macro expansion order could be an issue but this works on GCC and seems to minimize the amount of code changes required, while maintaining decent (though far from ideal) readability.
application.c:
#include <stdio.h>
#include "header1.h"
#include "header2.h"
/* use NAMESPACE1 and NAMESPACE2 macros to choose namespace */
int main() {
NAMESPACE1(mystruct) data1; // structure specific to this namespace
NAMESPACE2(mystruct) data2;
data1.n1 = '1';
data1.c = 'a';
data2.n2 = '2';
data2.c = 'a';
NAMESPACE1(print_struct)(&data1); // function specific to this namespace
NAMESPACE2(print_struct)(&data2);
}
header1.h
/* the below block is unnecessary, but gets rid of some compiler warnings */
#ifdef NAMESPACE_REAL
#undef NAMESPACE_REAL
#endif
/* edit the below lines to change the three occurrences of NAMESPACE1 to the desired namespace */
#define NAMESPACE1(name) NAMESPACE1 ## _ ## name
#define NAMESPACE_REAL(name) NAMESPACE1(name)
/* don't edit the next block */
#define TYPEDEF(name, ...) typedef struct NAMESPACE_REAL(name) { __VA_ARGS__ } NAMESPACE_REAL(name)
#define STRUCT(name) struct NAMESPACE_REAL(name)
#define FUNC(name) NAMESPACE_REAL(name)
/* normal header code, using FUNC and STRUCT macros */
#include <stdio.h>
TYPEDEF(mystruct,
char n1;
char c;
);
void FUNC(print_struct)(STRUCT(mystruct) *data);
/* don't edit the rest */
#undef TYPEDEF
api1.c:
#include "header1.h"
/* normal code, using FUNC and STRUCT macros */
void FUNC(print_struct)(STRUCT(mystruct) *data) {
printf("this is the struct from namespace1: %c %c\n", data->n1, data->c);
}
/* don't edit the rest */
#undef STRUCT
#undef FUNC
#undef NAMESPACE
#undef NAMESPACE_REAL
Other code in header2.h and api2.c is the same as header1.h and header2.h, modified for namespace "NAMESPACE2"
I realize that this is an old question (11 years old), but I was trying to accomplish essentially what I think you wanted originally as you have listed above.
I wanted there to be a namespace prepended to my functions. But I wanted the ability to change what that namespace would be. By default I wanted for this example to not have a namespace, but if a naming collision occurred then I wanted the ability to prepend a namespace to all of the functions in my library. (This is slightly backwards compared to C++ where there is a namespace by default and you use using namespace whatever to remove the need to specify the namespace every time.) However, just like C++ if you drop in a using namespace statement and alias your code, you will need to update your calling code. You could write some other macro sequence to auto rename your calls as well, but that is outside the scope of what I think you were looking for.
#include <stdio.h>
#define NAMESPACE(...) test_ //Use this as my prepender
//Where all the magic happens which could be included in a header file.
#ifndef NAMESPACE
//No Namespace by default
#define NAMESPACE(...)
#endif
//Actual replacements
#define NSPREPENDER(...) NSPROCESSING(NAMESPACE(), __VA_ARGS__)
#define NSPROCESSING(...) NSFINALIZE(__VA_ARGS__)
#define NSFINALIZE(a,b) a ## b
//BEGIN ACTUAL PROGRAM
//Prototype
void NSPREPENDER(myprint)();
int main()
{
test_myprint(); //If NAMESPACE(...) is defined to anything else, this code must change.
return 0;
}
//Implementation
void NSPREPENDER(myprint)()
{
puts("Testing");
}
This code will compile only on C99 and up since it is using variadic macros. These macros do a form of recursion which is all done so that we can grab the value out of a macro defined at the top.
Breakdown of all it works:
We define that we want our namespace to be.
If nothing is defined set a default
Do a bunch of calls to bypass and (ab)use preprocessor functionality.
Add the NSPREPENDER macro function to each c function so that it can be name mangled.
Write code using mangled names since the name will be properly mangled by the time the compiler see it.
This code was tested with clang.