重新学习C ++和typedef问题

时间:2010-08-02 18:15:12

标签: c++ typedef

因此,自从我将C ++用于大型项目以来已经过了5到6年,而且自从我上次处理小型/普通的C ++程序和C ++运行时以来已经有半年了。我已经决定要重新学习这门语言,主要是因为它可能与即将开展的项目非常相关。

我一直主要使用C和Python,而且我现在正处于下面的for循环语法中我不太自在:

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

虽然我承认解密并不难。

因为我知道语言和图书馆以及成语,模式和风格都有很多新增内容,所以我想问一下你对最新资源的看法。我想避免使用“这是带有很多额外内容的C”方法的教程。我仍然有我正在研究的“C ++编程语言”的强制性副本,但老实说我不确切地知道下一步要关注的地方。设计模式?模板和STL / Boost?还有别的吗?

我愿意接受所有建议!

另外,关于typedef的更具体的问题。如下:

typedef Type& TypeRef;

在提供opaque类型作为API的一部分时通常被认为是一种好的做法?这是一个有意义的名字。它是否与 pthreads libpcap 等库所采用的方法类似,如果是,是否更适合使用同一作业的指针?

提前致谢。

3 个答案:

答案 0 :(得分:4)

为了回答你的具体问题,typedef隐藏了一些东西是指针或引用的事实总是一个坏主意 - 在C中也是如此。考虑例如opaque类型FILE - 一个仍然需要显式创建FILE指针以便使用它。

关于图书,请参阅The Definitive C++ Book Guide and List

答案 1 :(得分:3)

我从不喜欢键入参考或指针类型。由于它们对客户端具有不同的调用语义,所以不可能有效地隐藏类型是指针与引用的事实,因此这只会导致我的经验混乱。

答案 2 :(得分:0)

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)当你使用稀疏文字时   为...创建类型        类型检查。

     

(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   明确地符合其中一条规则。

     

通常,指针或结构   有合理的元素   如果从不,请直接访问   一个typedef。