Coming from ATL(Active Template Library) there is a coclass an abstract base class and hence it is secure to tag the coclass with ATL_NO_VTABLE ( _declspec(novtable)). So you can use only the Microsoft C++ compiler to use the ATL classes. Has C++/winRT or WinRT/ABI such a CRTP-"feature" also for other C++ compilers ? And if, how does it work ?
__declspec(novtable) is an implementation detail, unrelated to the CRTP. It is handled in C++/WinRT like pretty much any other platform specific implementation in virtually any other C or C++ library: By use of preprocessor macros. You'll find the following in <base.h>:
#if defined(_MSC_VER)
...
#define WINRT_NOVTABLE __declspec(novtable)
...
#else
...
#define WINRT_NOVTABLE
...
#endif
The respective base types in namespace winrt::impl are appropriately tagged WINRT_NOVTABLE.
Related
The following is my scenario:
I have an executable along with multiple shared libraries(.dll or .so). Both the executable and the shared libraries(.dll or .so) uses a set of common libraries. Since they are common libraries I want to reduce the binary foot print of the shared libraries, in order to reduce the shared library's foot print I am exporting the contents of the common libraries from the executable and importing them in shared libraries(dll or .so).
Note: Though size of the foot print is not the only one among multiple reasons, for the time being we can stick with it being major reason.
Problem:
In the common libraries there are some inlined functions and some template classes. When I compile the executable and the shared libraries using performance optimization flags the inlined/ template classes are inlined both in executable and shared libraries. It will create problems if the inline definitions are modified and there are some shared libraries with different set of inline function definitions.
How to solve this problem ?
When I started thinking about this even the STL classes provided by the CRT are template classes. The similar problem exists even in their case. Have they solved this problem? What will happen if they modify the definition of std::vector ? Please help.
A class template is a mechanism for creating class. But these classed don't get instantiated until you define a particular instance of a class (with a template parameter.)
In your export control file.
#ifdef XXXX_BUILD
#define XXXX_EXPORT __declspec(dllexport)
#define XXXX_EXTERN
#else
#define XXXX_EXPORT __declspec(dllimport)
#define XXXX_EXTERN extern
#endif
where XXXX_BUILD is a symbol defined in your project.
To get your class exported.
XXXX_EXTERN template class XXXX_EXPORT YourClass<double>;
Where double is the type you want to instantiate the class with.
https://support.microsoft.com/en-us/help/168958/how-to-export-an-instantiation-of-a-standard-template-library-stl-clas
I feel that it is expected to be possible (to create a library with Rust that can be used from .NET and Objective-C) but after hours of googling I still have not clear picture of how to do so.
Does anyone have such experience (compiling Rust library to be used from Win32/Win64 .NET(P/Invoke), MacOSX, and iOS apps)?
A Rust library which is written with external usage in mind is indistinguishable in ABI from C library, so you can just use FFI tools natural for your language. For Objective-C, I believe, it is sufficient to write a header file which lists functions exposed by the library, and then link the library just as you would link some other C library.
To provide proper C interface, you would need to write extern functions which operate on C types. With some annotations these functions will be exposed as C functions callable by any external code which knows how to call C functions. It should work even if you compile your library as a shared object and then load it dynamically (I think you would need it to interoperate with .NET anyway).
For example, this is how an externally available function can be written:
#[repr(C)]
struct Foo {
x: c_int,
y: c_double
}
#[no_mangle]
unsafe extern fn frobnicate(foo: *const Foo) -> Foo {
Foo {
x: foo.x * 2,
y: foo.y / 2.0
}
}
#[no_mangle] disables name mangling, extern (equivalent to extern "C") defines calling convention, #[repr(C)] forces C field layout to the structure. When a crate containing this code is compiled into a library, frobnicate will be exposed as a function symbol, and some other program will be able to call it through corresponding FFI interface.
I think, these links will be helpful for you:
Foreign Function Interface
Writing Unsafe and Low-Level Code
Rust's Runtime - you will have to start a runtime manually if your Rust library uses some higher-level abstractions in std
I've written a wrapper for a C++ dll in C++/CLI. Inside the wrapper, I made some typedefs. Is there a way to export these names as .NET classes?
Background: the typedef'd classes are some templates. For these templates to work, you need a managed and a native parameter (this is part of the translation). This is impossible for the client of the wrapper to program / know. That's why he needs the different aliases for the used versions of the template.
I exchanged the typedefs with some new class definitions that derive from the template. This should work.
I do not have too much information but typedefing should work only on Clr types. Generic classes, maybe but template classes can not ne typedefed. Also among native types, only the ones that are common (the word "common" may not be correct here.) to .net i.e. double, int, char, Char* (not char*) etc.
This code works and introduces a "new" type to clr.
namespace example
{
#ifdef _WIN64
typedef sizeT UInt64
#else
typedef sizeT UInt32
#endif
}
Now you have size_t of .Net, whose size depends on platform.
I have an Objective C Class called Donald, I also have a C++ class called Donald in a static library that I would like to use in the same project. They both have a header file called Donald.h. Is there a way to do this?
You can include both header files by specifying a bit more of the path e.g.
#import "staticlibraryheaders/Donald.h"
#import "Donald.h"
However, you might find that the code won't compile since you are declaring two types both called Donald. If the compiler sees:
Donald* duck;
How does it know to type duck as a pointer to an instance of the C++ class or the Objective-C class? You might be able to fix that if the C++ class is in a C++ namespace. However, that hits the limit of my C++ knowledge.
I recently started writing a C++/CLI wrapper for a native c++ library. I'm now getting this compile warning
"warning LNK4249: directive '/CLRTHREADATTRIBUTE:STA' conflicts with command line; ignored"
My c++/cli wrapper is set up for MTA in the linker's command line arguments, but I have no idea what file or project is trying to give the STA directive.
I did enough reading to get worried about .NET forcing libraries to become multi-threaded. I've read that this mostly affects my application's use of COM, but I am not really sure if or where my DLL uses COM. I use the interop services to marshal string data and am using 'msclr\auto_gcroot.h' to point to managed classes from unmanaged ones. In the native c++ library that is being wrapped, I include the following headers:
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#include <afxmt.h>
#include "Winsock2.h."
#include <time.h>
Does anybody have any advice that could help me avoid painful experiences in the future, or should I just not worry about it?
So far so good. I haven't seen any real problems with this; I think it is just because MFC is a single threaded library, so it wants to compile that way. So, for my case, I think as long as I treat all MFC objects and such as not thread-safe I'll be okay.