Вопрос к программистам на C , Исходники ядра Linux

Цитата the_Shadow @ 19.04.06, 15:27

Ну и опиши их все... В чём проблема?

В том, что писать придется методом copy-paste, что в большинстве случаев очень не рекомендуется.

Цитата the_Shadow @ 19.04.06, 15:27

Зачем, если у меня есть возможность создать динамические или статические библиотеки? И использовать их в том же "добром десятке"?

Разные проекты... Разные типы данных... Да. Для стандартных типов я смогу создать библиотеки. А для своих, специфичных для проекта?

Кстати, забыл спросить -- а твой системный аналитик не собирается раз в месяц увеличивать их число? А то... :D:D:D

Добавлено 19.04.06, 15:36

Цитата

В том, что писать придется методом copy-paste, что в большинстве случаев очень не рекомендуется.

На сайте VIM есть примеры "макросов" для автогенерации кода. Забыл линк, но они там есть... Я ни их базе для генерации ПО для PalmOS зафигачил себе мкакросы... И... нормально.
Зачем cut'nd'paste? Мы же в Linux... :D:D:D

Цитата

Да. Для стандартных типов я смогу создать библиотеки. А для своих, специфичных для проекта?

typedef враги, покамест, не отменяли... :D:D:D
Более того! Посмотри на С99 -- там введены и булев тип данных и комплексные числа! Создавай те типы данных, которые нужны (из существующих) и пиши...

Добавлено 19.04.06, 15:44
Да. Продолжу. Если по-пилить по типам данных реализацию, то ты сможешь разнести её по библиотекам и скрыть детали реализации. На что-то это похоже... :D:D:D

Цитата Flex Ferrum @ 19.04.06, 14:12

Нередко встает задача обменять две переменные местами. Бывает? Бывает. Например, в алгоритмах сортировки. Да и не только. Можешь ли ты на С написать такую функцию (или макрос) обмена двух значений, которая максимально эффективно работает со значениями любых типов, для которых ты можешь ее вызвать. В частности, для интегральных типов (обмен через xor), типов, у которых есть своя функция обмена (должен вызвать ее), и для всех остальных типов, для которых используется обмен через третью переменную. В твоем распоряжении - С + препроцессор. В моем - С++.

Я в ответ на такую постановку скажу, что любые попытки прикрутить к императивному языку функциональные элементы всегда выглядят весьма убого и неполноценно. Что там в ваших плюсах придумывают (boost::lambda), чтобы реализовать то, что в функциональных языках доступно по определению?
И нечего меряться пиписьками по поводу того, что круче -- C или C++. Всегда можно поставить такую задачу, что оба эти инструмента шумно сольют, например, lisp'у, что отнють не будет означать, что надо бросать все и переписывать ядро на lisp'е.
И все-таки камень в огород C++ нельзя не бросить: всевозможные перегрузки (особенно по типу результата), конструкторы по умолчанию, перегрузка операторов добавляют кучу мест, в которых можно допустить ошибки, если не быть предельно внимательным. Плох тот инструмент, который заставляет сосредотачиваться не на решении задачи, а на борьбу с недостатками инструмента.

Приходилорсь перекомпилить ядро линукса, gcc очень утомлял, но перекомпилировать ядро винды никто не дает. Даже партийное начальство, хоть и ничего не говорило.

Добавлено 19.04.06, 17:53
Ошибки можно допустить и без перегрузки операторов, те же самые, а еще и больше. Так что не надо. Не хочешь не используй, пиши больше в стиле классического Си.

Перегрузки чего бы то ни было (функций или операторов) только добавляют путаницы, хотя со стороны все смотрится хорошо: одинаковые вызовы для различных типов аргументов.

Цитата linuxfan @ 19.04.06, 17:37

всевозможные перегрузки (особенно по типу результата), конструкторы по умолчанию, перегрузка операторов добавляют кучу мест, в которых можно допустить ошибки, если не быть предельно внимательным. Плох тот инструмент, который заставляет сосредотачиваться не на решении задачи, а на борьбу с недостатками инструмента.

Ты знаешь, а из пистолета можно выстрелить себе в голову. А циркулярной пилой - отрезать пальцы. Наверное, эти инструменты очень плохи? Понятно, что во всем нужна внимательность. А если хочется, чтобы было все сладко и безопасно - добро пожаловать в basic. Там наломать дров можно только если очень постараться.

Цитата linuxfan @ 19.04.06, 17:37

Я в ответ на такую постановку скажу, что любые попытки прикрутить к императивному языку функциональные элементы всегда выглядят весьма убого и неполноценно. Что там в ваших плюсах придумывают (boost::lambda), чтобы реализовать то, что в функциональных языках доступно по определению?

Что-то недопонял я этого пассажа. Постановка проста и ясна - написать обобщенный алгортим. Достаточно простой (реализация - от силы строк 20). Мне тут объясняют, что С + препроцессор - это сила. Согласен, сила. Но, позвольте, чем мне эта сила может помочь в том, что предлагает Шад. А он предлагает сделать несколько реализаций алгоритма, занимающего без малого сотню строк. Очень хороший выход из положения. Не находишь? А какова при этом вероятность допустить ошибку?

Цитата the_Shadow @ 19.04.06, 15:31

typedef враги, покамест, не отменяли...

Ну да. Как он мне может помочь, если в одном случае мне нужно сортировать записи в телефонной книге, а в другом - список файлов в директории на диске...

Цитата the_Shadow @ 19.04.06, 15:31

На сайте VIM есть примеры "макросов" для автогенерации кода. Забыл линк, но они там есть... Я ни их базе для генерации ПО для PalmOS зафигачил себе мкакросы... И... нормально.

А чем, позвольте, это лучше шаблонов? С учетом того, что все это раскрывается на этапе препроцессирования кода, а потому черевато таким количеством косяков, что... уууууууу....

Цитата the_Shadow @ 19.04.06, 15:31

Да. Продолжу. Если по-пилить по типам данных реализацию, то ты сможешь разнести её по библиотекам и скрыть детали реализации. На что-то это похоже... :D:D

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

Цитата

Ну да. Как он мне может помочь, если в одном случае мне нужно сортировать записи в телефонной книге, а в другом - список файлов в директории на диске...

Элементарно. Создаёшь соотв. структуры данных, в них -- через typedef определяешь типы данных для соответствия своему алгоритму и -- с Богом. Причём, всё создаёшь не "в одной куче", а в разных -- что-то для тел. книги, что-то -- в проекте по работе с каталогами.

Цитата

А он предлагает сделать несколько реализаций алгоритма, занимающего без малого сотню строк.

Гы-гы... А, может, и по-боле... Впрочем, если не валить всё в одну кучу, а разбить на отдельные проекты, то и меньше. Намного... :D:D:D

Цитата

С шаблонами я могу сделать ровно точно также. И успешно это применяю.

А я, по весьма странной привычке, стараюсь обходиться без них. Правда, если проект начат на С++, то его стоит на нём и продолжать. А, если нет, то... чур меня, чур! :D:D:D
В конце-концов, и более сложные проекты (GTK+/GNOME) живут и здравствуют на С и, пока никуда не собираются переезжать... :D:D:D

Цитата the_Shadow @ 19.04.06, 19:16

Элементарно. Создаёшь соотв. структуры данных, в них -- через typedef определяешь типы данных для соответствия своему алгоритму и -- с Богом. Причём, всё создаёшь не "в одной куче", а в разных -- что-то для тел. книги, что-то -- в проекте по работе с каталогами.

С первого раза не дошло. Приведи пример кода.

Цитата the_Shadow @ 19.04.06, 19:16

Гы-гы... А, может, и по-боле... Впрочем, если не валить всё в одну кучу, а разбить на отдельные проекты, то и меньше. Намного... :D:D

Я просто посмотрел реализацию стандартного qsort. Только и всего.

Цитата the_Shadow @ 19.04.06, 19:16

А я, по весьма странной привычке, стараюсь обходиться без них. Правда, если проект начат на С++, то его стоит на нём и продолжать. А, если нет, то... чур меня, чур! :D:D

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

Цитата

А он предлагает сделать несколько реализаций алгоритма, занимающего без малого сотню строк.

Эмммм, а в результате, чем бы ты не делал, оно так разве на одно не получится? При неумелом обращении что с шаблонами, что с макросами, дерьмеца не оберешься.

Цитата Ho Im @ 19.04.06, 19:31

Эмммм, а в результате, чем бы ты не делал, оно так разве на одно не получится? При неумелом обращении что с шаблонами, что с макросами, дерьмеца не оберешься.

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

Цитата

ибо предсказать, как развернется макрос, сложнее, чем предсказать - как развернется шаблон...

Хм. Давай добавим к этому утверждению «в случае, если неизвестно, кто будет этот макрос/шаблон использовать», чтобы оно было истинным.

Цитата Ho Im @ 19.04.06, 20:13

Давай добавим к этому утверждению «в случае, если неизвестно, кто будет этот макрос/шаблон использовать», чтобы оно было истинным.

Да даже если и известно... Тут вон Друнк в разделе по Visual C++ рассказывал про свое "веселье" с windows-методами, когда невинный "с виду" метод на поверку оказывался макросом... И все такое прочее. Ведь макрос - это, вообще говоря, достаточно примитивная замена одного фрагмента исходного текста на другой фрагмент. Без каких либо проверок - на сколько такая замена вообще правомочна и уместна. Правилам языка (ни С, ни С++) макросы не подчиняются. А потому гарантировать, что написанный тобою макрос имеет хоть какой-либо смысл компилятор не может. С шаблонами иначе. Шаблон - сущность, хорошо известная компилятору. Компилятор проверяет его соответствие грамматике языка. А в процессе инстанцирования осуществляет уже "тонкую доводку", подставляя вместо формальных реальные параметры. В каком то смысле это похоже на вызов функции, который осуществляется на этапе компиляции, и результат которого - какой-то фрагмент объектного кода или данных (или ничего, что бывает не так редко).

Цитата

Да даже если и известно... Тут вон Друнк в разделе по Visual C++ рассказывал про свое "веселье" с windows-методами, когда невинный "с виду" метод на поверку оказывался макросом...

Видишь ли, Друнк не знал, что это — макрос (я тот топик читал), и оттого была беда. Если же писал, скажем, сам для себя, то таких проблем не возникает (разве при перманентном скрезоле).

Цитата Flex Ferrum @ 19.04.06, 19:02

Что-то недопонял я этого пассажа. Постановка проста и ясна - написать обобщенный алгортим.

Вообще говоря, обобщенные алгоритмы это не та область, в которой хороши процедурные языки. Конечно, в силу необходимости их приходится использовать и в таких случаях нельзя не сказать спасибо дядьке Страуструпу и комитету ISO за существование шаблонов в языке C++. Но если посмотреть, например, на Lisp то быстро становится понятно, каким костылем являются темплейты, хотя, конечно, они сильно облегчают решение многих задач. Но ИМХО все элементы ФП в плюсах -- редкостно уродливый костыль, от которого весь мир в восторге, потому что ничего другого не видел.

[root@106-109-8-11 hel2]# ./a.out
bash: ./a.out: Permission denied

Я собрал a.out командой as hello.S, а он не запускается. В чем дело?
И можно сделать, чтобы as назвал выходной файл как-нибудь по другому?

Сообщение отредактировано: plan699 - 20.04.06, 06:51