显式源和目标类型的强制转换来解决
auto cast_from(From,To,Real)(Real a)
{
static if (is (From==Real))
return cast(To) a;
else
pragma(msg, "错误类型");
}
void main()
{
import std.range, std.stdio;
short a=1;
int b=cast_from!(short,int)(a);
bool c=1;
// int d=cast_from!(short,int)(a);
// 编译时错误
writeln("测试: ", b);
}D规则给C的规则加了些约束,来防止隐式转换导致精度丢失.
表明,为了性能,你肯定希望按单独代码单元对待UTF-8.
我痛苦发现,Unicode联盟使得无兆字节库就不可能做"正确"的Unicode.
D字符唯一问题是自动解码,讽刺的是,它符合你的建议,按Unicode代码点而不是代码单元对待一切.
这是个好主意,但它根本行不通.
gcc和ldc2编译器可转换?:至后者,而不是手写.
在D中,char是UTF-8,而ASCII是UTF-8的子集.
你不愿意写:
a += (b < c);我愿意.而且,正如我之前所说,GPU喜欢该编码风格,SIMD代码也如此,加密代码也如此.
判断发生什么的唯一方法是转储生成的汇编程序.编写可在各种SIMD指令集间移植的矢量代码时尤其麻烦.它根本无法扩展.
manu编写矢量代码.
因此,D方法是不同的.可在D中编写向量代码.如果不编译到目标指令集,不会用仿真代替它.它发出错误信号.使用户可轻松地使用版本控制来调整表达式,来匹配目标平台向量能力.
总之,如果想要输出流中的特定指令插件,系统编程语言必须可表达所需插件.而不能依赖未记录和不一致的编译器转换.
import std.stdio;
import std.string;
import std.utf;
char char_tolower_bright (char c)
{
if ('A' <= c && c <= 'Z')
c = c | 0x20;
return c;
}
string tolower_bright (string s)
{
string t;
foreach (c; s.byCodeUnit)
t ~= c.char_tolower_bright;
return t;
}
void process_strings (string s)
{
writefln!"input : %s" (s);
auto t = s.tolower_bright;
writefln!"bright : %s" (t);
auto u = s.toLower;
writefln!"toLower (std.utf): %s" (u);
}
void main ()
{
process_strings ("A a");
process_strings ("A a");
}除非使用配置文件引导优化编译,否则编译器一切都是盲目的.如分配寄存器和溢出位置.
如,现在和过去的AMD处理器已经在更多更小的执行单元方面模拟了更广泛的SIMD.
我同意,尽管即使在X86上,D也与有趣的指令严重不同步.除非使用内联asm(或Guillaume的内在函数库),否则不能用它们.
对非x86世界,ARM有NEON,但未来是SVE2,这些是变宽矢量指令.这可适合D_SIMD范式,但需要大小只有下限的类型.
RISC-V向量ISA类似发展.
如果优化器无法看穿具2个常量的三元表达式,则它可能需要更新.










