sharedptr的用法 shared_ptr的用法？

shared_ptr的用法？

写cpp，语法的痛苦点模板，等你模板报错达到几百行的时候，你就会明白劝退 1。第二个痛苦点，内存操作，包括内存越界，内存泄露，内存脏数据，共享内存，内存池等所有相关，迟早会遇到程序崩溃，劝退 1。第三个痛点，锁和多进程多线程还有协程，以及管道通信，消息机制。这些都是操作系统相关的知识，要搞明白不比学cpp简单。劝退 1。第四个，既然用了cpp，那就迟早要用到so，dll，对应的debug噩梦来了，服务器上用gdb调试带so的多进程多线程程序的难度和复杂度，会让人迷失。劝退 1。第五个，平台，编译器不同，优化和不优化导致程序运行结果不同，这个时候我都是无语问苍天。第六个，宏噩梦，dll依赖噩梦，cpp编译时间长噩梦，以及系统突然升级（安全漏洞修复）导致某个库不兼容的噩梦。没经历过的人是体会不到的。

如果实现了一种不用暂停世界的GC算法，会对现在编程语言产生什么影响？

很高兴回答你的问题。

首先，仅以个人较为熟悉的java jvm gc去回答这个问题

我们知道gc算法有很多种，同时，我们也知道，每一种gc算法在做full gc的时候都会STW，但是，每一种的gc算法都不会一味的追求极短的暂停，甚至楼主所说的无暂停。这在计算机中其实是一种平衡。

我们都知道计算机资源是有限的，任何一个指令的执行都是需要消耗资源的，在越来越先进的技术面前，我相信而且也确定已经有gc算法可以做到完全的并发，但是为什么没有成为大家通用的算法呢？这其中我认为就是资源的平衡。

gc算法的完全并发必然会造成cpu开销加大，一定程度的暂停，其实是有助于程序吞吐量性能。而且目前优秀的gc算法的暂停速度极快。在这种情况下，极短暂的暂停换来整体资源回收后的大幅吞吐量性能的提升，其实不见得不好。

当然，gc算法的选择极其重要。

因此，个人拙见，选择合适的gc算法，远比追求极端的不暂停更有意义。

谢谢。

c 中关于智能指针std::tr1::shared_ptr的用法？

智能指针本身绝对不能是动态分配的内存，不然只能指针就没有存在的意义了。

智能指针有个数据成员，是个指针，至于什么类型，看你类模板怎么实现。这个指针才是动态分配内存的。只能本身必须是栈里分配内存。利用栈的自动回收数据的特性，在被系统西东回收时，调用智能指针类的析构函数，从而释放智能指针内部那个指针型数据成员所指向的内存。举个例子 std::shared_ptr

关于发生时异常时，shared_ptr智能指针会自动析构的疑问？

看不到测试代码。

原则上，发生异常或函数的返回路径上，析构函数的调用是由编译器插代码来保证的。不过一般不要在构造和析构函数里抛出异常。

C 的异常是库和逻辑级别的，必须代码throw；错误的内存访问、除零错误等不是C 异常（在曾经的vs ide上，ms扩展了编译器行为允许try/catch处理结构化异常，注意看IDE设置选项）。这是不同于Java和C#的，他们是虚拟机平台级别的，除代码抛出外，发生异常时虚拟机也会抛出。

另外，在C 里异常是可选的，很多库都提供了关闭或开启的开关。而Java和C#是强制性的，属于核心机制。

sharedptr的用法 shared_ptr通过什么资源共享 shared_ptr原理

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。