V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 20 页 / 共 92 页
回复总数  1831
1 ... 16  17  18  19  20  21  22  23  24  25 ... 92  
2022-04-15 08:00:48 +08:00
回复了 Chad0000 创建的主题 奇思妙想 对于个人数据软件,如何解决隐私和便利的矛盾?
取消服务端,或者说所有客户端都能作为服务端,类似 DVCS 。
允许部分同步,只关心每个客户端节点需要处理的数据(比如 PC 和手机上生产的数据不一样,处理的数据也经常不一样),并允许后台自动同步,以提升响应和节约同步开销。
是不是要求完全同步才能用,根本上得看用户本人有没有强迫症不能容忍不同步,不是你能一刀切的问题。
@rekulas 你还能分得出几 P ,已经够可控了……
2022-04-15 07:41:37 +08:00
回复了 Rrrrrr 创建的主题 奇思妙想 能实现一种可以联系到任何人的应用吗?
比如你是一个犯罪嫌疑人 A ,被警察 B 抓了,想要被害者 D 的刑事谅解书。于是 B 告诉你 D 的律师是 C ,要谈条件可以转达。
这样?
2022-04-09 17:45:51 +08:00
回复了 sola97 创建的主题 海外留学 想去日本读研,掏空父母积蓄划得来吗
@Richardhtw 有没有可能有那么个 GE:女方跟当地食草男跑了,然后 OP 顺势搞定个首都圈樱花妹?
当然,前提是有能力搞得定(
2022-04-09 12:19:47 +08:00
回复了 fengche361 创建的主题 macOS 愁人,官网下单的加配 MBP 被疫情困在上海了
@omL72EEc 其实国际接轨的话也就这样,比如跟东京比……
2022-04-09 12:09:31 +08:00
回复了 shawnwang340 创建的主题 程序员 Java 开发者面向对象编程?不不不,是面向 Spring 编程
用 Java 开发 Android 的已经灭绝了么……
2022-04-09 11:48:56 +08:00
回复了 villivateur 创建的主题 分享创造 DIY 了一个苏康码与行程码“双码合一”的健康码 APP
前几天发现这边支付宝倒是支持二码合一了,但是就没怎么推广。大部分都还是用微信。
可以考虑移除 git 的硬依赖。你提供的功能基本上各家 DVCS 都能支持或者都不支持(所以要自己实现),没有特别 git 的部分,甚至有背道而驰的( git 向来鼓吹的依赖 pr )。
毕竟支持 git 的服务不缺,DVCS 中立的服务从 Bitbucket 之后基本就凉了( OSDN 那坨没统一前端的就算了),你能把基本功能都支持上你就是市场上最靓的仔。
2022-04-09 11:36:31 +08:00
回复了 sola97 创建的主题 海外留学 想去日本读研,掏空父母积蓄划得来吗
就奇怪哪来那么自信凭你自己的决定想掏空就掏空了。
真那么容易,那么怕是马上就会被社会调教——容易掏的软柿子向来可是稀罕货。
顺便,负债么,正常操作就是掏银行之类。你觉得你耐掏的抗性更高么。
@bandian 这可不一定。Linux 的首要全局影响是极大地推广了 GNU GPL 。如果没有 Linux ,就凭 GNU Hurd 的难产劲儿,肯定不是 BSD 的对手。于是也不太可能出现成熟的 GPL+专有许可的商业模式,想闭源的直接就成专有软件了。GPL 基本就得靠 GCC 来扛把子。RMS 会继续鼓吹 free ,但是不会有人出来发明 open source ,因为 copyleft 不够流行所以没有划清界限和对抗的意义。苹果还是那个苹果;微软不会有理由 FUD ,但也不会向开源转进。某种意义更加割裂(专有软件仍然会是专有的),另一方面又天下大同(开源和自由的分歧不会被大多数人注意,直到又有人想造 LLVM )才对。
@chuanqirenwu 声明的类型通过初值符的类型推断,不保证相同。和在函数模板的参数列表里写不带&的参数类型规则相同,占位符不会被推断为引用类型,于是声明的 m2 不是引用类型的变量。如果要保留引用,可以 auto&或 auto&&之类。
http://www.eel.is/c++draft/dcl.spec.auto#dcl.type.auto.deduct-3
2022-04-08 20:24:40 +08:00
回复了 bmpidev2019 创建的主题 分享创造 介绍 Go/ Java /C/C++/ Swift 等编程语言是如何实现范型的
1.先把词输入对。
范型(paradigm)
泛型(generics)
2.讨论泛型,C 放进来是用来嘲讽用的么。
这还是因为现在 C 有_Generic ,够当作底线了(但是 OP 一点没提)。
手工复制和旧式 C 宏连当作范型的底线都不配,因为和类型系统完全没有交互。
(原文评论区说无关是因为预处理器原因,这是错的,因为 pp phase 也是语言规范钦定的一部分,不应作为是否算是泛型实现的准则。否则 multi-stage programming 之类的就尬了。)
3.不要参考什么强类型弱类型之流只会让概念更加含混的伪劣资料来源。
所谓的强类型对立的就是“无”类型或者单一类型(unityped)。
更原则性上的错误在于这根本不属于类型检查,而是确保存在能被检查的类型的前提。
cf.github.com/FrankHB/pl-docs/blob/master/zh-CN/typing-vs-typechecking.md
4.装箱本质上和类型系统无关。
把装箱的外延缩小为几种 manifest typing 的语言的应用实例是一个常见理解偏差。
(cf.stackoverflow.com/a/69991369
利用装箱实现泛型只是用了箱和被装的对象的非同一性;技术上,这里拿来装出来的是不是箱并不重要。
对象布局根本上需要通过 ABI 约定,箱不是描述 ABI 的抽象。
5.类型擦除和装箱无关。(为什么是 ed 不是 ing ?)
没有箱的类型擦除一样可以实现某种意义上的泛型。
6.vtable 不一定是虚“函数”表(就 Java 来说,一般叫虚方法表)。
虚表这里只是用来替代 RTTI ,跟装箱也无关。
7.同上,图中的字典传递跟装箱也无关。
而且跟虚表并列的应该是字典(虽然这个词太滥了),同样是用来实现某种 RTTI 替代品。
文章和目录里倒是正常了一点。
原文评论区有说 Type Erasure/Dictionary ,这个也不确切,更准确地,应该是+。两者都算不上是完整的实现技术。
但是前者是任意 manifest typing 意义上必要的,后者只是针对静态语言静态区分数据和所谓泛型函数的可选优化。
8.文章里说的 type parameter 暗示实现的说法是错的。
type parameter 本来就是 parameteric polymorphism 的核心,没 type parameter 的系统根本不会叫做泛型。
原文的评论区也指出了这一点。
要有区别,就是 typing 意义上的强度,例如类型系统是否允许支持所谓的 non-type parameter (根本地,形式上还是 type ,比如 dependent type )。
9.文章链接的《透过 Rust 探索系统的本原:泛型》里把泛型函数从参数化类型中独立出来的做法在概念上是错的。
泛型函数的区别无非是类型参数和→这个类型构造器的交互,所以是参数化类型的一部分。
如果类型系统允许一个值同时居留于不带有→和带有→的类型(如类型擦除可以把*→*这个 kind 擦回*),那么单独考虑泛型函数差不多完全就是实现细节。
当然,考虑到带有→的 STLC (λ→)是 lambda cube 往其它类型系统(典型地,System F(λ2))扩展的原点,基本上会涉及泛型函数的语言都不允许这样做,即便类型擦除有能力实现;所以这点很容易被一般的作者忽视掉。
@FrankHB 修正:返回非静态存储期的临时对象的引用。
和 @nightwitch 指出的来源一样,返回自动对象的引用是悬空引用。这里的自动对象是一个被声明的局部变量。
但是仔细看了下,OP 的代码中并不是这种情况。
问题出在 max(max(a, b), c)返回的是 const char*类型的右值,通过 temporary materialization conversion 初始化一个临时对象并初始化 T const&[T=const char*]类型的返回值,在 return 外临时对象被销毁,所以返回悬空引用。
注意这不涉及 C++意义上的变量。使用 g++时,中文警告[-Wreturn-local-addr]会把它叫做“临时变量”,这是技术上错的;而原文 returning reference to temporary 是对的,虽然过时( ISO C++17 前就直接叫 temporary ,不叫 temporary object )。
注意这里实际上用的是软链接过去的 Apple clang++,警告的选项不一样。
因为不是被声明变量,所以说 local (指的是作用域)也是技术上错的。
OP 的注释也是错的,悬空引用是=右边的部分;而被声明的变量 m2 就不是引用,因为用的是 auto 而不是 auto&。
能运行也是 UB 的一种。
但是应该强调,返回临时变量的引用不一定就 UB ,这里只有限定返回局部自动对象的引用时才是。否则,这会显著干扰一些问题的理解,例如:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
2022-04-08 18:16:50 +08:00
回复了 dangyuluo 创建的主题 C++ CPU 指令重排是 cache 同步太慢的表征么?
哪个标准说了单核了……
C 和 C++之类的单线程 sequence before 完全是严格按照抽象机语义体现“;”这样的语法构造的语义。
而 CPU 实际上不保证存在这种顺序。

尽管原则译码的指令流是(按程序序)顺序的(用 PC 或者 IP 之类的架构寄存器的值保存),发射和执行从来就不需要保证严格的顺序。
乱序执行在核心内部实现,单核自然也可以发生这种所谓的重排序。这时候完全不需要关心核之间通信的 MESI (虽然可以复用 MESI 这样的 uncore 协议,但除了凭空复杂以外没什么用)。
特别地,对现在的执行单元来说,它可见的是解码之后的结果即微指令构成的信号,而不需要是架构支持的 ISA 指令,后者甚至根本不保证是乱序程序的输入——有些指令根本不需要进入 CPU 的执行单元(如 Intel SnB 等的 xor zeroing ;尽管抽象上这仍然叫“执行”,因为指令被消费掉了,区分于不管输入死活的“运行”)。所谓重排的结果只是和这种微程序尽量相同的以 ISA 指令重新实现的描述。
根本上,重排也就是为了叙述方便,指出和指令流基准的默认序(程序序)不同的部分而已。(算上投机执行,任一分支路径跳转也能算基准之内。)然而你没理解清楚乱序的来源,那么这种方式就是无益的。
@huang119412 你有动机和稀泥我可以理解,但居然还好意思说历史?能别在自己一窍不通的领域里那么颠倒黑白不。

Java 诞生的时候优秀在哪?一个面向嵌入式设备的原型从来就没真正成功过( JavaME ?算了 8 ),转“企业级”应用开始也没多成功( EJB 之类的黑历史),反而在 Web 服务器失之东隅收之桑榆,这算历史的玩笑就罢了,什么时候算是 Java 光荣了?
“优秀”的语言有脸在 20 世纪 90 年代设计出尽是一等(first-class)残废拼凑的特性,然后隔了几十年才被迫加入超过半个世纪前就成熟了的 lambda ( untyped 的都快一个世纪了)?

还语法糖多,你真懂什么叫语法(syntax)嘛?

要黑 C#也黑点子上,起码黑点 semantics 上比如 async/await 这种弱鸡抽象不堪大用,连 Web 前端都知道( e.g. blog.logrocket.com/async-await-is-the-wrong-abstraction ),结果还 dssq 甚至污染到 C 艹了。
你上道点整个 one-shot continuation 会死?
哦,你 Go 的 goroutine 更加弱鸡,Java 根本就没有……散了散了。

真要我暴论钦点,好意思在语言里直接提供什么 method 这种缺乏 formal significance 的破烂抽象,要么是 DSL ,就是垃圾。(我是不嫌地图炮不够大的。)
1 ... 16  17  18  19  20  21  22  23  24  25 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5224 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 03:50 · PVG 11:50 · LAX 19:50 · JFK 22:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.