недостатки указателя void в C++ [закрыт]
Насколько мне известно, указатель void в C++ void* может указывать на что угодно. Это может быть весьма полезно (для меня), если я хочу разработать решение без использования какого-либо наследования. Но вопрос, который я хочу знать, заключается в том, есть ли какие-либо недостатки в этом подходе?
7 ответов:
Самый большой недостаток заключается в том, что использование указателей void не позволяет компилятору принудительно применять проверку типов. Особенно в языке, который поддерживает объектно-ориентированные принципы, я думаю, что было бы странно интенсивно использовать пустые указатели.
Вы, скорее всего, найдете пустые указатели в C, чтобы имитировать некоторое полиморфное поведение, но существуют те же проблемы безопасности типов.
Есть два серьезных недостатка производительности
void*. То во-первых, это делает его гораздо более трудным для понимания и поддерживать программу, которая оказывает серьезное влияние на выполнение содержания программистами-и на время выполнения, так как это затрудняет переработку программного обеспечения когда профилировщик показывает, где у вас проблемы с производительностью. Самые быстрые программы-это те, которые хорошо написаны первыми, поскольку тогда становится возможным производить локальные оптимизации в решающее значение места без необходимости переписывать все целиком программа.Второе влияние на производительность заключается в том, что
void*может псевдоним что-нибудь. Правильный анализ сглаживания является важной частью оптимизация компилятора, и все, что вы делаете, чтобы сделать это более трудность затрудняет оптимизатор и может привести к замедлению кода. (char*иunsigned char*имеют сходный эффект.)
Нет никакого недостатка производительности при использовании
void*, кроме того, что компилятор не может делать предположения о типе, на который он указывает. Это по-прежнему указатель, как и любой другой.A
void*был полезен в C для указания на любой произвольный тип, потому что любой указатель на тип объекта может быть преобразован в Avoid*. Однако делать с ним практически все, что угодно, приведет к неопределенному поведению. Вы можете только безопасно вернуть его к исходному типу указателя.Однако в C++ мы имеем гораздо лучший способ хранения указателя на некоторый произвольный тип-шаблоны. Для некоторого аргумента шаблона
Tмы можем иметьT*.
Все еще могут существовать платформы, где
void*больше, чем другие типы указателей, или имеют другой формат, поэтому приведение к или изvoid*превращается в фактический код преобразования. На обычном оборудовании (x86, ARM) это не так, поэтому проблем с производительностьюvoid*Нет-вы просто отказываетесь от безопасности типов.
Да-у вас могут быть некоторые недостатки производительности. Используя
void *, Вы можете отключить оптимизацию, основанную на предположении строгого сглаживания.Пример
void fun(void * param1, int & param2) { param2 = 7; // 1 // do something with param1, param2 not used param2 += 1; // 2 }Если бы не было переменной
void *, компилятор мог бы удалить присваивание 1 и во 2 просто сгенерироватьparam2 = 8. Но теперь это невозможно, потому чтоparam1может указывать наparam2, Если вы назвалиfun(&i, i).
void*может указывать на что угодно. Это может быть весьма полезно (для меня), если я хочу разработать решение без использования какого-либо наследованияЕсли вы думаете о передаче указателя
void*на какую-либо функцию, подумайте уже о том, как он будет использоваться. Чтобы вызвать метод для этого объекта или получить доступ к его членам, необходимо знать тип этого объекта в любом случае.Используйте
void*только в том случае, если это действительно необходимо. Если вы ищете способ, как обращаться с объектами в более общий способ, а затем просто перейти на правильный дизайн ОО. Когда у вас есть указательvoid*, единственное, что вы знаете, это то, что "есть что-то по этому адресу в памяти", и ничего больше.Производительность использования указателей
void*такая же, как и для любых других указателей. безопасность, понятность , а также связанная с ней расширяемость и ремонтопригодность вашего кода должны быть вашими проблемами.