转换 c++项目到 clr 安全项目

发布于 2024-09-15 08:49:13 字数 160 浏览 7 评论 0原文

我需要将一个非常大的 C++ 项目转换为 clr 安全项目。当前的 C++ 项目有很多来自 C++ 的东西,如模板、泛型、指针、存储/流、ole api、zlib 压缩 api、内联等。在哪里可以找到这种类型转换的详细文档?能推荐一些好书可以参考吗?如果你们中有人做过这样的转换,我可以向您提供一些分析吗?

I need to work on converting a very huge c++ project to clr safe. The current c++ project has a lot of stuff from c++ like templates, generics, pointers, storage/stream, ole apis, zlib compression apis, inlines etc. Where can I find the datiled document for this type of conversion? Can you suggest some good book to refer to? If anyone of you have done such conversion, can I get some analysis from you?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

烧了回忆取暖 2024-09-22 08:49:13

我将直接引用标题为“如何:迁移到 /clr:safe

Visual C++ 可以使用 /clr:safe 生成可验证组件,这会导致编译器为每个不可验证代码构造生成错误”

的 MSDN 库文章 。以下问题会产生可验证性错误:

  • 本机类型。即使不使用本机类、结构、指针或数组的声明,也会阻止编译
  • 全局变量
  • 对任何非托管库的函数调用,包括公共语言运行时函数调用
  • 。 不能包含用于向下转换的 static_cast 运算符 static_cast 运算符可用于在基本类型之间进行转换,但对于向下转换,必须使用 safe_cast 或 C 风格转换(作为 safe_cast 实现)。
  • 函数 函数不能包含 reinterpret_cast 运算符(或任何 C 风格的强制转换等效项)。
  • 可验证函数不能对 Interior_ptr 执行算术运算。它只能对其进行赋值和取消引用。
  • 可验证函数只能抛出或捕获指向引用类型的指针。值类型在抛出之前必须装箱。
  • 可验证函数只能调用可验证函数(不允许调用公共语言运行时,包括 AtEntry/AtExit,因此不允许使用全局构造函数)。
  • 可验证的类不能使用 Explicit。
  • 如果构建 EXE,主函数不能声明任何参数,因此必须使用 GetCommandLineArgs 来检索命令行参数。
  • 对虚拟函数进行非虚拟调用。

另外,以下关键字不能在可验证的代码中使用:

  • unmanaged 和 pack pragmas
  • bare 以及align __declspec 修饰符
  • __asm
  • __based
  • __try 和 __ except

我认为这会让您忙碌一段时间。没有什么魔杖可以将原生 C++ 转换为可验证的代码。你确定这值得投资吗?

I'll just cough up the MSDN Library article titled "How to: Migrate to /clr:safe

Visual C++ can generate verifiable components with using /clr:safe, which causes the compiler to generate errors for each non-verifiable code construct.

The following issues generate verifiability errors:

  • Native types. Even if it isn't used, the declaration of native classes, structures, pointers, or arrays will prevent compilation.
  • Global variables
  • Function calls into any unmanaged library, including common language runtime function calls
  • A verifiable function cannot contain a static_cast Operator for down-casting. The static_cast operator can be used for casting between primitive types, but for down-casting, safe_cast or a C-Style cast (which is implemented as a safe_cast) must be used.
  • A verifiable function cannot contain a reinterpret_cast operator (or any C-style cast equivalent).
  • A verifiable function cannot perform arithmetic on an interior_ptr. It may only assign to it and dereference it.
  • A verifiable function can only throw or catch pointers to reference types, so value types must be boxed before throwing.
  • A verifiable function can only call verifiable functions (such that calls to the common language runtime are not allowed, include AtEntry/AtExit, and so global constructors are disallowed).
  • A verifiable class cannot use Explicit.
  • If building an EXE, a main function cannot declare any parameters, so GetCommandLineArgs must be used to retrieve command-line arguments.
  • Making a non-virtual call to a virtual function.

Also, the following keywords cannot be used in verifiable code:

  • unmanaged and pack pragmas
  • naked and align __declspec modifiers
  • __asm
  • __based
  • __try and __except

I reckon that will keep you busy for a while. There is no magic wand to wave to turn native C++ into verifiable code. Are you sure this is worth the investment?

才能让你更想念 2024-09-22 08:49:13

绝大多数本机 C++ 是完全有效的 C++/CLI,包括模板、内联等,但 CLR STL 与 BCL 相比相当慢。此外,原生 C++ 没有泛型,只有模板。

C++/CLI 编译的实际情况是检查开关并推送编译,并等待它抛出错误。

The vast majority of native C++ is entirely valid C++/CLI, including templates, inlines, etc, except the CLR STL is rather slow compared to the BCL. Also, native C++ doesn't have generics, only templates.

The reality of compiling as C++/CLI is to check the switch and push compile, and wait for it to throw errors.

巴黎夜雨 2024-09-22 08:49:13

将本机 C++ 重写为安全 C++/CLI 将生成语法上不同但语义上与 C# 相同的代码。既然如此,为什么不直接用C#重写呢?

如果您想避免本质上完全重写,请考虑以下替代方案:

  • P/Invoke。不幸的是,我不知道这是否会隔离安全代码和不安全代码。即使它可以执行隔离,您也需要将现有的 C++ 代码包装到类似 C 的过程 API 中,以便 P/Invoke 可以使用它。从好的方面来说,除非您的 API 过于繁琐,否则您可以保持(大部分)本机性能。
  • 将 C++ 包装到进程外 COM 服务器中,并使用 COM Interop 从托管代码中使用它。这样,您的托管代码就可以完全免受 C++ 端可能发生的任何损坏,并且可以保持“安全”。缺点是进程外封送会导致性能下降,并且正确实现 COM 需要花费大量的实现工作。

Rewriting native C++ into safe C++/CLI will result in a code that is syntactically different, but semantically same as C#. If that is the case, why not rewrite directly in C#?

If you want to avoid what is essentially a complete rewrite, consider the following alternatives:

  • P/Invoke. Unfortunately, I'm unfamiliar whether this would isolate safe from unsafe code. Even if it can perform the isolation, you'll need to wrap your existing C++ code into procedural, C-like API, so it can be consumed by P/Invoke. On a plus side, unless your API is excessively chatty, you get to keep (most of) your native performance.
  • Wrapping your C++ into out-of-process COM server and using COM Interop to consume it from the manged code. This way, your managed code is completely protected from any corruption that might happen at C++ end and can remain "safe". The downside is a performance hit that you'll get for out-of-process marshaling and the implementation effort you'll need to expend to correctly implement the COM.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文