C ++: POD плюсы \ минусы - PullRequest
Новая
       1

C ++: POD плюсы \ минусы

11 голосов
/ 24 декабря 2010
  • Каковы плюсы и минусы использования Plain Old Data (POD) структур \ классов в C ++ ?
  • В каких случаях следует отдавать предпочтениеиспользовать их над не-POD?
  • В частности, имеют ли POD преимущества при работе со средами сериализации?Возможно при работе кроссплатформенный и кросс-языковой?

Ответы [ 4 ]

6 голосов
/ 15 октября 2011

Если у вас есть несколько миллиардов небольших объектов, обеспечение того, что эти объекты являются POD, может быть огромным преимуществом.

  1. Вы можете вызывать из них значительную часть вызовов calloc () или malloc (), что экономит вам миллионы обращений к конструкторам.
  2. Для сохранения, а не для потоковой передачи объектов по одному, вы можете использовать fwrite () и fread () весь их кусок для скорости.

Недостаток в том, что вы должны сохранять гибкость, чтобы обрабатывать не-ООП POD в вашем коде. POD - это запасной вариант старого кода C, где вы знаете и заботитесь о расположении ваших данных. Когда этот макет четко определен, вы можете оптимизировать его, работая с большими кусками памяти, а не с множеством маленьких кусочков.

Обратите внимание, что то, что я описал выше, относится к тривиально выложенным конструкциям. Другими словами, если вы вызовете std :: is_trivially_copyable () type_trait для этого типа, вы получите true. Требования к POD на самом деле даже сильнее, чем к тривиально копируемым структурам. Итак, то, что я только что описал выше, относится ко всем POD и даже к некоторым не POD, которые оказываются тривиально копируемыми.

6 голосов
/ 24 декабря 2010

Существует одно преимущество POD в сочетании с константами.

Если вы объявляете / определяете константу и используете для нее тип POD, весь POD помещается в раздел данных (констант) исполняемого файла./ library и доступен после загрузки.

Если вы используете не POD, конструктор должен запускаться для его инициализации.Поскольку порядок запуска конструкторов статических классов в C ++ не определен, вы не можете получить доступ к статическому A из конструктора статического B или любого кода, который вызывается из конструктора статического B.

Поэтому использование POD в этом случае безопасно.

3 голосов
/ 24 декабря 2010

POD могут использоваться в интерфейсах C, что означает, что вы можете иметь библиотеку, написанную на C ++, но с интерфейсом C, что может быть полезным.

Недостатком является то, что вы не можете использовать конструктор, чтобы наложить бремя инициализации на сам тип - об этом должен позаботиться пользовательский код.

0 голосов
/ 24 декабря 2010
Стручки

имеют небольшое преимущество. Я не знаю какой-либо портативный способ для расчета требуемого объема памяти для оператора new [], если элементы массива не являются pod, поэтому трудно безопасно использовать оператор new [] для такого массива. Если структура nonpod имеет деструктор, new [] требуется дополнительное пространство для хранения размера массива, но этот дополнительный размер зависит от реализации (хотя обычно это sizeof (size_t) + (возможно) некоторый отступ для обеспечения правильного выравнивания)

...