@murmur 楼主本来是希望合同到期自然走人的，但出于某种单方面的善意（中间过了个年怕耽误交接？）他觉得应该“提前”跟公司对接这些事情。
然而公司并没有尊重楼主的本意，直接就按他已经主动提离职申请来处理了。

我觉得公司问题不大，楼主缺乏经验自己给自己挖坑了。

@mathzhaoliang 为啥没区别呢？你这个说法有啥出处？

你可以自己解释一下，你对那个 explicit 有啥预期？

还没结婚就老丈人丈母娘的叫了？

@James369 曾经也写过 swift，链式的?和??的设计确实不错。但代码中过多的感叹号和问号真的会影响观感和可读性。

究其根源在于他们的标准库从上一代（ Obj-C，Java ）一脉相承，里面难免带入了很多 nullable 语义，导致实际代码中 optional 类型极度泛滥。

反观现代 C++，在最佳实践中大部分类型都遵循值语义，天然是非空的，所以根本就不需要考虑 optional 操作，只有在你需要 optional 语义的地方才会引入 optional 类型。所以可读性方面反而明显更佳。

@James369 C++有 optional 呀（ https://en.cppreference.com/w/cpp/utility/optional ）

@James369 你可以理解为参数声明为指针类型就是在提醒你这个参数必须要在堆上构建

@James369

所以也正是因为 QObject 的子类都必须要在堆上构建，它们才会被声明成指针类型的格式。

@wutiantong

再提一下，基于我对 Objective-C 的了解，如果 QObject 和 NSObject 是差不多的话，那么它的各种子类，都应该在堆上动态分配内存（这一步会涉及到引用计数的内存管理，很可能 QObject 重载了 new 方法）

所以，你确实不应该在栈上直接构建一个 QObject 的子类对象。

@James369

看起来，之所以是指针（ QHttpMultiPart *或 QIODevice *）的原因在于这些类型都是 QObject 的子类，相对的 QNetworkRequest 和 QByteArray 就不是继承自 QObject

QT 里的 QObject 这套设计应该是很早期的，非常类似于 Objective-C 里的 NSObject，为了与 C 兼容会选择用指针类型来表达对象。

脱离开 QObject 的类型就更接近于现代 C++，一般是不鼓励用指针传参的，而应该用引用。

一般不存在你说的这种堆 /栈区别，
我查了一下，QIODevice 是个抽象基类，是不能直接构建的。
那么无论是 QIODevice dev; 还是 new QIODevice 都应该要报错的才对。
要不你再检查一下？

@wohenfuyou 返回裸指针的函数无法延续对象的生命周期，指针传出来了但对象死掉了。

save an object, not a pointer

很多往事已如隔世了。

@dorafmon 你没有认识到 noexcept 这个关键词的设计意图

@dorafmon

这个知识点是没问题的，但你的论述可能是有问题的。

我们在 C++ Core Guidelines 中可以找到关于这个知识点更清晰更正确的论述：

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-dtor-fail

当你代码写得有毛病时，功能强大的 IDE 会贴心地用下波浪线来提醒你，这就是 linter

@dorafmon

是有这样的说法，但既然不是 ub 就可以在充分了解的前提下加以利用。

我倒想考考，你能简洁地讲清楚 noexcept 应该怎么写么？

没有稿子磕磕绊绊的讲解令人难以忍受。
另外我查了，析构函数是可以抛异常的，即使在 stack unwinding 中也不是未定义行为：

As any other function, a destructor may terminate by throwing an exception (this usually requires it to be explicitly declared noexcept(false)) (since C++11), however if this destructor happens to be called during stack unwinding, std::terminate is called instead.
https://en.cppreference.com/w/cpp/language/destructor