Есть ли способ проверить, имеет ли класс C ++ конструктор по умолчанию (кроме предоставленных компилятором черт типа)?
Я получил это, чтобы работать. вам просто нужно изменить переменные
$query ="SELECT `column_name` FROM `information_schema`.`columns` WHERE `table_schema`='" . $_SESSION['db'] . "' AND `table_name`='" . $table . "' ";
$stmt = $dbh->prepare($query);
$stmt->execute();
$columns = $stmt->fetchAll(PDO::FETCH_ASSOC);
$query="SELECT name FROM `" . $database . "`.`" . $table . "` WHERE ( ";
foreach ( $columns as $column ) {
$query .=" CONVERT( `" . $column['column_name'] . "` USING utf8 ) LIKE '%" . $search . "%' OR ";
}
$query = substr($query, 0, -3);
$query .= ")";
echo $query . "<br>";
$stmt=$dbh->prepare($query);
$stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);
echo "<pre>";
print_r ($results );
echo "</pre>";
4 ответа
Извините, что отвечаю на собственный вопрос.
Погуглив, я обнаружил, что фактическая причина, по которой мы не можем проверить, есть ли у класса конструктор или деструктор, заключается в том, что известная техника, используемая для определения наличия члена у класса, основана на получении адреса члена. Но конструкторы и деструкторы не имеют имени, мы не можем взять их адрес.
Если мы не можем взять адрес, я не вижу способа заставить компилятор реагировать на конструктор без непосредственного инстанцирования, но в этом случае не будет обнаружения во время компиляции, а будет ошибка.
Поэтому, отвечая на свой вопрос, я бы сказал, что при нынешних методах обнаружить их невозможно и нужна поддержка компилятора. Но C++ открыл много сюрпризов, и вещи, которые были невозможны в определенное время, оказались возможными при использовании другой техники.
Я надеюсь, что эксперт по языку C++ читает это и сможет дать более ясное объяснение.
В MSDN сказано, что заголовок определяет has_default_constructor и подобные свойства.
Концептуальные черты больше не поддерживаются, но становятся частью черт типа. А в документах has_trivial_constructor и has_trivial_destructor авторы Boost ясно объясняют, что для выполнения этой работы требуется поддержка компилятора.
Предупреждение: некоторые анализы, приведенные ниже, устарели в C ++ 11. В C ++ 11 проверка доступа выполняется до создания экземпляра, и нарушение прав доступа не является ошибкой. Поэтому прилагаемый код может быть более совместимым. Повторно не анализировал.
Я новичок в СФИНАЭ. Сегодня мне пришло в голову поместить тестовое выражение внутри sizeof внутри параметра шаблона в типе аргумента функции.
Согласно N2634 , это не неправильно, но крайне непереносимо. ( РЕДАКТИРОВАТЬ: , похоже, соответствует C ++ 0x FCD.) Он может возвращать только положительный результат или не компилировать в GCC 4.2; GCC 4.5 получил 3 балла из 3 в моих тестовых примерах.
Правила SFINAE были расширены (в данном случае), начиная с C ++ 03 в FCD. Новый §14.8.2 / 8 (выделено мной):
Если подстановка приводит к недопустимому типу или выражению, вывод типа не выполняется. Недопустимый тип или выражение - это тип, который будет неправильно сформирован, если будет записан с использованием подставленных аргументов. Проверка доступа не выполняется как часть процесса замещения. Следовательно, когда вывод завершается успешно, ошибка доступа все еще может возникнуть при создании экземпляра функции. Только недопустимые типы и выражения в непосредственном контексте типа функции и его типов параметров шаблона могут привести к сбою вывода. [Примечание: оценка заменяемых типов и выражений может привести к побочным эффектам, таким как создание экземпляров специализаций шаблонов классов и / или специализаций шаблонов функций, создание неявно определенных функций и т. Д. context »и может привести к неправильному формированию программы.
template< class T >
class is_default_constructible {
template<int x>
class receive_size{};
template< class U >
static int sfinae( receive_size< sizeof U() > * );
template< class U >
static char sfinae( ... );
public:
enum { value = sizeof( sfinae<T>(0) ) == sizeof(int) };
};
class q { q(); };
class r { r(int); };
#include <iostream>
using namespace std;
int main() {
cerr << is_default_constructible<int>::value << endl // outputs 1
// fails to compile: access violation
// FCD demands that access violations be unrecoverable
// indeed, it's murky: q is default-constructible, but only "rarely"
//<< is_default_constructible<q>::value << endl
<< is_default_constructible<r>::value << endl; // outputs 0
}