Я не мог найти темы, дающие четкий ответ на этот вопрос -
у меня есть конструктор, например:
FanBookPost::FanBookPost(Fan* owner, std::string content);
Fan — это еще один класс в моем коде, но проблематичным является контент:
поскольку std::string не является указателем, я ожидаю, что вызов конструктора с помощью (fan, nullptr) будет невозможен. однако он компилируется! ... и вылетает во время выполнения с EXC_BAD_ACCESS.
этого можно избежать?
FanBookPost::FanBookPost(Fan* owner, std::string &content);
- person smac89   schedule 22.01.2014const char *
, которая пересылает, если не является нулевой. - person chris   schedule 22.01.2014std::string
, это не проблема вашего кода. - person Sebastian Hoffmann   schedule 22.01.2014std::nullptr_t
. Константы ненулевого указателя не будут выбирать эту перегрузку. - person dyp   schedule 22.01.2014char
или другой. Единственная проблема в том, что конструкторstd::string
не принимает его. - person   schedule 22.01.2014char *c = 0; FanBookPost fbp(..., c);
или дажеFanBookPost fbp(..., 0);
. - person   schedule 22.01.2014char*
будет интерпретироваться как строка и должно указывать на массив с нулевым завершением). - person dyp   schedule 22.01.20140
— это константа нулевого указателя. - person dyp   schedule 22.01.20140
не относится к типуnullptr_t
. - person Mark B   schedule 22.01.2014nullptr_t
является стандартным преобразованием, тогда как преобразование вstring
является преобразованием, определяемым пользователем. Стандартное преобразование лучше, поэтому перегрузкаnullptr_t
предпочтительнее. - person dyp   schedule 22.01.2014char *
, являющийся нулевым, гораздо менее явно ошибочен, чем передачаnullptr
дословно. Приоритет перегрузки RE: Интересно, спасибо за указание! - person   schedule 22.01.2014char*
, я думаю (по крайней мере, более) разумно предположить, что она должна быть действительной. - person dyp   schedule 22.01.2014char *
имеют более высокую (а именно › 0%) вероятность того, что они не будут нулевыми, но когда они равны нулю, гораздо сложнее определить, как и почему. Кроме того, учитывая, что многие люди (включая меня) очень склонны кодировать для счастливого случая, игнорируя возможность того, что указатели будут нулевыми, если это не суют им в лицо, видяf(c_str)
, они не будут проверять, принимает ли (1)f
значение null или ( 2)c_str
не может быть нулевым. Напротив,f(nullptr)
затрудняет игнорирование возможности нулевого указателя. - person   schedule 22.01.2014f(nullptr)
, я более склонен предполагать, чтоf
может обрабатывать нулевые указатели, чем когда я вижу, что это не удается, но компилируется (только)f(c)
. Конечно, проверка нулевых указателей разумна и полезна в интерфейсе (в основном, когда вы не хотите полагаться на то, что пользователь интерфейса сохранит гарантию отсутствия nullptr). - person dyp   schedule 22.01.2014