@changnet 啥时候连构造函数都不可控了呢？

@zhiqiang 就感觉你一直在处理好大一个烂摊子。。。

@wens07 f(x,y)==0 返回的 bool 值转为下标值 0/1，前面是个字符串字面量，用下标值从中取出对应 char。

@ooo3o 我也有对齐强迫症，我用 pos/end 或者 beg/end

既然都提到 finish 了，再加个 close 吧

@arzterk 都已经 delete 了 shrink_to_fit 就不重要了吧。

@zhiqiang 好像就我一个人在写 C++...

我感觉楼上说得有道理，虽然我不懂这块。。。

boost::circular_buffer 的模版参数是什么？
你 new 的对象是 vector 还是 circular_buffer 还是 circular_buffer 的模版参数？

@careofzm 计算机科学的缩写，也就是科班出身的意思

emmm, 中间那一段，说实话，没看懂

最终结论还是靠“猜”来得到的，做的实验对证明结论也没有直接帮助。

talk is cheap

在 C++里这属于典型的 ub 了，因为函数传参时 eval 顺序是未定义的。
单就这个例子来说，先算了(a++) 后算了(a)，结果没毛病。

@yuikns

这是我实现的 immutable data 类

https://gist.github.com/wutiantong/f322dd0ca7c0b3021cdf807e7f60a171

@yuikns

std::shared_ptr<string_view> 这个用法就很诡异了，几乎不存在。。。
因为 string_view 这个类不负责底层指针的生命周期管理，给它外面套一层 shared_ptr 并不会改变什么。。。

你说的这个需求，我以前刚好粗略实现过一个很类似的，待会可以发一下。

但说实在的，这种东西真的是用途不大，毕竟 immutable 太死板了。
目前来看最佳实践应该是 string + string_view 这种形式。

正如 @ipwx #8 所说，针对 shared_ptr 的这种封装可以认为是一种伪需求。

C++里面做数据结构封装时的最佳实践就是值语义，而你这段代码就是一个典型的违反值语义的示范。
那么这会带来什么问题呢？请看下面的例子：

Bytes s1("Hello");
auto s2 = s1;
s2[1] = 'a';

对 s2 的改动会意外的传递给 s1，在现代 C++中这段代码表现出来的行为是完全反直觉的。

同样在内部涉及到大量的动态内存分配操作，而 STL 中的各种容器（ vector, set, map ）无一例外的遵循着值语义。

C++之所以提倡值语义而不必担心引入额外的性能开销，是因为 C++提供了引用，指针，移动这一系列利器。

也就是说当你实现了一个值语义的 Bytes 后，你就可以免费享受：
1. Bytes &
2. Bytes *
3. Bytes &&
4. std::shared_ptr<Bytes>, std::unique_ptr<Bytes>

而像现在这样一个不遵循值语义的 Bytes 只会引入无尽的混乱。

@wangking 现在没有方案？ 那你主题里写的 1 跟 2 是啥？

现有方案的优缺点是啥先讲清楚

@ldd 我觉得强调“子公司”的恐怕都不太能转，正常能转的就像楼上说的那样叫“分部” or “有编制”。你还是得事先打听清楚才行。