V2EX › GeruzoniAnsasu 的所有回复 › 第 54 页 / 共 148 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 50 51 52 53 54 55 56 57 58 59 ... 148

❮

❯

2022-04-16 23:31:12 +08:00

回复了 rv54ntjwfm3ug8 创建的主题 › 信息安全 › 有可能禁用 iOS 每 3 天左右强制要求输入一次密码的功能吗？（！请！先！看！完！帖！子！内！容！再！回！复！）

/t/834415
/t/837270

----

大部分人都会看完内容，但他们仅仅想对内容的一小部分发表看法而已

建议下次 h1 加粗写「仅限对本句观点发表评论」

----

没有 ios 设备，现在 ios 不能用字符组合的复杂密码了？

2022-04-16 21:49:46 +08:00

回复了 justou 创建的主题 › C++ › 请教一个 C++模板问题 (≥C++17)

@lujunliang 模板只有在用到的时候才会实例化，实例化前被剔除掉的话根本不会进入语法检查阶段。 trait 类的所有成员最终只会留下 BaseType**推导结果** 的定义。在这个类里写一个 int a(){return "X";} 编译器都是不管的。所以只把声明留下来不要函数体也可以，反正最后编译器不会去检查这个函数的定义在哪里，只是用声明计算类型而已。

2022-04-16 12:23:33 +08:00

回复了 justou 创建的主题 › C++ › 请教一个 C++模板问题 (≥C++17)

https://godbolt.org/z/vq6hM4534

定义一个 trait 类，其中有一个类型成员 BaseType：
当 T::Base 存在时 using BaseType= T::base
当 T 继承自 SomeBase 时 using BaseType=SomeBase

另外介绍一下这个站：
https://cpppatterns.com/patterns/function-template-sfinae.html
https://cpppatterns.com/patterns/class-template-sfinae.html

我几乎每回重新写 trait 都要来查一下。。

2022-04-16 11:25:41 +08:00

回复了 znwindy 创建的主题 › 深圳 › 求推荐深圳租车平台

只用神州和 e 嗨，除了贵点啥毛病都没有。

两家都能手机自助开锁取还，e 嗨还有 etc ，app 里还车结算。

2022-04-15 23:57:33 +08:00

回复了 FreshOldMan 创建的主题 › 问与答 › 有没有和我一样的，都已经很久不主动记 API 了

我刚开始学写代码的时候能记住 10 多个 C 库函数和几十个 Windows API/MFC 类成员函数，参数不说记得很熟吧，有几个大概是些什么还是比较清楚的

后来呢，接触了 c++ stl / java （ android ）/ kotlin / python / golang / haskell ，写了单片机的工程、嵌入式的 linux kernel 和 bootloader 、golang 的 crud 、vue 的速成页面、unity 的小玩具 …………

别说什么 API 了，sql 语句我都得翻个文档出来参考。
更搞笑的是，我觉得 dash 还是比较好用的，但后来 dash 也用得越来越少了，还是直接浏览器 google 文档，因为连 dash 搜索我要打什么前缀都要搞不清了：

https://i.imgur.com/7CpSZnH.png

2022-04-15 02:41:40 +08:00

回复了 rv54ntjwfm3ug8 创建的主题 › JavaScript › 从多层嵌套的 object 中搜索配对的值然后进行操作的最佳实践是什么？

先建倒排索引呗还能咋的，反正只遍历一次

反正架构方案就要求了前端必须完整存储所有 data ，那我为了加速多建几种用于索引的数据结构谁都 blame 不了吧

2022-04-14 23:00:42 +08:00

回复了 chenliangngng 创建的主题 › 前端开发 › 请教大佬，把一段代码用函数式编程变得更加优雅

函数式的精髓在于「符号演算」，本质上是一些公式代换，所以是在处理复杂对象关系和约束时才比较好用，并不是说函数式就比过程式更优雅，先走出误区。

再说实例。
你展示的一个 getdetail 的过程：
1. 调接口
2. 验证拉取结果
3. 对参数进行「变换」
这个描述本身就非常过程化，有明确的分段步骤，并不存在关系约束的语义，所以用函数式写本来也不适合。

当然也不是不可以，我们换个描述：

1. setdetail 接受「 raw 数据的变换结果」，最终将结果闭包展开，暂时先不管它内部什么样
2. 「 raw 变换结果」可以写为将「变换」应用到「 raw 」上 ← 函数化
3. 「 raw 数据」可以看做将「请求提取子（包含验证子）」应用在「数据源」上←函数化
4. 「数据源」是一个「输入请求类型然后重封装为响应类型的 monad 」←函数化
5. 「请求类型」由「请求类型变换子」应用在「请求数据」上得到←函数化

你觉得这优雅吗，我觉得一点也不，还非常麻烦和抽象，每一个「变换子」（即函数）都得绞尽脑汁才写出来，这些步骤也不可能比过程描述要少。

像 map 和 filter 这样的函数已经是函数式最适用的最小场合了，提供一个输入数组和输出数组的约束函数，把这个约束应用在原数组上得到新数组。这不函数化吗，不够优雅吗？

2022-04-14 04:43:24 +08:00

回复了 Features 创建的主题 › 程序员 › 发现 photoshop 做九图好简单啊

以防后面的人一脸懵逼点进来又一脸懵逼点出去，放个搜索结果：
https://www.jianshu.com/p/122240596c99

2022-04-14 04:41:04 +08:00

回复了 Features 创建的主题 › 程序员 › 发现 photoshop 做九图好简单啊

woc 长见识了，今天才知道还有这种东西

称得上设计 hacking 了

2022-04-12 18:12:25 +08:00

回复了 lotusp 创建的主题 › 程序员 › 微服务架构盛行，微服务分分合合很常见，大家的微服务系统都是如何设计和演进的？

@devswork

当你 **产品的用户告诉你** 他们有两三个服务中心要冗余备份但统筹管理，你的产品满足不了需求的时候。

而不是「为了方便将来能卖给」有这种规模的用户而提前用上这样的架构

toC 的话，约等于，「用户没在微博上发网站怎么挂了」，就别用，用不上。

2022-04-12 18:03:19 +08:00

回复了 haoooooooo 创建的主题 › 职场话题 › 现在还能让第三方代缴社保不？

@PerFectTime 你好，个体户要房产证

2022-04-11 23:13:03 +08:00

回复了 yunshangdetianya 创建的主题 › Go 编程语言 › 请教各位 go 语言大佬一个问题

@yunshangdetianya

> 接口作用就是限制和约束类型

正相反。

静态类型语言的变量，类型是「唯一的」。你可能一下 get 不到有多唯一，我举个自己初学 oop 时对我帮助很大的例子

- 你的程序有两个窗口
- 窗口 A 叫 A ，B 叫<嘎>
- 你给窗口 A 声明了一个类型 type WindowA struct{ Title: A }
- 窗口 B 的类型 type WindowB struct{ Title: <嘎> }

现在你想判断鼠标点击了哪个窗口：

func findWhichClicked(x,y int) (T){}

问题来了：应该返回什么类型？返回 A ，那么点到 B 这个函数就给不出数据了，反之亦然。
那……返回他们的公共类型？

type WindowA{Window; Title }
type WindowB{Window; Title }// AB 都来自 Window
func findWhich(x,y int) (w Window){}

但还是有问题：我想获得点到的窗口的标题：

w := findWhich()
w.Title() // ?

做不到！
我永远只能获得 Window 的标题，不能获得 WindowA 或者 WindowB 的标题。

「这事简直跟我是男人了就不是人了一样荒唐」！！

你可能会疑惑了，那用个公共变量呗

if inA() {w=windowA}
else if inB(){w=windowB} // 类型不匹配！，无法将 WindowA 类型的变量赋值给 Window 类型

------

接口：
type <有 title> interface {Title() }
func findWhichClicked(x,y int) <有 title> {} // windowA 和 windowB 都可以实现 <有 title>
w.Title() // w 可以是任何 <有 title>类型，运行期决定

如果 w 是 windowA ，那么调用 windowA 的实现，是 B 调用 B 的实现。

------

想想这句话：「我要使用一个变量，它可能代表不同的东西，但类型又得是唯一的」

2022-04-10 20:05:17 +08:00

回复了 Jat001 创建的主题 › 硬件 › 为什么现在标榜“快充”的数据线其数据传输速率跌回了 USB 2.0 时代的 480 Mbps？

还速率…… 我甚至都不知道苹果配的那根 usb 线能不能传数据

除了拿来接电源真的没试过其它用途

2022-04-10 18:19:44 +08:00

回复了 OldNio 创建的主题 › Apple › 公司发了 21 的 16 寸 mbp 还有必要买新的电脑吗

@herozzm
@OldNio

公司电脑离职肯定会回收的，但有个通行做法是一定年限后所有权可以归你。比如阿里就是 4 年，4 年到了可以选换新或永久保留（鸡贼）。不过用这么久了也都到淘汰年限了，所以你懂的……

公司电脑也不是说就完全不能干自己的事，我还得登录自己的私人账号不是，但另一台 windows 主机打游戏还是很必要的。我和周围认识的所有人都是组一台台式机打游戏，主力生产工具用公司的笔记本，除非有很特殊的需求才会自己再添一台笔记本。

原则 1 ，同一领域和用途的重复持有就浪费了
原则 2 ，在特定领域里使用最适合且最好的

2022-04-10 18:00:29 +08:00

回复了 echojoy 创建的主题 › 问与答 › 大家的主语言都是什么啊，为什么选择他（她）

@pursuer 使用 C 暴露的数据结构确实大多数语言都没什么瓶颈，但方向调转难度就要陡增了。golang 和 C 几乎可以直接共享所有的数据类型，比如一个很常见的 C 接口接受一个 const char* 或者 struct whatever *，那些有 vm 的语言要从原生层传一个这种结构进去就算谈不上多麻烦吧，起码转译数据结构是躲不开的，而且好多实现被屏蔽了看不到做了啥。在 golang 这就是个「不会被 GC 的 unsafe 指针」，跟 C 的思路完全一致

我是感觉 plugin 属于那种还在 experimental 的东西（虽然发布挺早，但简陋啊），golang 1.11 之前的包管理也很糟糕，但现在已经能吹了不是，以后会有的（大概，如果有人提的话……）。之前的项目里，需要动态特性的一律无脑 grpc 了，socket 总是能用的。还是那句话，确实简陋，但轮子很容易接，这点成功弥补了很多缺陷。

2022-04-10 02:28:22 +08:00

回复了 lsk569937453 创建的主题 › 程序员 › 如何快速向文件中写入 1 亿个 ip？

@levelworm 好多都是学校里的了，因为学校里你有时间，可以很纯粹地为了学习而学习。你可以 TCP/IP 详解一二三卷硬看，虽然最后可能没记住多少，但看过了哪些目录一定是有印象的，这跟从目的出发一点一点零碎地搜就完全不一样了。

在学校你也有机会看一整本自制 OS 教程，一整本 Linux 教程，一整本 windows 核心编程，你如果说「系统地」怎么学的，那就是书籍目录，没有比这个更系统的了。

有了这些印象作为框架，即便是搜索新东西也会更有头绪一些。比方说 OP 这个例子，假设他其实想解决的问题其实是「要对大量 IP 进行匹配」，你就能想到协议栈，想到 win 和 nix 的内核，就会联想能不能手写逻辑简化数据结构的处理，以及联想到能不能别用内核的协议栈——复制数据和切换内核态都很耗时间。然后你就能用 high performance 「 USER SPACE 」 tcp 「 STACK 」搜到 DPDK （虽然我是从前公司项目知道它的），而搜 high performance tcp 就很难找到这种方案

我想大多数人都不缺书单，缺的是时间和精力真的去看一遍…… 工作之后自己都有点开始对「为了学习而学习」不屑一顾了

2022-04-10 02:03:17 +08:00

回复了 FreeCodeWu 创建的主题 › 程序员 › 在 serverless computing 下，有哪些方向可以给程序员提供服务？这样范式下有什么痛点？

几乎所有的工具型服务都可以 serverless

我个人很期望的一点是，能有个在线版的文档搜索，取代掉 dash 。这东西最大的缺点是不跨平台而且要手动管理文档集，要能做个 IDE 插件写什么项目就查什么就好了

然后就是些计算密集型的东西，视频压制什么的。用 PC 压片真的蠢，高参数压片一压就一晚上，母片数据也就几个 G （粗压一遍），再不济一两小时也能传完了，让我的 PC cpu 满载几小时不能响应，显然是不经济的

专家们在说「是未来」的时候，我猜他们的期望是以后别再用本地机子跑机器学习了，随时租一个短期高性能炼丹炉肯定要香很多

2022-04-10 00:57:43 +08:00

回复了 echojoy 创建的主题 › 问与答 › 大家的主语言都是什么啊，为什么选择他（她）

最近看到不少 golang 的抱怨帖

但我想给 golang 正一下名。
众所周知没有任何语言或套件能解决一切问题。如果语言能解决一部分问题，那么在这部分问题上就是个好选择。

golang 解决了什么问题：

1. 没有菜逼能把程序性能写崩，也不会有 pro 写出你要看很久才能弄清楚妙处在哪的魔法，逻辑很直观
2. bootstrap 一个项目足够简单，有现代的好用的，yet keep it simple 的包管理
3. 对接 ABI 没有什么痛苦，一切可以在 C interface 上完成

这意味着 golang 保持着极低维护成本的前提下还能提供不错的开发效率。

在过去，能达到 1 效果的语言都因为先天不足非常难以管理构建环境和依赖，看看 C 就知道了。上手一个 5w 行不到的 C 项目，可能都得先研究半个月构建脚本在写什么，甚至怎么往项目里加一个新文件都要试错很久，单元测试也是噩梦，写一个「自动收集某目录下的文件并生成单测 executable 」的「构建脚本」就得花掉不少时间，更别说试图引入一个新依赖包的时候 —— 我 tm 不如想办法复制粘贴一小部分要用的代码得了。

而这一切在 golang 上只需要 go get 和 go test

可以说 golang 的项目我是有自信无论最后写成了一坨什么样的屎，后面接手的人都是能吃得进去的（）

golang 粉在吹什么大道至简是吹歪了。简陋得承认，error code 就是冗长。但比起 c++ 能在异常处理里因为捕获的异常对象指针莫名其妙空了而 crash 的这种「异常」（这是我遇到的 ANTLR 生成的 c++代码的一个真实 bug ）—— return error code 你一目了然它不可能搞崩 GC 。这种「从简」还相对有道理一点，但表达不出 golang 的优点。

一句话来说，一个语法跟 C 一样简单，且无缝对接 C Interface 和 os native 的，能编译成 standalone 的性能不错的静态类型语言，还能像 nodejs 一样随意下载任何依赖包，着足够现代的生态支持，我认为足以成为任何想要开发面向服务器应用的小开发团队的第一选择。

找不到会写代码的人=>不需要，随便写写不崩
简陋语法写起来很慢=>不用造轮子，你能很快地搜索并一键引入全球的轮子

小公司福音。

1 ... 50 51 52 53 54 55 56 57 58 59 ... 148

❮

❯