-тся

>учаться

Может сам и ответишь?

учатЬся, конечно...

Научить невозможно.

Научить чему-либо невозможно, можно только научиться. Так что второй вариант.

А что плохого в возврате указателя? Вон, даже библиотечные функции так делают (взять хотя бы тот же strdup, strstr и т.п.). Плюс многие функции, работающие со строками/изображениями и т.п. помимо того, что изменяют указатели в аргументах, еще и возвращают указатель - чтобы легко можно было определить, выделила функция память, или нет.

Это ЛОР, смирись. Самое большое сообщество специалистов по быдло-коду. :)

>А что плохого в возврате указателя?

ничего плохого, это лиспер стебется)

упс. очепятка :). фиксед. правило знаю :) не надо мне его рассказывать ;)

И да, не знаю, чему сейчас учат - я учился сам (K&R, Богатырев и еще какие-то книжки читал).

так он на полном серьезе утверждает :) это то и пугает )

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

if (a) delete a;

и не заморачиваться.

Обычно так и делают - в том же man strdup:

Memory for the new string is obtained with malloc(3), and can be freed with free(3).

И ее обычно так и используют:

char *a = strdup(...);
...
if(a) free(a);

Аааа, malloc возвращает указатель!11 Непонятно надо ли его высвобождать или нет!11 Как дальше жыть...

> Может сам и ответишь?

Для этого требуется реформа русского языка, чтобы и ться писать как хочешь, и звуки ассимилировать.

И то и другое. Пришёл однажды на беседу в софтверную контору на должность Си-шного разраба. Требования заявлены были довольно высокие а я, честно говоря, соответствую далеко не всему. При этом рассказал, без понтов, что я могу, что могу в перспективе, а о чём не имею представления вообще никакого.

Потиху беседа перетекла в неформальное русло и ответственный товарищ стал жаловаться на проблему с кадрами. По его словам есть две основные проблемы. Первая - низкая мотивация студентов профильных вузов. Вторая - устаревшая система образования. Студенту, загруженному коллоквиумами по физкультуре ;-) просто физически не до «втыкания» в промышленное программирование.

>собсно у меня вопрос - это сейчас так преподают или просто так учатся?

Просто население планеты растет усиленными темпами, и количество мозгов в расчете на особь стремительно падает.

> Студенту, загруженному коллоквиумами по физкультуре ;-) просто физически не до «втыкания» в промышленное программирование.
Полностью согласен.

2ТС:

Попроси их сделать это без возврата указателя, интересно будет поглядеть.

Teh drama. Ты бы дочитал до конца, мой милый мим, а не разводил херню из вырванного контекста.

>struct mylib *lib = mylib_open()

С таким подходом основной цирк начнется когда потребуется использовать mylib в многопоточной программе.

Для студентов:
#include «mylib.h»

struct mylib lib;
int myerror;

myerror = mylib_open(&lib,...

Это чему сейчас учат?

Профиту?

>Teh drama. Ты бы дочитал до конца, мой милый мим, а не разводил херню из вырванного контекста.

вот тебе пруф на твой камент.

http://www.linux.org.ru/forum/development/5620342?lastmod=1291036691675#comment-5620769 (комментарий)

и цитата из этого камента.

Далее, нельзя написать в одну строку struct mylib *lib = mylib_open()

И правильно. Потому что так надо писать на высокоуровневых функциональных языках, а не на Си(кстати, возвращать указатель - дико дурной тон, если что).

продолжим? или таки осилишь наконец, что бредятину пишешь?

Совсем дурной? Сличи ники.

не твой камент, сори. просто отвечал тебе, вот и адресанул тебе :).

s/вот тебе пруф на твой камент/ вот тебе пруф на камент/

но суть месаджа не меняет. ты говоришь, что я выдернул из контекста, на что я привел пруф, в котором четко написана та формулировка.

Тогда повторюсь, библиотека не должна выделять память — это задача клиентского кода, но естественно есть случаи, когда такое невыполнимо. Вот моя мысль. Причем здесь возврат указателя? Притом, что ТС хотел выделять память и возвращать его.

>Тогда повторюсь, библиотека не должна выделять память — это задача клиентского кода

ой ли. почитай документацию к Qt, к Gtk, к любой клиентской библиотеке БД. Все они аллоцируют какие-то куски памяти и ты их сам должен освободить с помощью функций, предоставляемых этими библиотеками.

и при том, что ТС все правильно делал, а ты напару с Love5un (или как он там) начали нести несусветный бред. Точнее Love5un начал, а ты продолжил его бредовые начинания, тем самым начали вгонять ТС в голимый бред, чем собственно и справоцировали бурное обсуждение.

Qt

С++, мимо кассы

Gtk

Подсчет ссылок, поэтому понятно почему выделение GObjectов берет на себя библиотека. Но остальные функции, которые должны возвращать структуры, принимают указатель :P.

к любой клиентской библиотеке БД

Три функции, то же мне пример.

А что ты скажешь про винапи?

Подсчет ссылок, поэтому понятно почему выделение GObjectов берет на себя библиотека. Но остальные функции, которые должны возвращать структуры, принимают указатель :P.

открой уже K&R и убей себя об стенупрочитай главу 6.5 «Структуры со ссылками на себя»

А что ты скажешь про винапи?

поделка со странной логикой

а вот и вот тебе примеры из Стивенса, но ты иди изучай винапи дальше

> K&R, Богатырев

К.Ю. Богачев

//fixed

Если библиотека выделяет память, и возвращает указатель на неё; а также это описано в документации к библиотеке, то в чём проблема?

>А что ты скажешь про винапи?

Топить в серной кислоте авторов, а что?

>>еще один клоун

да надоели! что плохого в клоунах??

а что в них хорошего? их же даже дети боятся. я уж не говорю про 100500 фильмов ужасов с ними. и вообще, я не понимаю, чья больная фантазия придумала это.

>>их же даже дети боятся.

Вы так говорите, будто это что плохое(с)

это же ужасно!

поделка со странной логикой

Фанатик

а вот и вот тебе примеры из Стивенса

Оба примера попадают под исключение, сообразишь почему?

Топить в серной кислоте авторов, а что?

Фанатик опять же.

то в чём проблема?

А если я хочу аллоцировать на стеке или в секции данных?

На самом деле возвращать указатели из функций - это кошерно, ибо такие проще потом подцепить через libffi в каком-нибудь более высокоуровневом языке.

А вот освобождать/не освобождать - это уже вопрос к документации

>delete a;

Вот в плюсах уже указатели голые возвращать и не надо.

Студенту, загруженному коллоквиумами по физкультуре ;-) просто физически не до «втыкания» в промышленное программирование.

Бойян, я от безделия с третьего курса работать пошел, чисто потому что исключительно нечего было делать.

кстати тут ++

> а вот и вот тебе примеры из Стивенса

Оба примера попадают под исключение, сообразишь почему?

потому что они не укладываются в твою концепцию, что тут думать :)

> поделка со странной логикой

Фанатик

обоснуй

тенденция сейчас херовая, учат, как возвращать ссылки (и это в С++ то!) и гнобят ручное аллоцирование памяти

тенденция сейчас херовая, учат, как возвращать ссылки (и это в С++ то!)

ну-ка, ну-ка, и что же должен возвращать, к примеру, переопределённый оператор присваивания?

гнобят ручное аллоцирование памяти

ога, особенно при написании собственных аллокаторов и работе со сложными структурами данных

переопределение операторов это само собой разумеется ссылки. я С++ не приветствую, попытка превратить императивный язык в ООП не самое хорошее, что есть в жизни. хотите ссылки - джаба, хотите ручки/память - С

я С++ не приветствую

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

Ну не пользуйся этой функцией из библиотеки а напиши свою. Библиотека она предоставляет определённый функционал, если тебя не устраивает, не пользуйся.

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