将Delphi 2009/2010字符串文字转换为PAnsiChar [英] Casting Delphi 2009/2010 string literals to PAnsiChar

查看:86
本文介绍了将Delphi 2009/2010字符串文字转换为PAnsiChar的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以问题是,是否可以将Delphi 2009/2010中的字符串文字(或const字符串)直接转换为PAnsiChar,还是需要先将其附加转换为AnsiString才能起作用?

So the question is whether or not string literals (or const strings) in Delphi 2009/2010 can be directly cast as PAnsiChar's or do they need an additional cast to AnsiString first for this to work?

背景是我在具有C接口的旧版DLL中调用函数,该C接口具有一些需要C样式char指针的函数.过去(在Delphi 2009之前),类似以下代码的代码就像一个魅力(C DLL函数的参数是LPCSTR):

The background is that I am calling functions in a legacy DLL with a C interface that has some functions that require C-style char pointers. In the past (before Delphi 2009) code like the following worked like a charm (where the param to the C DLL function is a LPCSTR):

两个:

LegacyFunction(PChar('Fred'));

const
  FRED = 'Fred';
...
LegacyFunction(PChar(FRED));

因此,在更改为Delphi 2009(现在是2010年)时,我将调用更改为:

So in changing to Delphi 2009 (and now in 2010), I changed the call to this:

LegacyFunction(PAnsiChar('Fred'));

const
  FRED = 'Fred';
...
LegacyFunction(PAnsiChar(FRED));

这似乎可行,并且我从函数调用中获得了正确的结果.但是,应用程序中确实存在一定的不稳定性,这似乎主要是通过调用旧版函数的代码第二次或第三次发生的(在迁移到2009年版本的IDE之前不存在).通过调查,我意识到Delphi 2009/2010中的本机字符串文字(和const字符串)是Unicode字符串,因此我的演员表可能有误.这里和其他地方的示例似乎表明此调用应如下所示:

This seems to work and I get the correct results from the function call. However there is some definite instability in the app that seems to be occurring mostly the second or third time through the code that calls the legacy functions (that was not present before the move to the 2009 version of the IDE). In investigating this, I realized that the native string literal (and const string) in Delphi 2009/2010 is a Unicode string so my cast was possibly in error. Examples here and elsewhere seem to indicate this call should look more like this:

LegacyFunction(PAnsiChar(AnsiString('Fred')))

让我感到困惑的是,使用第二个示例中的上述代码,将字符串文字直接转换为PAnsiChar不会生成任何编译器警告.如果我不是字符串文字,而是强制转换为字符串var,则会收到可疑的强制转换警告(字符串将被篡改).这(以及字符串在DLL中可用的事实)使我相信编译器正在做一些魔术,以正确地将字符串文字解释为预期的字符串类型.这是正在发生的事情还是真的有必要进行双重强制转换(首先转换为AnsiString,然后转换为PAnsiChar),而我的代码中缺少它是难以追踪不稳定的原因吗?同样的答案也适用于const字符串吗?

What confuses me is that with the code above in the second examples, casting the string literal directly to a PAnsiChar does not generate any compiler warnings. If instead of a string literal, I was casting a string var, I would get a suspicious cast warning (and the string would be mangled). This (and the fact that the string is usable in the DLL) leads me to believe the compiler is doing some magic to correctly interpret the string literal as the intended string type. Is this what is happening or is the double cast (first to AnsiString, then to PAnsiChar) really necessary and the lack of it in my code the reason for the hard to track down instability? And does the same answer hold true for const strings as well?

推荐答案

默认情况下,常量(包括字符串文字)是未键入的,并且编译器会将其调整为适合您在其中使用它们的上下文中可用的任何格式.由于您的字符串文字中没有非ANSI字符,因此在这种情况下,编译器将字符串生成为ANSI而不是Unicode不会有任何麻烦.

Constants, including string literals, are untyped by default, and the compiler will fit them into whatever format works in the context you're using them in. As long as there are no non-ANSI characters in your string literal, the compiler won't have any trouble generating the string as ANSI instead of Unicode in this situation.

这篇关于将Delphi 2009/2010字符串文字转换为PAnsiChar的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆