Поведение оператора new платфоромозависимое?

В случае неудачи оператора new, допустим out of memory, он может кинуть исключение или вернуть ноль:
MSDN:

If unsuccessful, new returns zero or throws an exception

Подскажите, а это поведение так сказать платформ депендет или на всех платформах по дефолту он ведёт себя одинаково. Это же поведение можно поменять ?

0

Сообщение от KOPOJI есть set_new_handler

И тут на сцену выходит геморой отлавливания инфы, откуда, с какой строчки кода, в какой процедуре, из какого объекта и тд это исключение дропнулось ... Инфа нужна для лога и для необходимых действий

0

Сообщение от CheshireCat Хе-хе. Мы ж находимся в контексте форума по C++, не так ли?

Так ото ж. NULL - это сугубо сишный причендал, и в C++ не используется. Для обозначения нулевого указателя раньше использовался 0, теперь nullptr.

1

Сообщение от Mr.X Для обозначения нулевого указателя раньше использовался 0,

NULL использовался, и не как тех.реализация а как наглядность для человека.

0

Сообщение от Avazart NULL использовался, и не как тех.реализация а как наглядность для человека.

Ну, это только теми, кто Страуструпа не читал или не уважает. Ибо старичок очень не рекомендует.

0

Ну а Дьюхерст вроде рекомендует и я с ним согласен, ибо вероятность что где то-там NULL будет как то не так определен - мала. А вот ошибиться указатель/не указатель легче.

0

Сообщение от Mr.X Ну, это только теми, кто Страуструпа не читал или не уважает. Ибо старичок очень не рекомендует.

Старичок Страуструп, конечно же, человек заслуженный.... Но все же для меня истина в последней инстанции - это текст Стандарта. Ага, 18.2 в последней редакции, или же 18.1 в предыдущей.

0

Сообщение от Avazart Ну а Дьюхерст вроде рекомендует и я с ним согласен

Заглянувши в Дьюхерста, увидел там следующее:
"Тем не менее, настоящие программисты на C++ по-прежнему представляют нулевой указатель литералом 0. Применяя любой другой способ, вы рискуете показаться безнадежно старомодным."

0

Хз, значит в другой книге видел.

0

Сообщение от CheshireCat 18.2 в последней редакции, или же 18.1 в предыдущей.

Ага. Там как раз есть интересная сноска:
в 18.3.2.2

197) Possible definitions include 0 and 0L, but not (void*)0.

и еще вот такая в 8.5

107) As specified in 4.10, converting an integer literal whose value is 0 to a pointer type results in a null pointer value.

А вот конкретно про оператор new:
18.6.1.1

Default behavior: Calls operator new(size). If the call returns normally, returns the result of that call. Otherwise, returns a null pointer. [Example: T* p1 = new T; // throws bad_alloc if it fails T* p2 = new(nothrow) T; // returns 0 if it fails —end example ]

Битовое же представление указателя вообще не обязано даже выражаться одним числом, не говоря уже про конкретно нулевое значение null pointer.
Стандартом гарантируется, что компилятор знает как преобразовать 0 в правильный null pointer, этого достаточно, чтобы без опаски использовать его (0). Так что слова Страуструпа ни в коем случае не расходятся со стандартом и с реальным положением вещей.

PS. Да, я работал с платформами, где null pointer имеет не равное числовому нулю битовое представление, и в С++ ноль приведенный к указателю принимал правильное значение.
Все вышесказанное относится к С++. В С действительно нужен NULL.

В заключение приведу кусочек GNU libio.h
Добавлено через 1 час 7 минут

Сообщение от Scrooge McDuck Ну на счёт предпочтения понял, но всё же, практический выхлоп то от него какой?

nullptr позволяет типизировать null pointer, в С++03 и С++98 использование нуля вот в таком
контексте приводило к не всегда ожидаемому эффекту (вызовется перегрузка с int, т.к. она не требует конверсии, если требовалось иное, то приходилось использовать явное приведение).

А уже вот в таком примере мы бы получили ошибку компиляции:
Кстати, если бы NULL был определен как ((void*)0), то вот на таком примере мы бы тоже получили ошибку компиляции, хотя, очевидно, по смыслу ее здесь быть не должно.
В С++11/14, используя nullptr вместо ноля, мы сможем гарантировать отсутствие таких коллизий.

0

Сообщение от DrOffset А уже вот в таком примере мы бы получили ошибку компиляции: void a(long x); void a(int * x); //..... a(0); // выбор между а(long) и a(int *) приводит к ошибке компиляции

Честно говоря, я не не первый день знаком с С++ , но никогда не любил перегруженных функций и шаблонные классы ( template class и т.д.), нет, конечно STL то я уважаю, но этого и хватает. Хотя теперь мне и Qt хватает и ни на что другое я вряд ли пересяду, хотя всегда считал WinAPI наиболее качественным и профессиональным средством разработки, правда чисто под windows. Ну это я всё к тому, что мне всякие там выборы компилятором перегруженных функций, когда передаёшь туда ноль, как то по барабану. И можете даже не смеяться по поводу моего не желания использовать перегруженные функции (конечно же иногда я их использую), программирование - такая штука, где можно лет 50 чему то учится, а потом придёт пацан и скажет, что ты всё делаешь не правильно но ты уже ничего не будешь менять и скажешь ему "я слишком стар, чтоб что - то менять, я так уже привык" .

Сообщение от DrOffset В С++11/14, используя nullptr вместо ноля, мы сможем гарантировать отсутствие таких коллизий.

вообще nullptr я с выходом C++11 сразу стал везде задействовать, может это связанно с тем, что на Qt я перешёл уже во времена C++11, до этого всё время программировал в WinApi, а там был всегда NULL (по этому я и думал, что он оттуда).
Тут то я спрашивал про nullptr_t - который по моему мнению вряд ли где - то находит серьёзное применение , нет ну правда, это же тип нуля, а какой в нём только - то ? Ну вот просто пример void Hello(std::nullptr_t);, ну и что? Накой хрен писать процедуру, которая может принимать параметр только ноль? Я проще напишу void Hello(int a); и буду проверять его на ноль

0

Введение типа std::nullptr_t нужно для того, чтобы при наличии таких перегрузок:
можно было вызвать именно версию с указателем (а не с целым), передавая "нулевой указатель":
Т.о. суть введения типа std::nullptr_t не в том, чтобы писать перегруженные функции, которые принимают этот тип, а чтобы вызывалась версия, принимающая указатель, а не целое.
Достигается это тем, что тип nullptr_t (когда передается объект nullptr) может быть неявно преобразован в любой указатель, но не в целое.

0

Сообщение от Scrooge McDuck Честно говоря, я не не первый день знаком с С++ , но никогда не любил перегруженных функций и шаблонные классы ( template class и т.д.), нет, конечно STL то я уважаю, но этого и хватает. Хотя теперь мне и Qt хватает и ни на что другое я вряд ли пересяду, хотя всегда считал WinAPI наиболее качественным и профессиональным средством разработки, правда чисто под windows. Ну это я всё к тому, что мне всякие там выборы компилятором перегруженных функций, когда передаёшь туда ноль, как то по барабану. И можете даже не смеяться по поводу моего не желания использовать перегруженные функции (конечно же иногда я их использую), программирование - такая штука, где можно лет 50 чему то учится, а потом придёт пацан и скажет, что ты всё делаешь не правильно но ты уже ничего не будешь менять и скажешь ему "я слишком стар, чтоб что - то менять, я так уже привык" .

Весь этот пассаж есть следствие того, что ты не понял, о чем я говорил. Вот Tulosba еще раз обозначил эту мысль (спасибо ему). Других веских причин для введения nullptr с собственным типом - нет. Все мои примеры с перегрузками были иллюстрацией этой проблемы (проблемы нетипизированного нулевого указателя), никаких других смыслов в эти примеры я не вкладывал.
И поверь, мне абсолютно по барабану используешь ты перегруженные функции или нет

0

Сообщение от DrOffset Других веских причин для введения nullptr с собственным типом - нет.

Ну как это нет? Вот еще два:
1)
Я смотрю на этот код и не понимаю, что возвращает функция.
А так понимаю.

2) Вывод типов шаблонов работает неверно для 0 и для NULL. Выводится, ну например, int. А для nullptr верно - выводится nullptr_t.

Например. Я хочу написать функцию, которая вначале что-то лочит, а потом вызывает другую функцию, передавая ей указатель на данные. Будет это выглядеть как-то так:
И есть у меня скажем вот такие функции, которые я хочу туда передавать:
Тогда следующие вызовы будут выдавать ошибки компиляции:
Потому что PtrType будет выведен, к примеру, типу int, а неявного преобразования из int в те указатели нету.

В то же время со следующим вызовом все окей:
PtrType будет nullptr_t, а для nullptr_t определены неявные преобразования во все вышеперечисленные типы указателей.

2

Сообщение от ct0r auto result = SomeComplexFunction();

Я сейчас выражу свое собственное мнение. Auto чрезвычайно вредная вещь в неопытных руках и использовать ее надо с большой осторожностью. В частности, ИМХО, вот этот пример, с возвратом указателя замаскированным auto - пример неудачного использования. Хотя с сутью я согласен, показать что производится сравнение именно с указателем - хороший case.

Вообще же, ты слишком буквально понял мой пост, все твои примеры, собственно, того же разлива, что и и мои примеры в перегрузкой (я просто не стал это разжевывать - выходит зря).
Все это в итоге достигается введением конверсии из nullptr_t -> some ptr type, вместо прежней int -> some ptr type. Все примеры (и твои и мои) - это лишь демонстрация этого эффекта и показывают, суть, эту конверсию. Именно это я и имел в виду под

Сообщение от DrOffset Других веских причин для введения nullptr с собственным типом - нет

, а не конкретно перегрузки.

Добавлено через 3 минуты
Скажем так, читать это надо было так:

Сообщение от Tulosba тип nullptr_t (когда передается объект nullptr) может быть неявно преобразован в любой указатель, но не в целое.

Сообщение от DrOffset Других веских причин для введения nullptr с собственным типом - нет.

0

Сообщение от DrOffset Вообще же, ты слишком буквально понял мой пост, все твои примеры, собственно, того же разлива, что и и мои примеры в перегрузкой (я просто не стал это разжевывать - выходит зря).

По сути да, но контексты немного разные. Тогда скажем так: я показал практический пример, где фигня с int и nullptr_t происходит не только с перегрузкой функций.

0

0

0

Сообщение от ct0r Я смотрю на этот код и не понимаю, что возвращает функция.

Ну дак имя функции должно сообщать об этом. Если же имена функций будут скрывать, а не прояснять их поведение, то никто ничего не поймет, сколько нульпойнтеров туда ни напихай.

1

По моему вот это бред (в Qt)

0

Scrooge McDuck, intellisense это патентованое от ms, которое работает в студии. Креатор не может, потому что не дорос еще.

0