Комментарии 38
nullptr — это то, чего так долго всем не хватало :)
P.S. В Boost не шарю пока что… Узнал вот только что про lexical_cast. Прикольная штука :)
P.S. В Boost не шарю пока что… Узнал вот только что про lexical_cast. Прикольная штука :)
и чем не хватало? лишних 7 символов печатать, а суть никак не изменилась
Во-первых, не семь. Во-вторых, более строгая проверка типов — раз; стандарт для обозначения нулевых указателей — два (а то пишут… кто 0, кто NULL, а кто-то вообще MY_OWN_SUPERMEGAMACROS_4_NULL_POINTERS).
Интересно, за что минус =)))
А вы уверены, что NULL != nullptr? Если это не так, тогда все ваши выгоды выеденного яйца не стоят. Кроме того, чем вам 0 не нравится? Вполне ясно, что указатель неправильный, не вижу разницы между !ptr и ptr == nullptr, к тому же первое еще и явно нагляднее.
Тем что 0 имеет тип int, только и всего.
Значение указателя — это адрес, который так же имеет тип int, что не так?
И все же, указатель — это не просто int… Не всегда удобно интерпретировать его как простое целочисленное значение.
Блин, а что же это еще, если не int? А как же его еще можно интерпретировать, если не int?
Даже учитывая комментарий ниже, всё равно это int, в любом случае.
P.S. «Не просто int» — это нечто.
Даже учитывая комментарий ниже, всё равно это int, в любом случае.
P.S. «Не просто int» — это нечто.
К указателям удобно применять арифметику указателей, а не арифметику интов:
Если я прибавляю к указателю на начало массива еденицу, то я сдвигаю указатель на размер элемента массива, а не на еденицу.
Если я прибавляю к указателю на начало массива еденицу, то я сдвигаю указатель на размер элемента массива, а не на еденицу.
Ну и что? Ну а что от этого меняется? Только лишь характер операций? От этого указатель не перестаёт быть int-ом.
Кроме того, возвращаясь к теме выше, даже учитывая специфику операций, чем вам мешает 0? От того, что я присвою 0 указателю нарушится механика операций? Или 0 не является адресом? Да всё равно тот же nullptr будет тем же 0-ём, какая разница?
Кроме того, возвращаясь к теме выше, даже учитывая специфику операций, чем вам мешает 0? От того, что я присвою 0 указателю нарушится механика операций? Или 0 не является адресом? Да всё равно тот же nullptr будет тем же 0-ём, какая разница?
А в x64, а сегменты, а различные платформы,…
НЛО прилетело и опубликовало эту надпись здесь
Логически NULL — это не адрес, а его отсутствие :) Указатель указывает в никуда (или, точнее, никуда не указывает), а не на нулевой байт. Просто так сложилось что обращаться по нулевому адресу нельзя нельзя, вот NULL и равен 0, а вот если бы мы могли использовать все пространство памяти…
изменилось, теперь не будет ошибок с присвоением NULL'а обычной переменной, nullptr можно будет присовить только указателю.
Буст вообще вся прикольная штука. Но только для шарящих, а то такого можно наверетенить.
А почему не null?
насколько я понял из текущего доступного драфта, это так и не починили:
struct A{
int a[3];
A(): a({1,2,3}){};
};
<pre>Спасибо, большое! Жду когда же допилят gcc, чтобы использовать на полную мощь.
Отлично, автор пиши больше про новый стандарт. За основу можешь взять эту ветку: forum.sources.ru/index.php?showtopic=190375
Там много букв, так что самая выжимка не помешает.
Там много букв, так что самая выжимка не помешает.
Полезные изменения, хотя новые действия с фигурными скобками запутывают.
int x1 = {7.3}; //Ошибка приведения типов - и ошибка компиляции
double d = 7;
int x2 {d}; //И снова нельзя, произойдет ошибка
char x3{7}; //Все нормально
vector<int> vi = { 1, 2.3, 4, 5.6 }; //Не получится, так как нет соответствия
Разьясните, а зачем нужно так писать? Чтобы специально получить ошибку компиляции? А если не хочешь получить, писать по старому? :-)
Странное какое-то решение… Если бы такая более строгая типизация вводилась принудительно в весь язык, то было бы понятно, а так ведь все просто будут писать по-старому (хотя бы для совместимости).
Если я всё верно понял.
поддерживаю, надеюсь разработчики компиляторов сделают опцию что по умолчанию будет считаться что со скобками написано.
Как раз, скорее, старый вариант оставили для совместимости, а писать начнут по-новому… Ну, естественно, не в тех проектах, которые по 20 лет уже пишутся.
К примеру использовать фигурные скобки можно при создании собственной библиотеки шаблонов, а при последующем использовании этих шаблонов, часто встречаются ситуации, когда тип подставляется на этапе компиляции. Так, чтобы не произошло необоснованного преобразования типов — такое как раз и подойдёт.
П.С. Ошибка замеченная на этапе компиляции — это в некотором смысле хорошая ошибка :)
П.С. Ошибка замеченная на этапе компиляции — это в некотором смысле хорошая ошибка :)
В C++ когда-нибудь модули будут? Или так и дальше всё инклудами?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С++0x и решение проблем инициализации