- 主题:上午面试了一个小孩，问了一个问题是不是太过分了 (转载)
现在的小孩对这些历史问题是没啥认知的。你是过来人，他们不是，也不care。
现在的编译器有一万种方法帮你规避这类问题。而且现在本来就不应该再用这种写法了，都是直接stdint.h走起的。
对于老人问这种问题没啥区分度，对于新人问这种问题他只会表达不屑。
所以更多的还是你的问题，问这种问题多少有点倚老卖老的感觉。技术上要会与时俱进，文化上要学会用他们的黑话跟他们交流。当你跟他们没有任何代沟，能用他们熟悉的语言在他们熟悉的知识领域展现实力的时候，你才会真正赢得他们内心的尊重，否则你在他们眼里只是一个用着落后知识，即将落伍淘汰的中年人而已。
至于楼上那些说转c#的，人家是嵌入式环境。一般rom1~2mb，ram 256kb这样的，所以还是省省吧。
【 在 anotherstone 的大作中提到: 】
: 发信人: feiy (null), 信区: NewExpress
: 标 题: 上午面试了一个小孩，问了一个问题是不是太过分了
: 发信站: 水木社区 (Thu Jul 8 18:25:14 2021), 站内
: ...................
--
修改:lvsoft FROM 180.111.50.*
FROM 180.111.50.*
所以说你只是个会抬杠的外行。
python也是可以跑在这样的mcu里面的，so what？
【 在 xiaoju 的大作中提到: 】
: 既然是老人都知道java是给嵌入式系统研发的吧，C#自然也可以做
:
https://www.nanoframework.net/: Can run on resource-constrained devices with as low as 256kB of flash and 64kB of RAM.
: ...................
--
FROM 180.111.50.*
整个讨论除了你，就没人说java好吧。
你喜欢自说自话麻烦另开贴，别来污染别人。
【 在 xiaoju 的大作中提到: 】
: 你这是常识错误，python从来不是给嵌入式设计的语言，而java是嫌嵌入式市场太小才进入通用领域
:
--
FROM 180.111.50.*
整个趋势的走向是上层工具会越来越多的摆平所有底层问题，需要精通底层的人会越来越少。
但，世界是复杂的，发展是曲折的。
做个比喻，我们现在用一个工具，是不会从挖矿这种细节开始的。
但也不排除极少数极端场合，你要知道这玩意是用几几年从哪里哪个矿挖出来的材料制造的。
现在IT行业也在经历类似的发展过程。我的观点是现在对底层有深刻理解当然是有价值的，
但新人就不一定鼓励还这么做了，除非有特殊的天赋。
【 在 mystar1984 的大作中提到: 】
: 首先认同你说的这些才能显出真章来。
: 探讨下，以后这些问题会不会都被上层工具直接给摆平了，现在费劲的理解这些还真正意义有多大？
:
--
FROM 180.111.50.*
现在的小孩这种现象很普遍的。
比这个离谱的多了。
【 在 easebless 的大作中提到: 】
: 面试遇到不会的题 就气鼓鼓 这种来了你可难带了....
--
FROM 180.111.50.*
这个问题扯起来就复杂了。比如我用别人的代码都会先过下，把隐藏问题处理下，把雷排一排。
但这样会有额外投入，还会有额外风险，比如引入新的问题等等。
大部分人的做法是管它这么多呢，按照原来的代码要求的系统，环境，版本，什么都不改精确的搭一个的跑。
这也是docker普及之后大家越来越喜欢的玩法。然后多代码之间的联动协作又开始成为了新的麻烦。
这是一个理念的问题。对于你的这个场景，我倾向与先彻底消除char这种用法。
如果有多个库都自己定义的u8 s8，需要处理多个库之间的数据传输和格式转换，那就把所有的库都处理成统一的格式。
总之，我的基本思路是基础牢靠很重要，与其靠个人实力在危楼里面搭鹏，不如费点力气把地基打好，按规矩建设。
这笔额外的投资是必须要支付的代价，尤其是如果这个东西是构成你公司核心竞争力的产品的话更应该如此。
至于什么工程是意外使用之类的，这种事情有一万种解决办法。比如编译器给warning的代码不让push到repo就结束了。
【 在 feiy 的大作中提到: 】
: 所以，规范公司和有经验的工程师都会拒绝用单独一个char(plain char)，都会定义一套u8 s8 u16 s16之类的使用。
: 但现实里，却是有不少工程师有时会无意该地夹杂用char来表示他所本意的signed 8-bit，而且认为没错无问题。有时候，编译器会给warning，有时候未必会给warning(前面有人说char a=-5；很易被warning，但若-5是隐性计算出来的呢，编译器本身也并不总是很聪明)，有很多人面对一大堆warning也习惯于忽略无视。
: 不是说一定会出问题bug，做多开发经验有了，一般基本都会遇到。
: ...................
--
修改:lvsoft FROM 180.111.50.*
FROM 180.111.50.*
我不是说不需要知道这些问题，这个问题本身也不是啥大问题。如果你觉得这个人整体素质满意，即使他不知道这个问题也只是说一句话就能教会的事情。在我看来这种问题没必要问，问了没任何收益，反倒是降低了你在面试者眼中的身份。
我的意思是，比起现状，更重要的是往什么方向走，乘着什么波浪走。现在的IT技术已经不再是以前的手工业时代了，要拥抱新的技术，拥抱成系统成体系规范化的做法。至于你说的各种现状和形形色色的bug问题，你要想清楚这是你现在要解决的首要矛盾还是次要问题。如果这是你的首要矛盾，那你就应该招一个精通处理这方面经验的老中医角色的人。那你的jd和面试完全可以照着这个来，怎么细节怎么搞都可以。如果你招的是一个开发，那他就是来给你生产东西，而不是给你解决疑难杂症的。他能在你的生产体系里面达标能高效产出即可，同时你的生产体系也不能是小作坊形式，而是为了能高效产出合格的代码而配套的一整套体系。哪怕现状是小作坊，至少方向上也要向工业化标准看齐，所以我才强调这个方向的问题才是核心。
老一辈工程师都经历过这种用各种奇淫技巧在螺蛳壳里做道场的时代，但现在时代变了，你可以说作为过来人这是一种宝贵的经历和精神，但这种精神现在是不值得提倡的。比如cube这种东西肯定是未来，我不喜欢只是现在这个时间点，目前cube做的太烂了，还不够好，还没达到我心目中的标准。但这种东西给予一定的时间是肯定会改良到合格的状态的。但你不能因为这种东西现状不好所以就抱着以前的方法不放。一定要逼着自己升级自己的思路和技术，要跟现在的时代同步。
【 在 feiy 的大作中提到: 】
: 彻底消除char这种用法，是对的。公司代码审查规则必须有这一条。
: 我只是基于我协助解决过的许多朋友的形形色色的bug经验，知道很多公司很多工程师并不在乎使用char，这是个现实。
: 这是现实，如果你知道这里的问题风险，不是更好或必要吗？
: ...................
--
FROM 180.111.50.*
这个8位 16位 32位搬运指令混合只是实现过程中的优化带来的。所以他说的是memcpy的“最朴素”实现。
32位系统当然会尽可能发挥位宽优势，一般是用8位对齐，之后32位批量搬运，最后再8位解决剩下的。这个实现并不影响逻辑上的定义。
【 在 feiy 的大作中提到: 】
: 你可找台电脑或单片机板，自己分析对应的汇编看看。你可能看到8位 I6位 32位搬运指令混合都有。当然，若不支持8位，自然也不会有8位的。
: 单片机板上可尝试用这个函数读写flash或eeprom试试。说不清楚，自己试了就明白了。
: 若还想讨论，建议转去embedded版吧，那里更相关。否则，影响这里非底层开发的版友阅读。
: ...................
--
FROM 180.111.50.*
嗯...毕竟1byte=8bit也是经过一些时间的发展才稳定下来的...
【 在 adoal 的大作中提到: 】
: 我只知道上古平台有char可能是6或者7 bit的，还真不知道有>8的
:
--
FROM 180.111.50.*
其实我想说，换rust吧～
【 在 adoal 的大作中提到: 】
: 比较窄的领域里甚至可能没有太多动力像通用领域那样去
: 充分吸收编程语言理论和软工的一些实践去改进开发工具
:
--
FROM 180.111.50.*