@edimetia3d 然而 concept 和 constraint 不就是俩东西来的吗……

应该无解，不如说这看着像个缺陷，不应该合法才对

无论是可变参数 va_args 也好，还是可变模板参数 typename ... TS 也好，本来都只能作为最后一个参数。这个 case 推导不出来不奇怪，但居然没报错

npm cnpm pnpm 都遇到过依赖装不上的破问题
选 yarn 是因为暂时没遇到幺蛾子

贵生态圈是真的一言难尽

@markliu2013 你太大声了（👿

如果能接受非定期贡献者我倒是不介意看看

仔细看了一下描述，你们全都是兼职的，所以你肯定也不能要求合伙人全职无薪。那么远程非定期我觉得也很合理。

另外既然重要的是商业模式，你们代码其实完全闭源的意义也不大，因此在源码隐私性这点我觉得也合理。

mailto: cG5ja3h4QHBtLm1lCg==

关注白雪艾莉娅喵关注白雪艾莉娅谢谢喵


------


喜欢看女孩子打游戏聊心事很奇怪吗？
真人直播约等于你在群里跟一个头像是自拍照的群友聊天
套纸片人皮直播约等于你在群里跟一个头像是冻鳗角色的群友聊天

就这丁点区别，没了

必经之路：
1. 无人光顾
2. 被分享到论坛，开始曝光
3. 约 p 撩骚处理不利，被铁拳
4. 机器人处理不利，被上缴大量流量学费
5. +验证码+手机号实名认证+消息记录全量副本+人工审核
6. 烂完

@ligiggy 啊 msvc 那有点蛋疼，windows 的 libc 好像没有自己的堆管理，直接用的 win32 api 。 可以先试试 HeapAlloc / VirtualAlloc 能不能分配出足够的空间

@iosyyy 你擅长记概念这点我看出来了

那么我替你总结一下你表达过的观点
1. cpp 也有 ioc 框架
2. 改代码不符合开闭原则但改 xml 符合
3. 不要屎山
4. 不流行的做法不代表 bad practice

噢…… 除了第二点不同意其它的我同意啊

所以为啥要有个像 spring 的框架呢，它会好用吗？


OP:
> 真的需要将 Go 写成 Java 的样子吗

#29 :
我的观点是作为一种指导思想，在不同语言里有适合各自的表达形式，复制一个相似的框架并不能起到足够引人注目的效果，而且同一种设计在不同语言机制下能带来的意义也不同。因此我认为不需要或者不应该把 go 写成 java 的样子。

上述观点我后来又重复地显式地总结了一次

#47 :
> … 本身就是 IoC 作为设计原则的体现，而非造一个看起来像 spring 的框架，那根本就不合适啊



这一点我们共识吗？

500m 是很大了，而且比较要命的是，如果你只用标准库而不直接调 OS API 预留内存的话，上一个 500m 的连续空间不知道什么时候就会被 glibc(ptmalloc)拆碎，拆碎了之后还不会优先合并大区块或者热区块，让 glibc 来管这些反复申请的大空间不是个好做法

monotonic buffer 是单调递增 buffer （即指针永不回退，除非整个 buffer 释放），适用于把相对大的一整块内存分给要不停分配小空间折腾的场合，不太符合你的需求


建议尝试 std::pmr::vector 配合 pmr::memory_resource ，然后手动 mmap 一块内存作为 memory_resource 的基底

另外因分配内存导致的性能缓慢通常是因为分配姿势不对引起的，比如是不是用循环依次复制每个对象了？是不是调用太多其实没用的构造 /析构了？ c++里如果发现分配内存占了时间大头绝大多数都是逻辑写得有问题可以优化掉的

@iosyyy CRTP 是一个经典又独特的 idiom, which 完美体现了「反转」是怎么一回事，但 cpp 哪个项目试图把 spring 那一套在 cpp 上重新造一次吗？ 就算我孤陋寡闻没听说过「可能被拿出来举例的项目」，但那个项目——它不流行吧？也不在 cpp 的主流视野里吧？


你看了知乎，也看了阿里这个框架想干什么的话就会明白我说的「拿锤看钉」是什么意思，就跟在 cpp 里写
template<class T, class F > class IoCContainer{std::variant<T> obj}
class MyService : public IocContainer<MyService, Feature<Service, AutoWire>> {}
一样，也不说徒劳吧，反正看着滑稽是肯定的，因为 cpp 里模板参数本身就可以当成接口来用，根本没必要去模拟注解的功能，也模拟不来，顶多仿照一个静态版本——而静态版本↑模板参数本身就可以当成接口用，service 的使用者只要写
template<class S> class UsingService{}
然后在 UsingService 实例化的地方（而非 UsingService 内，UsingService 并不直接依赖 Service ，而是自己的模板参数）给 UsingService 派发 MyService 就好，这本身就是 IoC 作为设计原则的体现，而非造一个看起来像 spring 的框架，那根本就不合适啊。


另外开闭原则指的是（广义版）逻辑模块的开闭，你这直接把整个程序都看成不可分割的一个大逻辑块的看法整得我有点无语

@XCFOX

我写过一丁点 unity ，unity 本身就非常 DI 。对于场景设计器之类的东西静态定义的对象，框架控制着对象容器，写的逻辑会被框架反向绑定到对象上，逻辑类（ XXBehavior : Behavior ）是通过 unity 提供的 API 来获取自己绑定的物体实例的，物体不持有逻辑逻辑也不持有物体

有啥好看的，拿锤看钉罢了

第一性原理： IOC 是什么，解决了什么问题

- 是什么： 当我在一个纯 OO 语言里，想用到某个 object 提供的方法时（比如 A 类的实例）需要 a=new A; a.method()
但我不希望当前写的这个逻辑依赖死 A 类，我希望有个「只要跟 A 类差不多的类实例」就行。于是可以使用接口+工厂，即 a=AFactory.New();a.method()，但这个实现依然要依赖特定的工厂，我希望写任何逻辑都能有一个万能工厂提供我要的接口，于是我不再在逻辑里写 a=new A 了，我写 a=THEGOD.provide("A")，或者在我的构造函数里写 CreateMe(I_WANT_AN_A a)，这样我就有 a 了，怎么来的我不管，谁爱给谁给。

- 解决什么问题：
1. A 经常变化，我无法自己得到正确的 A ，但 GOD 可以，因为 A 会告诉 GOD 怎么生成自己
2. A 就算变了，我不需要配合改变，「代价」比较小




好，现在思考这两个问题在 golang 语境的意义

先说代价。因为这是最显著的差异
golang 是一个需要编译成二进制的静态类型语言，而且所有的代码都在同一个二进制里
它不像 java ，改了某一个模块，仅仅是那个模块的字节码发生变化。java 甚至可以动态加载字节码，也就说它完全可以 core 保持运行，临时下线一些功能，加载新的字节码，将原功能指到新加载的字节码上。
但 golang 不行。
****任意代码的修改都会导致整个程序重新编译****
编译时长之类的问题可以通过缓存文件优化，但是
****服务程序必须全部停止****
这一点是不会改变的。无论怎么折腾，golang 写的代码都必须重新编译，且**完全停止**原来的二进制程序运行再跑一个新的。
因此相比于 java 语境中「代价」有重大的运行时意义，golang 语境下「代价较小」的意义仅仅是保持代码工程的相对整洁罢了，但源码组织是整个软件工程中相当不重要的一环，我想没什么人会否认吧。大家都住在屎山，但没听说哪里的代码写成喜马拉雅能跑写成屎山就跑不了的。



再说问题 1

// service.go
var a IA = NewA()
a.method()

// interface.go
type IA interface{ method() }
func NewA() IA {
if 1{return a.NewA()}
if 2 {return a.v2.NewA()}
}

不行吗？
service 不引用 A 吧
interface 要改，但跟改 xml 本质上没什么区别吧



另外静态语言都不热衷这种框架，因为就算语言提供反射，它们也不像动态语言一样能「凭空造出一个类和实例」，从本质来说它们只能「改变指向类型的指针」，因此只要类型结构本身没有编译到二进制里，无论怎么折腾也造不出一个新类型。

这也就意味着 IOC 框架再怎么折腾也需要一个已经存在的类型实现，而非只要有存根就行。
因此在这些语言里，让框架为使用者寻找一个 IOC 容器的意义也仅仅只是在一个编译期就确定的类型映射表里找一个合适的类型罢了

那我代码里直接用这个静态映射不就好了，我干嘛还要「委托框架来帮我找」




----


拿你提的这个框架来说
1. 不使用这个框架，只用 interface 是不是也能从代码上解耦？
2. 使用这个框架，接口实现变化是不是一样的要「改代码+重新编译+重新部署」而且改动范围差不多？

golang 生态在微服务化跟 java 生态在 bean 化都是需求和语言特性 /限制的「磨合」，反向照猫画虎反正我的心态都是看个笑话

假设 c++库 /程序叫 core:

- core 在内存中保存配置或者控制位
- core 如果需要被外部控制，可以序列化成比较通用的结构化数据比如 json/msgpack ，外部控制器（比如 golang 写的 web 后端）来负责持久化它们，存取数据库之类的，core 只解析 web 后端传过来的结构化数据
- 转发器直接将流量转到 core ，比如 nginx module 或者集成了 libpcap 的东西，它们可以直接通过 IPC 手段与 core 存取同一个共享 buffer
- core 执行必要的计算并且在内存中保存计算状态
- 等待 web 后端异步地来读取这个状态，或者 RPC 通知后端状态发生变化
- 在 RPC 里传递计算结果，这时候就还是通用结构化数据

c++后台一般不直接跟 web 交互

可选的方式有：
1. 编译成动态库，暴露 C ABI 的 API ，这样 goalng 之类的后台基本可以即插即用（需要共享一个头文件和一个不需要实现具体功能，即 stub 的动态库二进制文件）
2. 使用 unix socket ，交互 json 数据或者 protobuf 之类的（无队列）
3. 使用消息队列中间件，随便选一个两边语言都有 binding 的