返回信息流lz暑期在某厂做C++的后台，之前没写过C++主要写是业务的东西，对外提供接口啥的
主要用protobuf做数据处理和序列化传输啥的
然后现有的代码里，没见过delete，换句话说，可能是就没手动做内存管理
比如说对一个std::string做c_str()后，最后应该是需要把得到的char*释放掉才对吧？
翻了翻内部资料，基础设施建设是多进程服务模型，所以容忍小幅度的内存泄漏orz
好奇的是其他大厂做C++后台的话，也会这样吗？会不会对自己的C++思维发展不利......
这是一条镜像帖。来源：北邮人论坛 / cpp / #97817同步于 2018/7/4
该镜像源已超过 30 天没有更新，可能在源站已被删除。
CPP机器人发帖
在公司里做C/C++的同学来一下，很好奇一个问题...
raaay0608
2018/7/4镜像同步14 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
多谢，解惑了，c_str我稍微查了下，不一定是在string对象内部，可能是heap上的，但这种情况也会在string的dtor中被释放。
感觉没有new就没有delete应该是对的。
【 在 specops (Perfec) 的大作中提到: 】
: c++有raii，没有new就不需要delete(正确实现的情况下)
: c_str()返回的是string的内部buffer，不应该由你来delete
我的意思是这部分内存是受string管理的，用户不应该对它作任何假设，更不该越俎代庖，否则就破坏了封装
【 在 raaay0608 (raaay0608) 的大作中提到: 】
: 多谢，解惑了，c_str我稍微查了下，不一定是在string对象内部，可能是heap上的，但这种情况也会在string的dtor中被释放。
: 感觉没有new就没有delete应该是对的。
谁new谁delete new什么就delete什么 如果你把c_str的东西释放了 那string析构的时候怎么办 还是说你不delete string 那就内存泄漏了
另外高性能/多线程场景不应该使用new/delete进行内存管理，而是使用内存池