- 主题:c++太垃圾
但是控制领域需要非gc语言保证实时性，所以像rust这种需要是有前途的
【 在 hgoldfish 的大作中提到: 】
:
: 那么你应该去用 java. 不是 c++ 更不是 c.
: --
: 灭绝人性啊
:
:
发自「今日水木 on HMA-AL00」
--
FROM 117.136.38.*
你这个也算是奇技淫巧，哈哈哈
【 在 hgoldfish 的大作中提到: 】
: 因为 char[0] 和 char* 不一样啊。
: 前者在申请内存的时候这样:
: struct example {
: ...................
--
FROM 42.3.19.*
也对啊。现在嵌入式领域用 rust 也是有人这么干。但 rust 的入门门槛比 c 高，所以暂时还不够流行，最明显的问题就是招不到人手。
c, c++ 有它的特定用途。保留这些奇技淫巧也有是必要的。
不要太绝对地说一门技术是好的还是坏的。
【 在 mrunmatched 的大作中提到: 】
: 但是控制领域需要非gc语言保证实时性，所以像rust这种需要是有前途的
: 发自「今日水木 on HMA-AL00」
--
FROM 124.72.109.*
有一说一，至少99%的人写c++都不会去用char[0]的
【 在 hgoldfish 的大作中提到: 】
那么你应该去用 java. 不是 c++ 更不是 c.
【 在 mrunmatched 的大作中提到: 】
: 为了这些根本不值得，内存错误会导致很多随机错误，需要浪费很多人力时间去测试，找bug。要是火箭汽车控制之类的，因为这种问题出bug，损失太大了
: 发自「今日水木 on HMA-AL00」
--
FROM 123.118.101.193
char[0]或者char[1]是很常见的技法，这是C带来的，C++继承了而已。
这是C/C++的“direct hardware mapping”这个语言特性决定的，bit fields、alignment、pack这几个feature也是。
【 在 HerSMTH 的大作中提到: 】
: 为啥定义char[0]数组啊？定义个char*指针不香？
:
:
--
FROM 222.131.205.*
感觉这些奇技淫巧还是应该放弃
用其它的方式一样可以实现目的，执行效率没差别，还有助于阅读，缺点只是多几行代码而已
【 在 z16166 的大作中提到: 】
: char[0]或者char[1]是很常见的技法，这是C带来的，C++继承了而已。
: 这是C/C++的“direct hardware mapping”这个语言特性决定的，bit fields、alignment、pack这几个feature也是。
--
FROM 103.135.248.*
数组越界的warning都不检查，到底是cpp垃圾还是coder垃圾？
零长数组是处理变长对象的利器，经历少不是lz的错，出来秀无知就不对了。
【 在 mrunmatched 的大作中提到: 】
:
: 明明编译都检查出数组越界了，愣是只报warning，还允许编译通过，是怎么想的？给黑客留后门？
: 不怪很多大公司呼吁用内存安全语言替换他，再不思进取，过几年就被淘汰了。
:
: 发自「今日水木 on HMA-AL00」
#发自zSMTH@桃花源v6
--
FROM 223.104.3.*
这两种区别老大了，一个本身就是地址，不占内存，一个还得占一个指针长度。
处理变长对象，堪用的还真的只能用零长数组。
不然你看看写tcp协议，到处是零长数组
我最近处理多边形，也不得不用它。
否则代码量凭空增加一倍。
【 在 HerSMTH 的大作中提到: 】
:
: 为啥定义char[0]数组啊？定义个char*指针不香？
:
: 【 在 hgoldfish 的大作中提到: 】
: : 这是一个 c 的技巧，定义 char[0] 数组。但实际长度另说。
#发自zSMTH@桃花源v6
--
FROM 223.104.3.*
嵌入式里边全是c写法，这种char0写法只会更多不会更少。
【 在 mrunmatched 的大作中提到: 】
:
: 为了这些根本不值得，内存错误会导致很多随机错误，需要浪费很多人力时间去测试，找bug。要是火箭汽车控制之类的，因为这种问题出bug，损失太大了
: 【 在 HerSMTH 的大作中提到: 】
: :
: : 估计有些人喜欢用奇技淫巧，强制的话，这帮人要不爽了
#发自zSMTH@桃花源v6
--
FROM 223.104.3.*
有些懂了，多谢赐教！
【 在 hyperLee 的大作中提到: 】
: 这两种区别老大了，一个本身就是地址，不占内存，一个还得占一个指针长度。
: 处理变长对象，堪用的还真的只能用零长数组。
: 不然你看看写tcp协议，到处是零长数组
: ...................
--
FROM 103.135.248.*