0
点赞
收藏
分享

微信扫一扫

d的符浮.

伢赞 2022-05-23 阅读 50


显式​​源和目标​​​类型的​​强制转换​​来解决

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个常量​​​的​​三元表达式​​​,则它可能​​需要​​更新.



举报

相关推荐

0 条评论