精神可嘉，送你一波铜币，聊表敬意。
期待 有 lemon lang 的详细 tutorial 以及 feature

@geelaw

所以不用 goto 就没有这种连声明个指针 都是 ill-formed 的破事儿
就跟不要写 i+++i++ 这种破代码是一样的道理。

@geelaw 还是再补充一句。

即使是 C++ 里面，去掉大括号去掉 else
TypeD d; 这一句也并不一定就会编译错误。

视乎你的 TypeD 怎么写。

所以这种一不留神就会踩坑的代码，我真的不觉得直观。

我保留我的意见。

@geelaw

是否错误，取决于你用哪个编译器，以及 flag。
而且这里也涉及到了 C 和 C++ 的差异，如果有 C 和 C++ 混用的话，效果更显著。

算了，反正你觉得 开心就好。

@geelaw 是我复制错代码了，给的是已经修改过后的。

本来应该是把 else 以及后面的 {} 都去掉，至少让你品尝一下 cross initialization 的。

@geelaw 能介绍一下你是怎么测的吗？

@geelaw 很直观？ 我给你找个实际例子，这段代码会泄露资源，资源类为 TypeA TypeB TypeC


```
std::shared_ptr<TypeA> a(new TypeA);
{
bool error = doA(a);
if (error)
goto out_a;
else
{
std::shared_ptr<TypeB> b(new TypeB);

TypeD d;

error = doB(b, &d);
if (error)
goto out_b;
else
{
std::shared_ptr<TypeC> c(new TypeC);

error = doABC(a, b, c);
if (error)
goto out_c;
else
goto out;
}
}
}

out_c:
undo C

out_b:
undo B:

out_a:
undo A

out:
return ret;

```

确实很直观吧。

要不你建议，试试用 try ？ XD XD

try + goto 死得更快

@geelaw

https://stackoverflow.com/questions/3179936/goto-out-of-a-block-do-destructors-get-called

C++ 语义上保证 goto 语句， 对作用域内的对象生命周期是安全的。

然而编译器的行为和直观上的感觉可能会不同；
而 break continue 之类的就不会有这样的担忧，因为它们一次只会跳出一个 block。

用递归有栈溢出的风险，这是事实。
但这不是使用 goto 的理由。
没有什么使用 goto 的场合是找不到不用 goto 的替代方式的。而使用 goto，在很多原生语言例如 c++里，因为打破了符号作用域，会产生意外的效果。如果不是这些原生语言，那么 goto 比起正常使用其替代方式，带来的运行效率提升基本等于无。

所以我不知道楼主有什么好感到得意的，我看到的只有无知。

@ryd994

行行行，你说得都对，DHT 不好，KAD 不好，性能挑战不了 CDN ……

那你用一个 CDN 给你家网络加个速啊……

我没你厉害，但我不用给任何机构任何组织付钱，
我都可以在地球任意角落的网络找到浮动 IP 的自家 KAD 上的机器。

这就够了。

你吹得再牛的现状，对你没有任何利益的增加，你继续使劲吹吧。

@ryd994

请继续你的演讲。请问 BGP 如何代表或者关联现实距离？
IP 地址与运营商有什么关系？

又要去中心化，又要有中心控制，感觉题主很难办啊。

DHT 查询一轮能绕地球一圈，这只是最差情况。

现实情况是，在有超级节点的情况下，能在 5-6 次查询内查出任何一台 KAD 网络的节点的 IP 地址。
而不需要任何 类似于 ICANN 这样的中心化机构。

几年前咱们讨论过 BT 网络，你给我说蜜罐或者吸血，说不行。
几年下来，你对去中心化网络的理解还是这个水平，

我很担忧啊，如何完成党和国家交给你的任务哇。

@ryd994 原来你是这个意思。有道理，但我觉得这锅 KAD 背不起，墙有一定责任，毕竟也是一种网关嘛。

先不说别的，你能不能举个例子，哪一个网络地址系统能告诉你现实世界的距离？
IP 吗？域名系统吗？

再告诉我，如果有这样的网络地址系统，如何能够缩短现实世界的距离？

@hjc4869 我粗略看了一下 AVX 的指令集的一些指令功能，感觉做不出来，不知道怎么做，想不到居然真有实现了的，长见识了。有没有关键字提供一下？

@msg7086

用 AVX 处理字符编码其实我还真没做过，甚至都没见过。

仔细想想的话，对于变长编码类型来说，什么 AVX 乃至并行算法其实都是不可行的。
因为这些编码格式本来就只考虑流式处理，而不是并行处理。

字符流和用于快速地把数据 copy 到显存、什么的图像编码流，并不一样。

不过即使是图像领域，不也还有 JPEG、PNG 等等的压缩格式嘛，显然其数据单元就不是内存对齐的。

离题了。

我最初的出发点只是想说，设计用于传输和存储的编码格式，是不需要考虑寄存器大小的。

让我意外的是，显然有很多人并不知道什么场合才需要考虑内存对齐。

@dishonest 那要不我回你一句“多事”“没有帮助”，然后再和你说，你敢把我拉黑就是小孩子气？

“最烦那些劝我大度的人，你知道我经历了什么，你死不死”——郭德纲

走好不送，同拉黑，最烦那些没什么料还劝人大度的。

@wwqgtxx

“转码还真的可以不使用通用寄存器，用 AVX 之类的直接就可以大量直接转”

你是没看到我说什么，还是没看懂什么叫通用寄存器？还是不知道 AVX 指令使用的是非通用寄存器？

gcc\llvm 要处理的数据都是要放到通用寄存器里面的，当然转成内存对齐的咯。