Политика typedef, принятая ядром Linux для C, является лучшей.По сути, политика заключается в том, чтобы не использовать typedefs, если вы не создаете абстракцию нового типа.Это полезно в тех случаях, когда низкоуровневые типы различаются в разных архитектурах, но пользователям ядра нужен общий тип.Например, u64 задается конкретный тип, но базовый тип может меняться между сборками или архитектурами.
Однако, весьма вероятно, что в C ++ существуют разные идиомы, использующие typedefsэто вполне приемлемо, однако, я бы освоился с C до C ++.
Возможно, лучший способ переориентироваться на C ++ - это написать разовые программы, которые выполняют определенную функцию.Например, написать шаблон, использовать библиотеку в Boost, создать несколько потоков, выделить немного памяти.Суть не в том, чтобы изучить все эти вещи, а в том, чтобы увидеть и убедиться, что вы не будете задыхаться, когда наступит время показа.
Chapter 5: Typedefs
Пожалуйста, не используйте такие вещи, как "vps_t".
Это ошибка использовать typedef дляструктуры и указатели.Когда вы видите
vps_t a;
в источнике, что это значит?
В отличие от этого, если оно говорит
struct virtual_container * a;
на самом деле вы можете сказать, что такое "a".
Многие думают, что typedefs "помогают читабельности".Не так.Они полезны только для:
(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) когда вы используете sparse для буквального создания нового типа для проверки типов.
(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.