重新学习 C++ 和 typedef 问题

Question

所以，自从我将 C++ 用于大型项目已经有 5 或 6 年了，而我上次不得不处理小型/琐碎的 C++ 程序和一般的 C++ 运行时已经有大约半年了。我决定重新学习这门语言，主要是因为它可能与即将到来的工作项目非常相关。

我一直主要使用 C 和 Python，目前我什至对下面的 for 循环语法都感到不自在：

for( int i(0); i != n; ++i) {}

虽然我承认它并不难破译。

由于我了解该语言以及库以及习语、模式和样式有很多新增内容，因此我想就最新的优质资源征求您的意见。我想避免使用“这是带有很多附加功能的 C”方法的教程。我仍然有我正在学习的“C++ 编程语言”的强制性副本，但老实说，我不知道下一步该关注哪里。设计模式？模板和 STL/Boost？还有什么？

我愿意接受所有建议！

还有一个关于typedefs 的更具体的问题。是否如下：

typedef Type& TypeRef;

在提供不透明类型作为 API 的一部分时通常被认为是好的做法？有一个有意义的名字，就是这样。它是否与 pthreads 或 libpcap 等库所采用的方法完全相似，如果是，是否比对同一作业使用指针更可取？

提前致谢。

Answer 1

要回答您的具体问题，隐藏某物是指针或引用这一事实的 typedef 总是一个坏主意 - 在 C 中也是如此。例如考虑不透明类型 FILE - 仍然必须显式创建 FILE指针以便使用它。

书籍见The Definitive C++ Book Guide and List。

Answer 2

我从不喜欢对引用或指针类型进行类型定义。无法有效地隐藏类型是指针与引用的事实，因为它们对客户端具有不同的调用语义，所以这只会导致我的经验混乱。

Answer 3

Linux 内核对 C 采取的 typedef 策略是最好的。本质上，策略是不使用 typedef，除非您正在创建新的类型抽象。这在架构之间的低级类型不同但内核用户想要一个通用类型的情况下很有用。例如 u64 被赋予特定类型，但底层类型可能会在构建或架构之间发生变化。

typedef u64 unsigned long long;

但是，在 C++ 中很可能有不同的习惯用法使用完全可以接受的 typedef，但是，我会在 C++ 之前对 C 感到满意。

也许用 C++ 重新定位的最佳方法是编写可能一次性使用特定功能的程序。例如，编写一个模板，在 Boost 中使用一个库，创建一些线程，分配一些内存。重点不是要学习所有这些东西，重点是要看到它，这样你就不会在稍后放映时大口喘气。

这里是 Linux 内核 typedef 标准，取自 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=blob_plain;f=Documentation/CodingStyle;hb=HEAD

  Chapter 5: Typedefs

请不要使用“vps_t”之类的东西。

使用 typedef 是一个错误 结构和指针。当你看到 一个

vps_t a;

在源码中是什么意思？

相反，如果它说

struct virtual_container *a;

您实际上可以分辨出“a”是什么。

很多人认为 typedef “帮助可读性”。不是这样。他们是 仅适用于：

(a) 完全不透明的物体（其中 typedef 被积极地用于隐藏 对象是什么）。

 Example: "pte_t" etc. opaque objects that you can only access using
 the proper accessor functions.

 NOTE! Opaqueness and "accessor functions" are not good in themselves.
 The reason we have them for things like pte_t etc. is that there
 really is absolutely _zero_ portably accessible information there.

(b) 清除整数类型，其中 抽象帮助避免混淆 无论是“int”还是“long”。

 u8/u16/u32 are perfectly fine typedefs, although they fit into
 category (d) better than here.

 NOTE! Again - there needs to be a _reason_ for this. If something is
 "unsigned long", then there's no reason to do

typedef unsigned long myflags_t;

 but if there is a clear reason for why it under certain circumstances
 might be an "unsigned int" and under other configurations might be
 "unsigned long", then by all means go ahead and use a typedef.

(c) 当你从字面上使用稀疏 创建一个 new 类型 类型检查。

(d) 与 标准 C99 类型，在某些 特殊情况。

 Although it would only take a short amount of time for the eyes and
 brain to become accustomed to the standard types like 'uint32_t',
 some people object to their use anyway.

 Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
 signed equivalents which are identical to standard types are
 permitted -- although they are not mandatory in new code of your
 own.

 When editing existing code which already uses one or the other set
 of types, you should conform to the existing choices in that code.

(e) 可以在用户空间中安全使用的类型。

 In certain structures which are visible to userspace, we cannot
 require C99 types and cannot use the 'u32' form above. Thus, we
 use __u32 and similar types in all structures which are shared
 with userspace.

也许还有其他情况，但是 规则基本上应该是从不 除非可以，否则永远使用 typedef 明显符合这些规则之一。

一般来说，指针或结构 具有合理的元素 应该从不直接访问 类型定义。