@wsseo 我认为就楼主的需求来看，“图形化 SSH 工具”不是合适的选择，更不需要商业产品
之所以一些人更偏向于某些商业图形化 SSH 工具，而不是 SSHFS，原因可能有很多，我只能做推测
比如他们解决了“方便地传输文件，方便地编辑文件”之外的问题
比如他们有商业支持
比如 SSHFS 的实现存在一些问题
比如网络环境受限
或者仅仅是信息不对称

实在不行，小孩才分对错，大人只看利弊，你满意了吧
Might makes Right，你满意了吧


实在不行我们来讨论 5G 预期中的普及能对 SSHFS 的应用产生什么影响吧

@wsseo 不，就是因为这种方式从根上就是错的。

@efsg 您好，vi 和 nano 不喜欢可以尝试下 emacs :)

楼主的需求无非就是，方便地传输文件，方便地编辑文件，简单来说就是以本地文件的方式操作远程文件
那 SSHFS 就可以了啊

"图形化 SSH 工具"这个东西的存在就是很尴尬的事情，这种工具做得再好也不可能像本地文件系统一样和其他软件一起无缝的互操作，虽然它解决的问题是存在的，但是它选择了错误的层级来解决这个问题。我个人觉得这种工具是没有未来的

（然后话题转进到一个图形化的 SSH 连接工具，可以选择服务器，记忆用户名 ...

其实应该说，你正确调用 swap 的时候，把 std::swap 重载了
另外 C++20 之前调 std::swap 应该是不会调到你的 swap 去的

@alanlian 意思类似于：
Q：传输大文件用什么服务最吼？
A：顺丰快递
你感受一下

标准对 overload 的定义：“When two or more different declarations are specified for a single name **in the same scope**, that name is said to be overloaded.”
technically，你在使用 swap 的时候用了 overload resolution 的机制，overload resolution 在决定 candidate set 的时候会考虑 scope 和 ADL。不过 overload resolution 和 overloading 是两回事

这个不是重载的 std::swap，这个新函数应该是通过 ADL 被找到的

啊等等我好像搞混了，无视掉 #8 的评论吧 ... 我再看看

friend 好像是只能写在这吧 ...
这里 swap 是个成员函数，成员函数是可以不加 friend 访问自己的 private 成员的

之前好像没见过这么写 copy-and-swap idiom 的（不过 C++11 之后好像不用这个 idiom 也可以了

@icekingcy 请升级网络，FreeNAS 不背这个锅

噢对了，如果是 Windows 的话，有一个类似的功能叫 Shadow Copy

你可以使用带 snapshot 功能的文件系统，比如 ZFS
实例：FreeNAS 就是使用一个 ZFS Dataset 作为 ROOT 文件系统，每次升级之前会自动创建一个 Snapshot，并且会把这个 Snapshot 添加到系统启动菜单中。这样如果升级挂了可以重启进入之前的系统

在你创建了 snapshot 之后，你可以使用 zfs send 命令把它序列化，然后通过 zfs receive 命令将它 replicate 到另外一个 zpool 中（如果是两台机器，中间用 ssh 转发一下就可以）

当然我觉得实际情况是，移动硬盘比笔记本硬盘更容易挂（笑
所以 FreeNAS 原来的推荐是用两个 U 盘做系统盘，现在的推荐是用两个 SSD

另外一种方案是通过 ZFS 等软 RAID 方案，把笔记本硬盘和移动硬盘做一个 mirror，这样可以做到完全实时、无缝的同步，但是也要求时刻都插着移动硬盘

亮点还是有的，就是 Phil Schiller 那句"Oh it's so pro"
直接逗笑了

名字前两个字母已经告诉你了 ...

@CEBBCAT 楼主明显更习惯这么写 ...

你得学会带面试官的节奏

俩好像都挺监听的
880 能一千拿下么，是二手么

Mac 不是有 FileVault 么？
还可以用 ZFS Encryption，不过我不保证 ZFS 在非 ECC 内存上的数据完整性
x86 平台上合格的软件加密应该都可以利用 AES-NI，所以如果你的处理器支持 AES-NI，性能损失应该不大。

@FaiChou 这个其实很难说是一个 bug。“a 在第五行被回收了”也完全没有保证。

另外 GC 这个东西很难被定义，我至今没见过哪个语言成功地在自己的 spec 中把 GC 以确实有用的形式定义出来。
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Determinism：Tracing garbage collection is not deterministic in the timing of object finalization. An object which becomes eligible for garbage collection will usually be cleaned up eventually, but there is no guarantee when (or **even if**) that will happen.
意思是就算一个对象实际不被引用，Tracing GC 依然可以**根本不回收**它

这个不仅仅是 wiki 这么说，Scheme 的 spec 更有意思：www.r6rs.org/final/r6rs.pdf 第一页就说了：No Scheme object is ever destroyed. The reason that implementations of Scheme do not (usually!) run out of storage is that they are **permitted** to reclaim the storage occupied by an object if they can prove that the object cannot possibly matter to any future computation ... "Permitted" 意思是 Scheme 实现可以根本没有 GC ...（关于 Scheme 对内存这个东西的定义后面还有更多的描述）

JLS 写得很模糊：When an object is no longer referenced, it **may** be reclaimed by the garbage collector. 但是 JLS 里面还隐藏了另外一个有趣的东西，就是 finalizer，紧接着上面一句话：“If an object declares a finalizer, the finalizer **is** executed before the object is reclaimed to give the object a last chance to clean up resources that would not otherwise be released.”，后面还有一节专门讲 finalizer 的同样说："Before the storage for an object is reclaimed by the garbage collector, the Java Virtual Machine **will** invoke the finalizer of that object."，但是后面又说“A finalizable object has never had its finalizer automatically invoked, but the Java Virtual Machine **may** **eventually** automatically invoke its finalizer.”

这个定义就算是把 may 去掉了也没用 ... 比如考虑我定义成对象 eventually 会被回收，但是同时实现成“无限长”之后会被回收，在实际情况中依然是一个非常受限的实现

这就相当于根本就没有办法从 spec 的角度 enforce 任何 GC 的行为。而我们一般意义上研究的 GC，从这个角度来说都属于编译器的“优化”，“优化”就是 spec 没有强制要求（实际上正常的 spec 不会有任何相关内容），而实现所添加的在保持 standard conformance 的同时为了增强某些方面性能做得的额外的 feature。这就是说为什么这个 Chromium 的 issue 是个 feature 不是个 bug。

有一个很有意思的例子就是 PTC (proper tail call)，同样是 R6RS 的要求：A Scheme implementation is properly tail-recursive if it supports an unbounded number of active tail calls.（在内存受限的前提下，这个其实等价于 tail call 的 space complexity 是 O(1) 的）
有意思的是，C/C++ 标准里至今没有这样的内容，但是主流的编译器都做了这样的优化。ES6 做了类似的要求（不过标准的表达有些区别），但是好像现在只有 JavaScriptCore 的实现是可用的？
当 PTC 这条不在标准里面的时候，它就属于编译器的一个优化，优化不仅仅是实现相关的，更是没有保证的，编译器可以选择做这个优化，也可以选择不做这个优化。C/C++ 标准没有 PTC 是一件十分细思恐极的事情——背后的 implication 是：我无法使用标准 C/C++ 的函数调用实现一个符合 Scheme 标准的解释器（ ES6 同理），我必须自己维护函数调用的 activation record （或者依赖于特定的实现提供了这样的优化的这个前提 (这就超出标准 C/C++ 的范畴了)），这会让实现 DSL 更麻烦。而如果使用 ES6 来写，在实现符合标准的前提下就没有这个问题，而至于 V8 不符合 ES6 标准，就是另外一个问题了 ...
需要注意的是虽然 PTC 有若干其实挺 well-known 的实现方式，但是标准（尤其是 Scheme 标准）并没有规定该怎样实现 PTC，它仅仅规定实现应该满足的一个 性质。和其他的优化一样，就算标准里面没有这个东西，实现者也可以选择做这样一个优化（确实也很有用），但是这东西最后能进到标准里面，前提之一是这个行为可以清晰地被定义。在实现这一行为的过程中，某些实现可能会让 tail call 在时间上更慢，某些实现则会在保证 PTC 的同时试图让 tail call 的性能最优，但是这些都不在标准规定的范围内。