What is the difference when I use
vcpkg install <any package>:x64-windows
x64-windows-static
x64-windows-static-md?
x64-windows:
VCPKG_LIBRARY_LINKAGE = dynamic
VCPKG_CRT_LINKAGE = dynamic
x64-windows-static:
VCPKG_LIBRARY_LINKAGE = static
VCPKG_CRT_LINKAGE = static
x64-windows-static-md:
VCPKG_LIBRARY_LINKAGE = static
VCPKG_CRT_LINKAGE = dynamic
VCPKG_LIBRARY_LINKAGE Determines if a library/port is build as a static or dynamic library
VCPKG_CRT_LINKAGE Determines if the static (/MT(d)) or dynamic (/MD(d)) CRT (C runtime) is used
Related
I have two custom protobuf libraries. One is dynamic, other is static.
Static lib has a message:
message DataType
{
int number = 1;
string name_1 = 2;
string name_2 = 3;
string name_3 = 4;
}
// The dynamic lib has a message:
message MyMessage
{
DataType type = 1;
}
I build dynamic proto lib with linking static proto lib to it.
Then I build exe application to which I link dynamic proto lib.
The problem is that when I set one of name_1, name_2 or name_3, they all have this value. I think all these strings have same buffer.
If to convert dynamic lib to static, then problem disappears.
Could anyone explain me what is wrong with it? Thank you.
If a field is not set then it should return empty string. Please check the documentation here.
If you are using version 2 you can query whether the field is set by has_name_x().
By the way there are several ways to set a value:
The simplest creates a copy: void set_name_x(const string& value)
In case of C++11 you can move a string value: void set_name_x(string&& value)
You can pass pointer: void set_allocated_name_x(string* value)
You can get the pointer to the stored string: string* mutable_name_x()
I would advice to get familiar with protobuf and let it manage memory and use set_name_x. If it is not sufficient you can optimize your code with manual memory management.
I am trying to build a memoryHandler which allows me to create and manage my shared memory, e.g. I want to create a managed_memory_object only once.
When I construct an segment I want to actually store the return pointer as a member variable in my class, so I can access it without using the find function from boost.
Is there any way to achieve something like this or do I always have to map my shared memory and find my segment with the find function?
thank you for you help
Manu
Example Class:
MemHandler::MemHandler(const char* name_p)
{
size_m = 1024;
name_m = name_p;
shm_m{open_or_create, name_m, size_m};
sharedVar_m = shm_m.construct<int>("sharedValue")(4711);
}
int* MemHandler::getSharedVar()
{
return sharedVar_m;
}
void MemHandler::setSharedVar(int value)
{
sharedVar_m = shm_m.construct<int>("sharedValue")(value);
}
In C++, is it possible to load a shared library at execution time?
I want the user to choose which shared library to be loaded at runtime, without recompiling the whole program.
dlopen() is a solution for C, but my program is written is C++/Qt, and the symbol to extract are Qt-style class, is there a more "c++" way to do that.
You can do it in Qt using QLibrary in two ways. The following example calls a function from a shared library at runtime in two different ways:
#include <QLibrary>
#include <QDebug>
class Dynamic_library
{
public:
Dynamic_library();
virtual int sum( int len, int * data );
};
typedef Dynamic_library * (*get_object_func)();
typedef int (*call_sum_func)(int len , int * data);
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QLibrary library( "./dynamic_library" );
library.load();
if( !library.isLoaded() )
{
qDebug() << "Cannot load library.";
return 0;
}
call_sum_func call_sum = (call_sum_func)library.resolve( "call_sum" );
if( call_sum )
{
//Dynamic_library * obj=get_object();
int * a=new int[3];
a[0]=2;
a[1]=3;
a[2]=4;
qDebug() << "sum of 2+3+4' = " << call_sum( 3, a ) <<"\n";
delete [] a;
}
get_object_func get_object = (get_object_func)library.resolve( "get_object" );
if( get_object )
{
Dynamic_library * obj=get_object();
int * a=new int[3];
a[0]=7;
a[1]=8;
a[2]=9;
qDebug() << "sum of 7+8+9' = " << obj->sum(3, a );
delete [] a;
}
return a.exec();
}
The code for the shared library is as follows:
class DYNAMIC_LIBRARYSHARED_EXPORT Dynamic_library
{
public:
Dynamic_library();
virtual int sum( int len, int * data );
};
extern "C" Q_DECL_EXPORT Dynamic_library * get_object()
{
return new Dynamic_library();
}
extern "C" Q_DECL_EXPORT int call_sum(int len, int * data)
{
return Dynamic_library().sum(len,data);
}
Dynamic_library::Dynamic_library()
{
}
int Dynamic_library::sum( int len, int *data )
{
int sum = 0;
for(int i=0; i<len; ++i )
sum += data[i];
return sum;
}
If the target library itself, or at least its specification, is under your control, then you shouldn't be using QLibrary - use the Qt plugin system instead. It doesn't require the call-via-pointer gymnastics otherwise needed.
If you insist on using a dlopen-like mechanism, there is nothing C-specific about QLibrary. The obvious limitation is that the library that you're trying to open must have been compiled with a C++ compiler that's ABI-compatible to the one you use to compile your own code. On Windows that really means using the same MSVC version.
Apart from that, you'll have to look up the mangled version of the symbol. Once you've done that, you can call the symbol using a function/method pointer that matches it. This won't work on constructors/destructors, by design. If you wish to create new instances of objects, you'll need a static factory method provided by the library.
If the library doesn't provide factory methods, you can implement a shim library that links to the target library by a generic name and does provide factory methods. You'll still need to call individual methods by function/method pointers.
Create a temporary folder.
Copy the shim library to the temporary folder.
Copy the target library renamed to the generic name, into the temporary folder.
Save the value of LD_LIBRARY_PATH environment variable.
Prepend the temporary folder to LD_LIBRARY_PATH.
Open/load the library.
Restore the saved value of LD_LIBRARY_PATH.
Of course, you must have the header file for whatever interface the library exposes. It can't be, generally, reconstructed given just a dynamic library file - primarily because the mangled symbols don't have full structural information for the used types. For example, even if you can find a constructor for a given class, you won't know how big is the class instance (its sizeof).
Yes it's possible to do what you're describing on most operating systems, but how you do it is dependent on the system and regardless of the system it's definitely a bit more work on your end to make it happen.
The general steps are:
load the library
for each symbol you're interested in within the library, locate it and store to a variable for later use. (This can be done as-needed, rather than right away.)
For example, in pseudo-code (read: this won't compile!) on a *nix type system, lets assume your shared library has this in it:
// I'm declaring this _extern "C"_ to avoid name mangling, making it easier to
// specify a symbol name for dlsym() later
extern "C" int myFunction() {
return 10;
}
Assume this is in a library called libmyFunction.so. Your main application could, for example:
{
void *handle = dlopen("libmyFunction.so", <flags>);
if (!handle) return; // error: cannot locate the library!
int (*func)() = (int (*)())dlsym(handle, "myFunction");
if (!func) return; // error: cannot locate the symbol!
printf("The function returns: %d\n", func());
}
If you need to do this on Windows, the concept is the same but the function calls are different.
I know that C++ cannot create variables at runtime. Everything has to be declared when it is compiled.
My question is, if I have, let's say, 10 included header files with simple variable names, can I reference them dynamically, by the header file name or something like that.
For example, if I had two header files, one called "myVars1.h" with variable "myVars1name" and another called "myVars2.h" with a variable "myVars2name" could I do something like
int fileNum = 1;
string name = ["myVars" + fileNum + "name]; //i wish this worked...
Is this along the same lines as creating variables at runtime (and therefore illegal)?
Thanks
Assuming these variables are declared in header files, and defined somewhere else as global variables, you may get what you want by using dlsym(). Basically C/C++ cannot define variables at runtime, but it can load them at run time.
Precondition: these variables must be built into shared library, e.g. mylib.so
....
int fileNum = 1;
string name = ["myVars" + fileNum + "name]; //i wish this worked...
void *handle = dlopen("$PATH/mylib.so", RTLD_LAZY);
void *varPtr = dlsym(handle, name); // Your wish comes true here...
//cast varPtr to its target type.
....
I think you should use Namespaces
I am creating a small C++ wrapper shared library around a Fortran 95 library. Since the Fortran symbols contain . in the symbol name, I have to use dlsym to load the Fortran function into a C++ function pointer.
Currently, I have a bunch of global function pointers in header files:
// test.h
extern void (*f)(int* arg);
and I populate them in the corresponding C++ file:
// test.cc
void (*f))(int* = reinterpret_cast<void(*)(int*>(dlsym(RTLD_DEFAULT, "real_f.symbol_name_");
Questions:
If I do it this way, when are these pointers populated?
Can I assume them to be loaded in my executable that loads this library?
In particular, can I use these functions in statically created objects in my executable or other libraries? Or does this suffer from the static initalization order fiasco?
If the above way is not correct, what is the most elegant way of populating these pointers such that they can be used in static objects in executables and other libraries?
I am using the Sun Studio compiler on Solaris, if that makes a difference, but I would also be interested in a solution for GCC on Linux.
Where does the line
f = reinterpret_cast<void(*)(int*)>(dlsym(RTLD_DEFAULT, "real_f.symbol_name_"));
occur in test.cc? The pointer will be initialized when the line is
executed (which of course depends on when the function which contains it
is called). Or did you mean to write
void (*f)(int* ) = reinterpret_cast<void(*)(int*>(dlsym(RTLD_DEFAULT, "real_f.symbol_name_");
? In this case, the pointer will be initialized during static
initialization. Which means that you still have order of initialization
issues if you try to use the pointers in the constructor of a static
object.
The classical solution for this would be to use some sort of singleton:
struct LibraryPointers
{
void (*f)(int* );
// ...
static LibraryPointers const& instance()
private:
LibraryPointers();
};
LibraryPointers const&
LibraryPointers::instance()
{
static LibraryPointers theOneAndOnly;
return theOneAndOnly;
}
LibraryPointers::LibraryPointers()
: f( reinterpret_cast<void(*)(int*)>(dlsym(RTLD_DEFAULT, "real_f.symbol_name_")) )
, // initialization of other pointers...
{
}
Then wrap the library in a C++ class which uses this structure to get
the addresses of the pointers.
And one last remark: the reinterpret_cast you are trying to do isn't
legal, at least not formally. (I think that both Sun CC and g++ will
accept it, however.) According to Posix, the correct way to get a
pointer to function from dlsym would be:
void (*f)(int* );
*reinterpret_cast<void**>(&f) = dlsym(...);
This doesn't lend itself to initializations, however.