I need to create some API, with which, by calling a function, the correct one for the current operating system will be called.
So I went with that :
main.cpp :
#include "api.h"
int main() {
helloWorld();
return 0;
}
api.h :
void helloWorld();
api.cpp :
void helloWorld() {
#ifdef __gnu_linux__
printf("Hello World of Linux");
#endif
#ifdef WIN32
printf("Hello World of Windows");
#endif
}
But this doesn't satisfy me. When I'll have big functions, such as the one to get all childs of a process under Linux, and many others, I'll have a problem of space, of visibility to maintain the code.
I tryed to include different headers depending on the underlying OS, but this doesn't work very well, I can't have two headers (one for Windows, one for Linux) and only one C++ file.
So, do you know how I could separate the code for Linux and Windows so I end up with two file (one only for Linux and one only for Windows) with one header file that will have a #ifdef condition ? I couldn't make it work ...
I did it the following way:
main.cpp and api.h does not suffer any modification.
api.cpp:
#ifdef linux
#include "linux_api.h"
#endif
#ifdef WIN32
#include "windows_api.h"
#endif
void helloWorld() {
#ifdef linux
helloWorld_linux();
#endif
#ifdef WIN32
helloWorld_win32();
#endif
}
Then you need to provide linux_api.h, linux_api.cpp and windows_api.h, windows_api.cpp. The advantage is that this four files are already platform specific. You only have to create the "glue code" in api.cpp for each function.
linux_api.h:
void helloWorld_linux();
linux_api.cpp:
#include "linux_api.h"
#include <cstdio>
void helloWorld_linux()
{
std::printf( "Hello world from linux..." );
}
Hope this helps.
Related
Basically I have a dll project in visual studio. I'm linking this dll project to a second project successfully but as soon as I try to use extern variables things go wrong. I've seperated my extern variables into a single header and source file from everything else so I can isolate the problem and potential solutions. I've scowered the internet for hours now and I feel like I've tried everything. I am beginning to think it might be a compile flag? Anyway, heres my code.
macros.h
#pragma once
// dll management
#ifdef TOAST_EXPORT
#ifdef _MSC_VER
#define TAPI __declspec(dllexport)
#else
#define TAPI __attribute__((visibility("default")))
#endif
#else
#ifdef _MSC_VER
#define TAPI __declspec(dllimport)
#else
#define TAPI
#endif
#endif
globals.h
#pragma once
#define TOAST_EXPORT
#include "macros.h"
namespace toast
{
TAPI extern const char c;
}
globals.c
Note that I tried this without const and made no assignment here
#pragma once
#include "globals.h"
namespace toast
{
const char c = 'a';
}
main.c (from the project that compiles to an exe)
#include <globals.h>
int main()
{
char c = toast::c;
return 0;
}
So far I've tried making a lot of subtle changes like reordering extern and const and such. I've also done it both with just extern and just const. Still produces the same unresolved external symbol "char const toast::c" error. Keep in mind that I can create instances of classes and call their methods from the dll successfully and thats with things like class TAPI logger... and such.
What I'm trying to do is provide a library with some defaults set by #define directives in the library header. Those would determine what functions of the library code will be compiled with a given application. In case the application developer needs to add or remove library functions, it should "override" the library's defaults with new values without modifying the library. Besides modifying the library compiled code, those application header's #define values will, in turn, add or remove parts of the application code itself. This is for an embedded system, so even small memory savings are important.
Below are the 4 test files. I can't get it working if it's even possible to do this. Maybe the right question is: What's the correct order of #define / #undef inside the project files?
library.h:
#ifndef MY_LIBRARY_H
#define MY_LIBRARY_H
#include <stdio.h>
#define FUNCTION_1 true
#define FUNCTION_2 false
class Class {
public:
Class();
~Class();
#if FUNCTION_1
void Function_1(void);
#endif
#if FUNCTION_2
void Function_2(void);
#endif
};
#endif // MY_LIBRARY_H
library.cpp:
#include "library.h"
Class::Class() { /* Constructor */ };
Class::~Class() { /* Destructor */ };
#if FUNCTION_1
void Class::Function_1(void) {
printf("Hi, this is %s running ...\n\r", __func__);
}
#endif
#if FUNCTION_2
void Class::Function_2(void) {
printf("Hi, this is %s running ...\n\r", __func__);
}
#endif
tst-09.h
#ifndef TST_09_H
#define TST_09_H
#include <library.h>
#undef FUNCTION_2 // .....................................................
#define FUNCTION_2 true // THIS IS WHERE I'M TRYING TO OVERRIDE THE LIB DEFAULTS
#endif // TST_09_H
tst-09.cpp:
#include "tst-09.h"
int main(void) {
Class object;
#if FUNCTION_1
object.Function_1();
#endif
#if FUNCTION_2
object.Function_2();
#endif
}
Take advantage of the capabilities of your linker. If you want to exclude unused or unnecessary code from you binary, one way to do that is to put each function in its own source module. (Some compiler packages support Function Level Linking, where the linker can remove unreferenced functions.)
Trying to use macros the way you show in your question would need them to be defined on the command line (and the library rebuilt with any change).
My question is quite straight forward. I just intended to know that is the #define directive in C++ controllable over the different project files? Elaborately, I have a header file and a cpp file for one project. The codes of the files are as follows:
MyHeader.h
#ifndef __MY_HEADER_H__
#include <cstring>
using namespace std;
#ifdef _HEADER_EXPORT_
#define HEADER_API __declspec(dllexport)
#else
#define HEADER_API __declspec(dllimport)
#endif
#ifdef __cplusplus
extern "C" {
#endif
class HEADER_API MyHeader
{
public:
MyHeader();
~MyHeader();
#ifdef _HEADER_DISPLAY_
void __cdecl ParseHeader();
#elif defined (_HEADER_RETURN_)
string __cdecl ParseHeader();
#endif
};
#ifdef __cplusplus
}
#endif
#define __MY_HEADER_H__
#endif
MyHeader.cpp
#ifndef __MY_HEADER_H__
#include "MyHeader.h"
#endif
MyHeader::MyHeader() { }
MyHeader::~MyHeader() { }
#ifdef __cplusplus
extern "C" {
#endif
#ifdef _HEADER_DISPLAY_
HEADER_API void __cdecl MyHeader::ParseHeader()
{
fputs(string("Displaying...").c_str(), stdout);
}
#elif defined (_HEADER_RETURN_)
HEADER_API string __cdecl MyHeader::ParseHeader()
{
string retVal("Returning...");
return retVal;
}
#endif
#ifdef __cplusplus
}
#endif
In another project HeaderImpl.cpp file has been implemented with the following code.
HeaderImpl.cpp
#include "stdafx.h"
#define _HEADER_DISPLAY_ // To display the message
// #define _HEADER_RETURN_ // To return the message as string
#include "MyHeader.h"
int main(int argc, char* argv[])
{
MyHeader header;
MyHeader.ParseHeader(); // To display the message or to return the string
return 0;
}
Now, I wanted to know that how can I use the #define directive in my HeaderImpl.cpp file to control the ParseHeader method for MyHeader.cpp file? As it has been noted that MyHeader.h file doing exactly what I need for; i.e. controlling the ParseHeader method upon declaring the #define directive, accordingly.
You can't. Each C++ source file is compiled independently, and settings in one cannot affect another. You'll have to do this on project level.
One way to do that would be to set up different project (and solution) configurations for different values of this macro. Instead of just the usual Debug and Release, you could add Debug-Display, Debug-Return etc. You can then define the macros in the project settings for each configuration. This will make sure you link the correctly built version of your library.
As a side note, you're using illegal names in your code. A name which contains double underscores, or starts with an underscore followed by an uppercase letter, is reserved for the compiler & standard library. User code is not allowed to use such names for its own purposes.
You usually can provide #defines for all of your compilation units on the command line of the compiler. IIRC for Visual studio that would be something like /D_HEADER_DISPLAY_ or /D_HEADER_RETURN_
Your project must be using something like this already for the _HEADER_EXPORT_ define.
There is no way for a preprocessor definition in one translation unit to remotely affect a different translation unit.
Most, if not all, compilers accept them as parameters for the compilation, though (and the flag is usually -D, or /D for VC++).
In Visual Studio, you can set project-wide preprocessor definitions in the project settings, under
Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions
I would like to know if this is the correct way to port a C library to C++; for this example I wrote a 2 line C header with a function and a typedef managing a pointer.
lib.h
#ifndef LIB_H
#define LIB_H
#include <math.h>
double foo(double a) { return (log(a)); }
typedef double (*PtoFoo)(double);
#endif // LIB_H
lib.hpp
#ifndef LIB_HPP
#define LIB_HPP
namespace lib {
extern "C" {
#include "lib.h"
}
}
#endif // LIB_HPP
and a little test in C++11
#include <iostream>
#include "lib.hpp"
#include <functional>
int main() {
// call to the function
std::cout << lib::foo(42354.343) << "\n";
// trying the pointer to function type
lib::PtoFoo ptr = lib::foo;
std::function<double(double)> f(ptr);
std::cout << f(342.4) << "\n";
return (0);
}
right now my attention is focused on pointers, function pointers and functions, but in general I would like to know if this is the correct way to port standard C code to C++ and using the new c++ interface with namespaces without possible backfires .
Yes, that is the correct way to do it.
Alternatively, you can use the __cplusplus preprocessor token to define the C++ interface in the same header file:
#ifdef __cplusplus
namespace lib {
extern "C" {
#endif
typedef ...
#ifdef __cplusplus
}
}
#endif
The advantage of this approach is that only a single header file is required.
As I commented, C++ is designed to be compatible with C, so just wrapping your C library headers with the appropriate extern "C" { and } /* end extern "C"*/; is enough.
However, you may want to design a C++ friendly interface to your library. This requires some thoughts, and some code (most of it in C++ specific header files). For instance, you may want to provide interfaces using C++ object, overloading, operator, and template facilities.
I can't help more, but look for examples at: libonion and its C++ bindings, GTKmm which is a large C++ binding to GTK (and companion libraries like Glib...), the C++ class interface to gmplib, or even the newest C++11 standard thread library (i.e. std::thread etc, etc...) which could be viewed as a clever C++ wrapping of pthreads ....
I believe that each library could have its own C++ wrapping... How to design that is up to you... (depends a lot on the wrapped library, your available time, and your fluency with C++...).
I need to maintain a project that supports running on Linux and Windows. Some codes using preprocessor directives like this are fine.
#ifdef _WIN32 // _WIN32 is defined by Windows 32 compilers
#include <windows.h>
#else
#include <unistd.h>
#endif
But some are the actual implementation, which I would like to prevent using preprocessor directives.
void Foo()
{
#ifdef _WIN32 // _WIN32 is defined by Windows 32 compilers
code for windows
#else
code for Linux
#endif
some common code...
#ifdef _WIN32 // _WIN32 is defined by Windows 32 compilers
code for windows again
#else
code for Linux again
#endif
}
So things get convoluted and harder to maintain. Is there any better way?
The traditional way is to "hide" all the code that is specific to any OS in wrapper functions - you can either do that in complete functions that do a higher level functionality - e.g. have a function that returns all directory entries based on a given path as input, or implement the individual base-functions, e.g. start_read_directory(path), read_dir_entry(), end_read_directory() - that's just an example functionality, the same principle(s) can be applied on almost any system specific functionality. Wrap it enough, and you wouldn't be able to tell what you are programming for.
In essence, you are doing it wrong if you have a lot of #ifdef in the code itself.
Handle the OS specifics from the build system, not the code. For instance, have two versions of Foo.cpp: one that gets compiled on Linux and another on Windows. Ideally, the header file will be common and all function signatures identical.
You can use a simplified version of the factory pattern.
Have a common interface
class MyClass
{
public:
virtual void Foo() = 0;
};
And for each platform you create a specific class
#import <windows.h>
class MyClassWindows : MyClass
{
public:
virtual void Foo() { /* Do something */ }
};
#import <linux.h>
class MyClassLinux : MyClass
{
public:
virtual void Foo() { /* Do something */ }
};
Then when you need this class, you use your factory:
class MyClassFactory
{
public:
static MyClass* create()
{
#if defined _WIN32
return new MyClassWindows();
#elif defined _LINUX
return new MyClassLinux();
#endif
}
}
There a many variants of this methods, including defining the MyClassFactory::create method in the .cpp of each platform-specific class and only compiling the .cpp for the appropriate platform. This avoids all preprocessing directives, the switching is made by choosing the correct implementation file.
A common pattern would be to provide system independent header files, and platform-specific implementation files.
Nothing platform specific in the header:
class Foo
{
...
};
In two different implementation files, foo_linux.cpp
Foo::Foo() { .. linux code }
foo_windows.cpp
Foo::Foo() { .. windows code }
and maybe platform independent implementation in foo.cpp
void Foo::plat_independent_function()
Your platform builds then link in foo.cpp and foo_platform.cpp
A possibility for the implementation of this is to use the PIMPL idiom, where your class just publishes the "interface" and declares a meaningless pointer to an implementation class (in its dark, hidden and private corner) and the build system takes care of pulling in the correct platform dependent code for the class containing the implementation of your PIMPL.