当我创建共享库时，我在库源的根目录中有一个与库同名的头文件（但没有文件扩展名）。
例如，如果我的库名为 libirock.so，那么我将在项目根目录中有一个名为 irock 的文件。该文件将包含库中所有最重要的头文件，因此当要实现库时，您需要做的就是使用以下包含行：
#include <irock> // Instead of <irock.h>
当我看到类似于以下内容的编译器警告时，我得到了这个想法：
#include <string.h> is obsolete, use #include <string> instead
两个问题：
行动方针
感谢您的回答！根据答案，我决定：
<irock.h>而不是<irock>.一句话，没有。您需要明确使用 irock.h
有了扩展名，很明显这是一个头文件，任何使用基于文件扩展名的文件的应用程序都将正确地知道如何解释你的头文件。
不， <header> 而不是 <header.h> 习语应该仅用于标准库（和标准模板库）标头。
标准中没有关于文件名扩展的“允许”、“禁止”或“最佳实践”。
使用您喜欢的任何形式。在某些平台上，为注册类型提供文件扩展名是一个便利因素。
对于它的价值<string.h>和<string>完全不同的标题。C++ 命名空间等价物<string.h>实际上是<cstring>.
#include 只是将给定文件名的内容放入实际文件中。因此，如果您在没有文件扩展名的情况下感觉更好，那就去做吧。
当然，文件扩展名具有有用的语义含义。此外，在大多数用户心目中，没有扩展名的包含文件与标准库相关联。
Qt4中使用的是，您可以通过“类名”包含文件名，例如
#include <QString>
#include <QWidget>
#include <QPainter>
#include <QApplication>
#include <QCoreApplication>
这些包含是虚拟包含，它将包含正确的标题。在现实生活中，您会看到在单个 include.h 中定义了多个类，并且您将该文件包含了两次。
再次使用不带“.h”的版本的一个原因是，您会很想使用包含 camelCase（或 PascalNotation）的内容，如果您将代码从 windows 移动到 unix（linux 或 mac），您通常会遇到问题。做起来并不难——但你确实需要注意正确地做。