mq白
#114
写的是： >[dynamic_cast](https://github.com/huihut/interview#dynamic_cast) 用于多态类型的转换 **执行行运行时类型检查** 只适用于指针或引用 对不明确的指针的转换将失败（返回 nullptr），但不引发异常 可以在整个类层次结构中移动指针，包括向上转换、向下转换 **`dynamic_cast( 表达式 )`** 如果 表达式 是到[多态类型](https://zh.cppreference.com/w/cpp/language/object#.E5.A4.9A.E6.80.81.E5.AF.B9.E8.B1.A1) `Base` 的指针或引用，且 新类型 是到 `Derived` 类型的指针或引用，**那么会进行运行时检查**。 除此之外其他时候**基本上**是没有这种额外开销的。 并且它也可以用作其他的转换。 ```cpp struct X { }; struct Y :X...
描述的是： > [`extern “C”`](https://github.com/huihut/interview#extern-c) > * 被 extern 限定的函数或变量是 extern 类型的 > * 被 extern "C" 修饰的变量和函数是按照 C 语言方式编译和链接的 不管是第一句话还是第二句话，都是既**不严谨**，也**错误**的。 并且我严重怀疑抄了[知乎的一篇文章](https://zhuanlan.zhihu.com/p/123269132)，描述简直一模一样。 1. “是 `extern` 类型的”，这话很莫名其妙，`extern` 不是类型。 非要狡辩一下那就是，写的时候想着：“语言链接是每个函数类型的一部分”；但也和 `extern` 没关系。 2....
它并非标准的，一般情况下不该去使用它。 可使用标准的 [`alignas`](https://zh.cppreference.com/w/cpp/keyword/alignas) 和 [`alignof`](https://zh.cppreference.com/w/cpp/keyword/alignof) 运算符。
你们描述的是： > 方法：将 new 和 delete 重载为私有 事实上在我看来毫无价值，你设置私有，那我不让它优先查找内部的不就是，加有限定名字查找 `::` 优先查找全局的 `operator new` 和 `operator delete` 不就是。 除了逆天的 `msvc` 有限定名字查找有问题，`gcc` 和 `clang` 都可以直接使用。[`code`运行](https://godbolt.org/z/T5e8cWbMf)。 ```cpp #include struct X{ int n{}; X() {...
在内联函数中，所有函数定义中的函数局部静态对象在所有翻译单元间共享（它们都指代相同的在某一个翻译单元中定义的对象）所有函数定义中所定义的类型同样在所有翻译单元中相同。 命名空间作用域的内联 const 变量默认具有外部链接（这点与非内联非 volatile 的有 const 限定的变量不同） | (C++17 起) -- | -- 在内联函数中， 所有函数定义中的函数局部静态对象在所有翻译单元间共享（它们都指代相同的在某一个翻译单元中定义的对象） 所有函数定义中所定义的类型同样在所有翻译单元中相同。 命名空间作用域的内联 const 变量默认具有[外部链接](https://zh.cppreference.com/w/cpp/language/storage_duration#.E5.A4.96.E9.83.A8.E9.93.BE.E6.8E.A5)（这点与非内联非 volatile 的有 const 限定的变量不同） (C++17 起) inline 关键词的本意是作为给优化器的指示器，以指示优先采用[函数的内联替换](https://en.wikipedia.org/wiki/inline_expansion)而非进行函数调用，即并不执行将控制转移到函数体内的函数调用 CPU 指令，而是代之以执行函数体的一份副本而无需生成调用。这会避免函数调用的开销（传递实参及返回结果），但它可能导致更大的可执行文件，因为函数体必须被复制多次。...
The original description is unclear: > You can declare functions in a way that allows the compiler to expand them inline rather than calling them through the usual function call...
> 示例 >```cpp >struct T { > int i; > > int foo() { return i; } > int bar() { return 0; } > > static int baz(); >};...
> 失去对已分配资源的控制 其实单看这个，线程 `detach()` 也算是失去控制了。 [`std::thread::detach`](https://link.zhihu.com/?target=https%3A//zh.cppreference.com/w/cpp/thread/thread/detach)，线程对象释放了自己的资源（线程）的所有权，允许线程执行独立地持续。 不过可以保证一旦该线程退出，**则释放任何分配的资源**。 并不会有原文中说的： > 对于动态分配的资源，其地址、句柄或描述符等标志性信息不可被遗失，否则资源无法被访问也无法被回收，这种问题称为“***资源泄漏***”，会导致资源耗尽或死锁等问题，使程序无法正常运行。 之类的问题。 或许是标题中的 “不可失去对已分配资源的控制”，中没有明确是“***谁***”失去了对资源的控制？ 线程 `detach()` 之后，我们的确失去了对此线程的控制，之后的合法性由 `OS` 保证，这或许不是什么问题。 当然，我不是推崇 `detach()`，它本身也有不少问题，[如](https://github.com/Mq-b/Loser-HomeWork/issues/190)。 --- 总而言之，或许我觉得此规则可以增加一些描述，明确是“谁”失去了资源的控制，或者即使失去，如果有保证正确，也无所谓。
原文： >应改为： >```cpp >namespace U { > const float PI = 3.14F; // Compliant >} > >namespace V { > const long double PI = 3.14159L; // Compliant >} ---...