为什么默认情况下我的Delphi 7中的可分配类型常量被禁用?

时间:2013-05-30 18:15:13

标签: delphi delphi-7

而不是我能够只输入

const clicks : Integer = 1;

我必须输入

{$J+}
const clicks : Integer = 1; 
{$J-}

我认为在编译器选项菜单中选中此框后会更容易..但我想确保它不会在长时间的错误中伤害我...并且想知道为什么它会被禁用(未经检查) ?

我感谢你们的任何帮助,谢谢你们。

3 个答案:

答案 0 :(得分:4)

默认情况下,自Delphi 2发布以来,禁用它们,IIRC。在Delphi 1的对话框中提供了实际选项,我似乎回忆起在下一版本中默认情况下已从启用更改为禁用的大惊小怪。虽然已经很长一段时间了,所以当默认情况发生逆转时,我可能会被一个人关掉;它可能是D3。可分配的常量是旧Turbo Pascal天的结转,并且可以替代缺少实际的静态变量类型。它们被更好的解决方案取代,这是一个初始化(全局)变量(见Declaring Variables)。

如果您确实需要使用可写常量,则应仅在必要的最小(最有限)范围内执行此操作,而不是更改全局设置。常数应该尽可能(常量)。使用可写常量的典型原因是当您需要某个范围内的局部变量(例如过程,函数或单元)需要在调用之间保持其值时,通常有更好的方法。一些选项是对象字段(成员变量)或有限范围初始化变量(在受限区域中可见的变量,例如在单元的implementation部分内,并初始化为起始值)。

可分配常量意味着可以在运行时更改该值,并且实际上很少有用。真常量就是 - 常数 - 不应该被允许改变。

类型常数也是如此;应该有使用它们的实际需要,除非你存储一个常量数组,记录,指针或过程类型,否则很少有这些声明:

const
  TIntLookupArray: array[0..1] of Integer = (1, 2);
  TErrorMsgs: array[0..1] of string = ('Invalid input', 'Invalid sequence');

您是否有理由首先使用类型常量?如果您只是使用

,则不会出现此问题
const clicks = 1;

让编译器决定正确的类型。如果你想确保它是Integer的大小,只需使用类似

的类型转换
const clicks = Integer(1); 

有关详细信息,请参阅Delphi documentation docwiki

答案 1 :(得分:3)

我猜它已被禁用,因为“可分配的常量”本身就是一个信号。您可以通过

替换您的代码
var
  clicks : Integer = 1;

“可分配常量”稍微有用的唯一情况是模拟静态局部C变量。

答案 2 :(得分:3)

默认情况下,可分配的类型常量选项已被禁用,只要我记得。在Delphi 7之前的许多版本中默认禁用它。

语言功能设计不佳,因此,在我看来,不应该使用。这对代码的读者来说很困惑。修改常量的想法非常奇怪。可分配类型常量的用例是具有静态(即全局)存储持续时间的本地范围变量。

如果语言设计得当,那么本地范围的变量就会有静态存储持续时间。但是这个设计存在致命的缺陷,因为由于const关键字的重载,你无法用Delphi语言轻松区分可分配的类型常量和实常数。

理智的设计会引入语法来声明带有静态存储的变量,并将它们与常量区分开来。但是设计师选择了编译器选项。或许,在Turbo Pascal中,当所有类型的常量都可以赋值时。同样,如果没有语言语法支持,const关键字的重载就是站不住脚的。

保留编译器选项以实现向后兼容性。您不应使用可分配的类型常量。同样,只要我记得,任何不错的编码标准都禁止使用可分配的类型常量。

我的建议:

  1. 在全局级别禁用可分配的类型常量。
  2. 切勿在代码中使用$ J +。
  3. 现代Delphi中具有静态存储持续时间的本地范围变量中最接近的构造是严格的私有类变量。它们在Delphi 7中不可用,因此您唯一的选择是全局变量,这是一个令人遗憾的事态。