问题标签 [ldc]

我最近在我的 Mac 上通过 hombrew 安装了 ldc，并且正在测试从 D wiki将代码作为脚本运行时，我注意到使用 ldmd2 编译我的程序之后也不会运行我的程序。那么有什么区别，因为这与运行 ldc2 的行为相同。

这是我的程序

编辑：网站声明“对于小型项目，只需一步即可编译和运行。大多数（如果不是全部）编译器包都包含一个名为 rdmd/gdmd/ldmd 或类似的工具。出于教学目的，我们将其称为 rdmd 。” 我从中得到的是它取决于您使用的编译器，但在 ldc 的情况下，我应该使用 ldmd。

我正在尝试与 C++ 和 D 进行互操作。我今天发现的事情真的让我心烦意乱：我的程序中没有正确传递对象。

最好举个例子。

我有一个 C++ 库，我将其编译为目标文件和 D 程序，我将其与我的库链接并运行。

他们来了：

和 D 程序：

我用这些命令编译它们：

但是当我运行时./main，我得到了奇怪的结果：

让我认为对象被错误传递的只是一个简单的实验。首先，我运行了我的程序几次，这就是我所看到的：

所以第一个数字似乎是一个指向内存块的指针。我的第六感加上汇编知识让我认为它是指向this变量的指针。

现在，为了确认我的数据仍然存在并且这些数字不仅仅是随机数字，我在我的课程中添加了另外两个字段Color：

C++ 库：

和 D 程序：

输出是：

我尝试使用 DMD 和 LDC 编译器编译我的程序，但两者都为我提供了完全相同的行为。

UPD：更有趣并且（可能）指出问题所在的事实是，在 C++ lib 中创建的对象正在 D 和 C++ 之间正确传递。

为了证明这一点，我在Color课堂上创建了“工厂方法”：

然后，在 D 程序中：

所以c对象来自 C++ 库，被传递给printer对象，在 C++ 库中创建，这种传输是在 D 程序中进行的。

结果出乎意料地正确：

我是否缺少 C++ 和 D 互操作的概念，或者这是两个 D 编译器中的错误（怀疑）？

我对学习 D 很感兴趣。但是我对 DMD 有点反感，因为它不是完全开源的。这就是我考虑使用 LDC 的原因，但我不确定它的状态。在 debian 包中它说：

我知道 Debian 存储库有时可能有点古老，但 1.0.0 似乎是最新的 LDC 版本。

我打算经常使用用 C 编写的库。哪个编译器更适合这个目的？最不发达国家还是 DMD？我知道以前有人问过这个问题，但是我发现的所有问题都比较老，我想知道目前的状态。

主文件

当我编译并执行它时，它工作得很好

但是当我尝试

我尝试在c

和

这是工作！

为什么在我编译宽度 ldc 时在 Dlang 中不起作用？？？

I am writing an application in D. It's compiled with the ldc2 compiler, using dub configuration (target type: executable). The compiled program creates a console window, which I do not need since the application uses a GUI framework. I need a way to prevent creating the console window.

The only other example I know with similar behaviour is when compiling C/C++ programs with mingw64-gcc, which has an -mwindows flag. I do not know anything similar for D programs. Neither dub configuration nor ldc compiler flags seem to do what I want. Does anyone know what to do? Even another compiler could work, if it at least does what I want.

When the application is opened from CMD or PowerShell, no additional console is opened. The problem only occurs when I start the application from the Windows GUI.

dub.json:

compile command:

Solution:

add linker flags as follows in dub.json

this removes the console poping up at program start, if the program is not run from another console. it also enables the usual d main (void main() etc.), NO need for the winmain entry point. (that can be used if you simply leave the entry flag out)

此代码与合同：

使用 dmd (v2.076.0-dirty) 编译和运行，但不是 ldc (0.17.1) 或 gdc (5.4.0 20160609)。

最不发达国家 说：

和 gdc 说：

编辑：使用“body”而不是“do”进行编译，根据 ldc 的答案成功。gdc 得到一个新的编译错误：

请注意，目前合同编程的 dlang.org 文档没有提到body，虽然可能已弃用，但仍然有效，并且对于早于 [未知版本] 的 dmd 编译器版本和任何 gdc 或 ldc 版本是必需的在版本 [未知版本] 之前使用 dmd 前端。

我使用 D 的 Deimos openssl 标头将 D 链接到 OpenSsl，并使用 ldc 1.8.0 编译器尝试加密字符串作为小测试。加密的字节数组与我的预期不一致。当我运行程序并加密字符串并随后解密时，我会取回原始字符串。但是中间的加密字节数组在代码的执行之间并不一致。

所以我的问题是，这是预期的行为吗，OpenSsl 中的 AES 是否在内容中添加了某种盐，因此更难攻击，或者这是我的错误？

我正在使用最新的 LDC2 测试版，当使用 -I 运行编译器时（在 中查找导入），它会因未解决的外部问题而失败。这些是我的命令。

但是，当我明确告诉编译器setup.d依赖于common.d.

我在带有 VS Build Tools 2017 的 Windows 上使用 DMD v2.082.0 上的 LDC2 版本 1.12.0-beta2。感谢任何解决方案或更正。

注意：这些编译器命令将由其他代码生成，因此使用显式文件名是不可行的。

一段时间以来，我一直在使用带有 Digital Mars D 编译器和 LLVM Clang 编译器的 CodeBlocks，没有任何问题。现在我需要使用 LDC D 编译器并且在链接器调用方面遇到问题。

我得到以下输出：

编译步骤似乎工作正常，但将 ldc2.exe 指定为链接器显然失败了。

同样，在 CodeBlocks 的链接器规范中使用ldmd2.exeand会产生类似的错误。lld-link.exe

有什么建议么？

我正在调试一个用 D 编写的相当简单的程序，它似乎有随机机会接收到 SEGV 信号。经过进一步检查，我观察到使用不同的编译器和构建模式会产生不同的结果。

我的测试结果：

• DMD 调试 = 99% 的时间都可以工作
• DMD 释放 = 50/50
• LDC 调试 = 50/50
• 最不发达国家释放 = 50/50

因为默认编译器 (DMD) 中的二进制文件仅在我无法真正调试时崩溃，并且由于缺少调试符号，发布模式也无济于事。在调试模式下使用 LDC 构建二进制文件让我使用 gdb 和 valgrind 对其进行测试，以总结我收集到的内容。

来自valgrind的相关信息，

Gdb 没有给我更多的见解，3 个堆栈帧，其中只有第 0 个感兴趣，第 0 帧的回溯显示文件 video.d 第 46 行，这是一个中断语句，那么现在呢？

这是产生段错误的代码片段

那么有没有人知道是什么导致了这种行为，或者更准确地说是如何解决它？