>Увы, в данном случае эдакое сообщение об ошибке придёт слишком поздно.
Ситуация когда можно словить segfault конечно возможна, но это не отменяет необходимость проверки потому как возможна и ситуация когда malloc вернет NULL. Таких как Alphex кучи и они ничерта не проверяют, выделилась ли память, открылся ли файл, прочитался ли файл, записался ли файл и тд и тп. Эти кодеришки рождают тонны глюкалового кода и имеют наглость называть себя программистами. Ты посмотри его код над которым весь LOR ржал и рыдал. Ладно бы код был дерьмовым но он сремился бы писать лучше, так он упирается как баран и непризнает вообще никаких ошибок.

Да нет уж, если проверять, то не только на NULL, а ещё и записью чего либо во всю выделенную область.

Иначе такие проверки - всё равно, что от комаров зажигалкой отмахиваться - может кого и пожжешь, но всё равно зажрут, и в клоуны запишут...

2anonymous (*) (04.04.2005 14:48:35)

идиотик - хватит свою желчь тут выказывать - я проверяю;

и тут разговор о конкретном случае и уж как ты со "стандартом" опустился вот это должно быть смешно;

если честно, ты уже запарил со своим malloc(0).
Такое ощущение, что просто убийственный аргумент в пользу того,
что malloc не надо проверять на NULL. 

Я поделюсь с тобой одним примером, выстраданным после многих лет
работы в моделировании нейросетей и моделировании погодных условий:

unsigned char* getNewMemory(const int &sz)
{
  if(!sz)
     return NULL;

  unsinged char *b = (unsinged char *)malloc(sz);

  if(!b)
      return NULL;

  return b;
}

-------------------------------

Только тсссс! Это очень секретная разработка.

>если честно, ты уже запарил со своим malloc(0).

это такие как ты уже достали, я не говорю что _НЕНУЖНО_ я говорю что в некоторых случаях _НЕОПРАВДАННО_.

твой пример - ну и что? это все что ты можешь показать ?

программировать ты точно не умеешь
идиотский пример :
1)
>if(!b)
> return NULL;
>
> return b;

можно было заменить на просто

return b;

а
unsigned char* getNewMemory(const int &sz)

на

unsigned char* getNewMemory(const int sz)

потому что при
>const int &sz
передается на самом деле указатель,
т.е. в принципе может использоваться больше памяти в стеке
чем для int, потом будет неявно использоваться каждый раз
указатель, что медленее чем использовать просто значение,

т.е. тебе прежде чем кому-нибудь что-нибудь советовать надо
самому научиться программировать.

Ржу - не могу!

Keiko, классный анекдот, ты его сам придумал или подсмотрел где?

>моделировании нейросетей и моделировании погодных условий

ты хотя бы научись программировать, а то моделировиние сетй...

сранная статья. Пишет непрофессинал, который по-видимому
никогда не программировал ни на GTK/GDK, ни на Qt.
В "История Gtk" не упомянуты Owen Taylor - автор
xdnd, xembedded, очень активный человек в команде GTK
(btw работающий в RedHat - именно поэтому RedHat лоббирует GTK)
Другой человек - Tor Lillqvist -- win32 port.
Почему-то ничего не сказано про "историю Qt"?

вообщем статья из серии "слышал звон, но не знаю где он" ...
конспектирование конспекта.

owen taylor

> очень активный человек в команде GTK

поправка - Owen is the project leader of the GTK+
http://www.osnews.com/story.php?news_id=5453

>>можно было заменить на просто да хоть меняй, хоть не меняй, суть от этого не поменяется. Пример хоть и ламерский, но альфексу сойдёт для malloc(0). P.S. люблю таких как ты :) Всега придираются к мелочам. Типа не там запятую поставил и т.д. :) Сам-то ты небось в университет преподаёшь ? :)

>>можно было заменить на просто

да хоть меняй, хоть не меняй, суть от этого не поменяется. Пример хоть и ламерский, но альфексу сойдёт для malloc(0).

P.S. люблю таких как ты :) Всега придираются к мелочам. Типа не там запятую поставил и т.д. :) Сам-то ты небось в университете преподаёшь ? :)

разобрался.
этот Арсений Чеботарев перевел
"Other credits" from http://www.gtk.org/people.html,
kak "История Gtk" выкинув из GTK главных разработчиков.

Это ли не пример безграмотности?

Арсений Чеботарев

http://www.google.ru/search?hl=en&q=%D0%90%D1%80%D1%81%D0%B5%D0%BD%D0%B8%...

плодовит, однако