标头的类型可见性 共享在本机客户端和托管客户端之间共享的标头文件
我有一个包含在本机 cpp 文件和托管 cpp 文件（使用 /clr 编译）中的头文件。它仅包含本机类型，但我想指定本机类型在程序集外部可见
（请参阅 http://msdn.microsoft.com/en- us/library/4dffacbw(VS.80).aspx)。
本质上，我想要：
public class NativeClass // The public makes this visible outside the assembly.
{
};
如果我从本机 cpp 中包含此代码，则会收到以下错误：
error C3381: 'NativeClass' : assembly access specifiers are only available in code compiled with a /clr option
尝试的解决方案：
我当前正在使用预处理器解决方案，该解决方案会导致在使用托管客户端进行编译时出现 public，但它不会出现对于本机客户端：
#ifdef __cplusplus_cli
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public public
#else
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
#endif
CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
class NativeClass
{
};
问题：
这是实现此目的的适当方法，还是有更好的方法？
I have a header file that is included by both a native cpp file and a managed cpp file(compiled with /clr). It includes only native types, but I want to specify that the native types are visible outside the assembly
(see http://msdn.microsoft.com/en-us/library/4dffacbw(VS.80).aspx).
Essentially, I want:
public class NativeClass // The public makes this visible outside the assembly.
{
};
If I include this code from a native cpp, I get the following error:
error C3381: 'NativeClass' : assembly access specifiers are only available in code compiled with a /clr option
Attempted solution:
I'm currently using a preprocessor solution that causes the public to appear when compiling with the managed client, but it does not appear for the native client:
#ifdef __cplusplus_cli
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public public
#else
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
#endif
CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
class NativeClass
{
};
Question:
Is this the appropriate way to achieve this, or is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否尝试过链接到的 MSDN 页面上列出的
make_publicpragma？否则，您的解决方案是完全有效的。我很想知道为什么要从 CLR 程序集中导出本机类型。
Have you tried the
make_publicpragma listed on the MSDN page you linked to?Otherwise, the solution you have is perfectly valid. I'm curious to know why you want to export native types from a CLR assembly though.