更何况婚庆公司不可能 7 天无休的，哪有这么多人结婚还找同一个公司。再算上设备费用之类的，公司抽成，ummm 我觉得楼主还是不食肉糜了

程序员一个月 5 天三万工资嫌公司小气。

婚庆公司一套班子少说也有三四个人吧，一单 2800 一天，每个人 700~900 块。哪怕是 7 天无休呢，900*30 也不过刚刚三万。。。

接上一条。总之 C++ 里面我第一反应就是写个重载，然后重载函数构造一个局部栈对象或者智能指针传给参数多的那一个，根本不会轮到 new XXX 这种默认值出场。

@h404bi 怎么说呢，其实我内心觉得任何语言在默认值里面构造堆对象都不是好的行为。

@sillydaddy 我第一反应 C++ 程序员应该不会意外这种设计，主要是 C++ 有栈对象。如果是栈对象作为默认值，那么我理所当然地认为这里栈对象本身是默认值的一个拷贝。反而如果默认值是 new XXX()，我理所当然地觉得，那这种东西作为默认值，本来就不行，涉嫌内存泄露。

简而言之就是我潜意识觉得符合 RAII 原则的程序就不会在默认值 new XXX()。毕竟连 std::shared_ptr<XXX>(new XXX) 都是错误用法，应该使用 std::make_shared<XXX>() 不是吗（笑

yysy 我觉得接受这种行为去写程序也没啥不好，写起来基本不会有啥不方便的。把对象构造从默认值上面移开其实是一种很好的习惯。

@sillydaddy 嘛不管怎么说我从内心最基本的原则里面其实早就接受了 Python 的这个行为。如果不是今天看到这个帖子你的回复我估计从来都不会发现这件事。

不过哪怕避开这种写法，C++ 写起来也应该很方便。。。至少我上面这个例子里面的用法肯定不是正常的 C++ 用法就对了。

@sillydaddy ummm 本来觉得 C++ 也应该是类似 Python 的行为，没想到不是。

https://ideone.com/iulg3B

这还挺让我意外的。这么说来 C++ 的默认值是求值表达式，在调用时会展开。

不是 Bug 也不是 Feature 。我觉得有过 C++ 经验的程序员更容易接受这个设定。

@nothingistrue ？我一开始就没说是虚拟磁盘干的事情啊。。。

“只是声称这个文件有 120G 但是没有分配存储块而已。”——虽然笔误写成了 120G 。我这里说的是操作系统没分配（物理）存储块，这有问题吗？

现在通常所说的设计模式 OOP ，最佳实现模版就是 Java 那一套。当然结果大家都知道了，纯 OOP 单继承的设计模式就是又臭又长，虽然对于规范良莠不齐的团队开发很有用。

Python 一般情况下都不是纯粹的 OOP ，Pythonic 是一种混合了函数式、命令式和 OOP 的特殊形式，形成了它自己特有的写法。一般来说相同的功能，Pythonic 写起来还挺简洁的。——当然，也不绝对。

----

总之按楼主的初学者属性，用 Python 去对照设计模式容易走火入魔。要么忘记“设计模式”去体会 Pythonic ，要么扔掉 Python 去学习设计模式。

？好怪，我不知道 @nothingistrue 一本正经地想要纠正我啥。

按照这个形式，这个案例确实是声称了文件有 12G ，确实没有分配物理的存储块啊？不管是 NTFS 层面的“压缩”手段，还是 NTFS 的稀疏文件，还是 Linux 啥神奇 Hack ，不都是实现这个效果的某种手段嘛。

我也没有深入各个文件系统不同的实现方式，

@nothingistrue "Size 11.7 GB ，Size on disk 138MB 。12G 资源已经分配了，后面是磁盘系统实际占用 138MB ，这个跟虚拟磁盘无关。"
----

对不起真的和虚拟磁盘有关。

香农老爷子已经明确告诉你了，信息的压缩比是有极限的。12G=>138MB ，显然大部分数据位都是 0 ，所以才能把那部分 0 的位置给压缩出来。这恰恰是虚拟磁盘才会有的特性。

@tool2d 这部分评论也适用于楼主。不信楼主你在虚拟系统里面随便放个 10GB 的视频文件再删掉，然后你再看看 NTFS 能给你压缩到多大。

----

从这个意义上，“它只是声称 12G” 一点毛病都没有。不论是 NTFS 层面声称 12G （但不占用），或者预留出 12G （占用）。反正真正原因是没有写入非 0 数据所以才看上去有这么牛逼的压缩比。

@qrobot 我不否认粘包实际不存在。我知道 TCP/IP 。但我觉得既然这么多人叫，那在别人都这么叫的语境下，借用这个术语表达他们的意思，我没意见。。。

为啥要这么纠结术语的纯洁性。DL 论文里面一堆（数学）术语乱用，只要该 domain 认同，不也就这么过来了。

只是声称这个文件有 120G 但是没有分配存储块而已。

@nekoneko 吗吗，你的言论有些“反粘包警察”哦。

所以其实我“粘包”打引号了。虽然 TCP 确实不存在粘包这个概念，但是在应用中这个“问题”确实存在。我是不关心这玩意儿到底用“粘包”这个术语，还是准确地“因为 TCP 是流式协议所以必须自己处理数据包分割的问题”这么长的文本描述。在我看来，入乡随俗，如果“粘包”接受度广，用“粘包”来代指上面这句话我没意见。

@ChoateYao 嗯我确实说错了，在通用模型里面属于第四层应用层。HTTP 和 WebSocket 都属于应用层。

另外如果看 HTTP 和 WebSocket 的关系，实际上 WebSocket 可以独立于传统的 HTTP 服务器单独使用，只不过 Handshake 这一步好像用了 HTTP header 。但如果一整个端口都用于 WebSocket 应用程序的话，其实可以忽略 HTTP 协议这玩意儿。

WebSocket 单独使用，你可以参考币的交易所协议。

TCP 确实有“粘包”问题。

所以为什么要死磕 TCP ？找个 TCP 上层的、有“消息”概念的协议不好嘛？比如 WebSocket ？

我有些反感粘包警察，是因为早就被标准化解决了无数遍，直接拿来就能用（比如 WebSocket 这个五层协议）的问题，非要当做现实中一个重大问题去翻来覆去地讨论。

@tool2d ？合着股东不挣钱来供着二次元小将是吧。