首页   注册   登录
 FrankHB 最近的时间轴更新
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
发现这些分析之中都少了一个原因……就是用户到屏幕的距离很可能比以前更近了。
现在分辨率普遍提升的情况下用户有更多的选择,不少用户就习惯缩小文字以显示更多的内容(或者干脆默认使用高分辨率以适配更高的设备 PPI ),但当某些时候局部太小又不清晰时,多数人一般不会去用放大镜之类的,而是凑上前看……久了就凑得近了。
明视距离短到一定程度,比较宽的屏幕没法一眼看清,还要麻烦颈椎,当然拉仇恨。
至于换行……主要是自动折行普遍没法照顾布局逼的。有条件当然最好避免莫名其妙的硬回车,但编辑结果的兼容性就呵呵了。
@yuikns 按我看到的一般的常见的用法,serializing / deserializing 指数据结构的内部表示和(至少)允许串行访问的外部存储的表示(尤其是直接对应外存中的可持久化格式,如文件映像)之间的转换; marshalling / unmarshalling 则强调系统内处理的以既定方式访问的数据(通常就是语言运行时支持的一等对象(first-class object) )和系统外的表示形式(不限制格式是否公开稳定,不强调持久化,具体支持和语言之间互操作的要求有关)的交互。两者外延不同但有交集,条件允许时可以共用一套实现。

划分 I/O 操作的基准要看什么是系统“内部”。I/O 是指保证对外部有不可忽略的影响的操作。否则,找不到一个外延去限定什么才能算 I/O,字面含义也说不通。
有些操作作为 I/O 是没疑问的:产生可观察且无法保证消除的行为(比如说,总是需要消耗电力)的物理设备发生的通信是真实的 I/O。
除此之外,还可以假装认为存在其它类似的影响外部状态操作,以实现不可控的“外部”系统交互。例如通用操作系统的内核把设备驱动排除出这里的“内部”,统计的所谓 I/O 可以包括仅在虚拟设备上有意义的操作;为便于设备驱动实现和统计方式的原因,这种假定姑且是合理的。
但就不提供让用户显式指定如何处理的计算作用(computational effect) 大多数编程语言来讲,没有说得过去的理由这样装。特别是 C 和 C++ 对这种“外部”副作用已经专门用 volatile 区分了,再含糊地给库函数开洞只会导致不必要的劣化和库 API 设计的混淆。
96 天前
回复了 Pichai 创建的主题 程序员 国产 App 的吃相为什么这么难看?
@Takuron 没有 Root,都是弟弟。
过审有过审的流氓姿势。
@GeruzoniAnsasu

serialization 序列化
deserialization 反序列化
marshalling 列集
unmarshalling 散集

翻译不是问题,只是因为没多少人用所以才用原文。问题是原文意思就被普遍用错,而这个错误来自权威来源。
具体来说,I/O 是指系统内部和外部的交互。在一个系统内部交互的作用强行称为 I/O 会引发混乱。
这种误用的典型例子是,以抽象机语义指定行为的 ISO C++规定 I/O 操作(“库的 I/O 函数”)引发副作用——不管其实现是否改变了抽象机这个系统的状态。
这不科学。因为至少像 std::stringstream 这种( ISO C++所谓 Input/output library 里的)东西本来就不应该和系统外部交互,在这个定义下因为钦定副作用可能影响可观察行为而没法被优化成 no-op,即便实际可能什么都不用做。
再如,像格式转换之类的功能本来就该是 serialization/deserializaton,是应该能够证明不必要就该消除的东西。
真正的 I/O,是和设备交互的操作,操作的设备这种抽象机以外的接口。
这个意义下,C++的标准库 I/O 原则上设计就是错的,因为它违反了核心语言要求的抽象边界。让所谓标准 I/O 库函数比用户实现的 I/O 函数具有更加一等的地位也不可能是目的,何况在这里根本还没法直接优化。
这个问题从 C 就有,不过大概 stdio 隐藏了缓冲所以才没那么明显,以讹传讹惯了……
真要“一键”应该只能买给你 root 过的,按开机键……
现在新机出厂的大概都不行吧。
想知道粘包警察是何种文化输出……樱警察 /车万警察 /厄介警察?
另外倒是想出警把 serialization/deserialization 或者 mashalling/unmarshalling 和 I/O 混为一谈的……
99 天前
回复了 caowentao 创建的主题 程序员 怎么理解回调函数?
这么多楼跑题了那么多,也就半个说到点上的。
控制流(control flow) 在很多时候是个有害的概念,因为过度片面强调程序(源代码)反映的静态结构对程序运行状态的影响,反而给理解添乱。
摆脱这个刻板印象,最直接的方式是在判断程序如何运行的问题上,使用续延(continuation) 的概念代替。(当然,这个理解偏差问题更多毒害写静态语言编译器的,一般用户一时间理解不了也犯不着死磕。)但除非打算实现控制操作符(control operator) ,这里还不需要是一等(first-class) 的。
恐怕对大多数看不清“回调”意义何在的用户来讲,这里真正需要被理解的首先是一等函数(first-class function) 。如果把函数以一等对象(first-class object) 的方式使用——例如拿来当别的函数的参数或返回值,然后适时地允许调用之,自然地就用到了所谓的回调。关键是“不限制”当作参数或返回值以后获得的对象被当作其它函数同等方式地使用。
这个时候,刻意需要理解回调的概念是不必要的,因为只有比较残废的缺乏一等函数的语言中,才会显得要用其它特性来弥补这种一等函数基本功能的缺失的重要性。
——说白了,大部分情况需要强调回调的概念,是因为在用其它特性实现一等函数作为变通。
而如果已经这样自然地用上了回调函数,反而不会(不需要)拿它当一回事儿,这就像把一个不是函数的一等对象当作参数或者返回值一样自然。
至于所谓异步如何如何,什么什么模式如何如何,与其说是回调给你的功能,倒不如说是健全的“函数”本来就该能够实现的东西。只不过只有残废版的函数能用的下,你需要借助其它特性(比如“函数指针”)来变通罢了。
99 天前
回复了 kisshere 创建的主题 程序员 windows Gmail 客户端,求推荐
没一个省心的,迟早得自己撸个。
暂时 Outlook 凑数。(老实说,光是备份本地数据缓存就极其不爽了,之前还有回滚 Windows 版本,大概因为这货在 %APPDATA% 里的 junction 的关系,把数据滚没了的……)
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2018 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 00:13 · PVG 08:13 · LAX 17:13 · JFK 20:13
♥ Do have faith in what you're doing.