форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

Сообщения по теме

[Сортировка по времени | RSS]

3. "Идеи по усовершенствованию реализации библиотек на языке Си"	+2 +/–
Сообщение от croster (ok) on 17-Окт-10, 22:09
Не согласен с пунктом 12 "На стадии разработки не стоит утруждаться вопросами портирования кода на другие платформы." Если разработчик не потрудился проверить работу на нескольких платформах, то он может завязать свою разработку на специфических функциях, работающих лишь на одной платформе. И портирование может превратиться в непростую задачу. Зачем усложнять другим жизнь, когда можно сразу сделать всё по-нормальному?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Идеи по усовершенствованию реализации библиотек на языке Си"	+8 +/–
	Сообщение от ананим on 17-Окт-10, 22:22
	это у нас так принято, а для человека пологающегося интуитивно на анси С (да и С++) - это естественно. под портированием под платформу они как раз подразумевают специфичные функции. но, повторяю, когда источником является мсдн, то... ну трухина вы видели.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Ананимуз on 17-Окт-10, 22:54
	А разработчику (этого кода) оно точно нужно? Боюсь многие в таком случае просто забьют на идею поделиться.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Идеи по усовершенствованию реализации библиотек на языке Си"	+2 +/–
	Сообщение от Aesthetus Animus (ok) on 17-Окт-10, 23:38
	Цитируйте до конца ;) "Если вы сами не собираетесь тестировать код на платформе, отличной от той, где велась разработка, оставьте это на потом." И это как раз ключевой момент. Пусть код работает только на некоторых платформах, но делает это хорошо ;) Если код написан грамотно, а это как раз и оговаривается в остальных пунктах и в их лозунге, то его не составит труда портировать тому, кому это надо.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от croster (ok) on 17-Окт-10, 23:47
	Код может быть написан грамотно, но прибит гвоздями к Windows (Linux). Потом может кому и захочется на Linux (Windows) портировать, но затраты будут достаточно велики (а возможно и написать с нуля будет гораздо проще).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	35. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от ананим on 18-Окт-10, 14:35
	это уже не грамотный код. с точки срения стандартов. к примеру fprintf есть в стандарте C, cin/cout есть в стандарте С++, а WWriteFile есть в стандарте только винапи. первые доступны на любой платформе, последняя только на винде (вайны не в счет) так вот, когда нормальные люди пишут подобные документы, то им даже в голову не приходит, что кто-то по умолчанию за стандарты берет стандарты мс (или других вендоров). а когда нормальные люди говорят о портировании, то предполагают что кому-то на винде (и только на винде) когда-нибудь потом,по какой-либо существенной причине захочется вместо fprintf вызывать WriteFile. мысль, что намертво прибитый код может быть грамотным - даже в голову не придет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	39. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 18-Окт-10, 20:00
	> к примеру fprintf есть в стандарте C Есть-то он есть, да кто ж его ест. В смысле, для того, чтобы правильно и _портабельно_ воспользоваться fprintf в нетривиальных случаях (с нетривиальными модификаторами/типоуказанием), надо не полениться заглянуть в man на фряхе, инфо на линуксе и MSDN на винде.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	45. "Идеи по усовершенствованию реализации библиотек на языке Си"	–1 +/–
	Сообщение от Аноним (??) on 19-Окт-10, 00:07
	_портабельно_ - это как указанно в ANSI C стандарте. А он на всех платформах един ...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	46. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:15
	Та часть, которая предсказуемо работает на всех платформах, уж очень ограниченна. Учитывая, что даже на размер переменной не заложишься - а для разных размеров нужны разные модификаторы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	54. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от ананим on 19-Окт-10, 11:56
	приведите пример "ограниченности". пока только сферически-нетривиальные кони в вакууме. это во-первых. а во-вторых, портирование под платформу (а эти кони именно так и называются) никто не отменял. просто заморачиваться этим не стоит на первом этапе. зы: про размеры переменных - это несчастный инт что ли? 1. его, инта, не та уж много. 2. а нахрена на размер закладываться? достаточно того, что его в любой момент можно подсчитать. 3. не пользуйтесь интом.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	57. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 21-Окт-10, 06:08
	> приведите пример "ограниченности". > пока только сферически-нетривиальные кони в вакууме. Нет, практический опыт написания низкоуровневых приложений (а иначе нахрена C ?) > это во-первых. > а во-вторых, портирование под платформу (а эти кони именно так и называются) > никто не отменял. просто заморачиваться этим не стоит на первом этапе. И, в результате "портирования" выясняется, что дешевле НЕ пользоваться всем из себя таким _портабельным_ , "ANSI-Сишным" и бла-бла fprintf и иже с ними, а нагородить свой велосипедик разной степени убогости, и в следующем проекте использовать именно его. > зы: > про размеры переменных - это несчастный инт что ли? > 1. его, инта, не та уж много. > 2. а нахрена на размер закладываться? достаточно того, что его в любой момент можно > подсчитать. > 3. не пользуйтесь интом. Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C, хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	59. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от kshetragia (ok) on 22-Окт-10, 05:25
	> Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или > ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти > чудесные типы данных? э-э-э... inttypes.h не? По крайней мере это работает для linux/bsd x32/x64. Для винды похоже придется писать свой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	63. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 22-Окт-10, 22:35
	>> Ох... В C им и так почти не пользуются. А пользуются, например, типом size_t. Или off_t. Или >> ещё какой int16_t. Итак, Вы, кажется, знаете, как "портабельно" напечатать в поток эти >> чудесные типы данных? > э-э-э... inttypes.h не? > По крайней мере это работает для linux/bsd x32/x64. Для винды похоже придется > писать свой. Задание, напомню, касалось вывода целочисленных типов в поток посредством "портабельного и ANSI-Сишного" fprintf & Co. inttypes.h не при делах, см. соседние сообщения
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	71. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от kshetragia (ok) on 25-Окт-10, 11:29
	гм.. уже посмотрел..
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	60. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 22-Окт-10, 08:41
	> Ох... В C им и так почти не пользуются. А пользуются, например, > типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется, > знаете, как "портабельно" напечатать в поток эти > чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C, > хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию! Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех платформах, где его нет изначально (Windows), можно взять готовый и адаптировать. Это будет заметно меньше работы, чем полностью городить свой огород, равно как и его поддерживать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	61. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 22-Окт-10, 08:48
	>> Ох... В C им и так почти не пользуются. А пользуются, например, >> типом size_t. Или off_t. Или ещё какой int16_t. Итак, Вы, кажется, >> знаете, как "портабельно" напечатать в поток эти >> чудесные типы данных? На всём многообразии платформ, для которых есть компиляторы C, >> хоть сколько-нибудь претендующие на "ANSI-Сишность". Рецепт, что называется, в студию! > Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", > соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех > платформах, где его нет изначально (Windows), можно взять готовый и адаптировать. > Это будет заметно меньше работы, чем полностью городить свой огород, равно > как и его поддерживать. А если собирать не посредством VC++, то и таких проблем не возникнет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	62. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 22-Окт-10, 22:30
	> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", Спасибо, Капитан. > соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех > платформах, где его нет изначально (Windows), можно взять готовый и адаптировать. > Это будет заметно меньше работы, чем полностью городить свой огород, равно > как и его поддерживать. Вы хотите предложить таскать мне за собой гнутый рантайм (или сравнительно свежий BSD'шный). Что ж, это решение, покуда у вас есть "настоящая платформа". Как только дело начнёт касаться всяких аппаратно-программных недоразумений - тут внезапно и выяснится, что переносимость, а, главное, применимость гнутого рантайма - сильно преувеличена. Поспрашайте людей, пишущих под телефоны и прочие "имбеддеды".
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	64. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 22-Окт-10, 22:39
	>> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", > Спасибо, Капитан. Ну и да, выше упоминается off_t, а не ptrdiff_t. Который, как известно, нынче скорее 64'битный "на линуксах", но, во-первых, и там необязательно и достигается дифайном при компиляции, и, во-вторых, кое-где - по-прежнему 32-х битный. Специального модификатора для него в POSIX'овом printf'е нет. P.S. Замечу, от ANSI C-шного стандарта мы как-то тихой сапой уползли в POSIX. Что, замечу, существенно сокращает и выбор рантаймов, и выбор компиляторов для них.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	66. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 22-Окт-10, 23:15
	>>> Для size_t и ptrdiff_t в POSIX имеются варианты конверсии "z" и "t", >> Спасибо, Капитан. > Ну и да, выше упоминается off_t, а не ptrdiff_t. Который, как известно, > нынче скорее 64'битный "на линуксах", но, во-первых, и там необязательно и > достигается дифайном при компиляции, и, во-вторых, кое-где - по-прежнему 32-х битный. > Специального модификатора для него в POSIX'овом printf'е нет. > P.S. Замечу, от ANSI C-шного стандарта мы как-то тихой сапой уползли в > POSIX. Что, замечу, существенно сокращает и выбор рантаймов, и выбор компиляторов > для них. <inttypes.h> входит в C99. Что ещё тут сказать? Да, не все компиляторы поддерживают C99. Если у кого-то нет inttypes.h в наборе разработчика, может взять из BSD-шного и, если возникнет такая необходимость, доработать.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	65. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 22-Окт-10, 23:07
	>> соответственно. Для работы с целочисленными же типами есть inttypes.h; На тех >> платформах, где его нет изначально (Windows), можно взять готовый и адаптировать. >> Это будет заметно меньше работы, чем полностью городить свой огород, равно >> как и его поддерживать. > Вы хотите предложить таскать мне за собой гнутый рантайм (или сравнительно свежий > BSD'шный). Всего лишь заголовочный файл. > Что ж, это решение, покуда у вас есть "настоящая платформа". > Как только дело начнёт касаться всяких аппаратно-программных недоразумений - тут внезапно > и выяснится, что переносимость, а, главное, применимость гнутого рантайма - сильно > преувеличена. Поспрашайте людей, пишущих под телефоны и прочие "имбеддеды". Мимо. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	67. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 23-Окт-10, 04:43
	> Всего лишь заголовочный файл. П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу той, с которой ему удобно сражаться, и понеслось... > Мимо. :) Это точно, точнее не скажешь. Итого, подведём промежуточные итоги. Исходным тезисом являлось утверждение о том, что (ANSI-) C'шный рантайм обладает достаточной портабельностью и универсальностью, чтобы можно было не задумываясь применять его в широкопортабельных проектах (порты с Ubuntu/32 на Debian/64 не в счёт). В качестве примера такой универсальной функции приводился классический fprintf. В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод типов size_t, off_t и int16_t, я дождался от Вас только предложения форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных мне, в общем, сведений о том, как форматировать ptrdiff_t и предложения таскать за собой _реализацию_ fprintf'а из glibc (или *BSD libc или любой другой открытой реализации С-шного рантайма, непринципиально). Ещё Вы порадовали меня предложением не использовать MSVC++. Мне кажется, Вы уже исчерпали допустимый лимит неправильных ответов на такой простой, не правда ли, вопрос?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	68. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Окт-10, 05:04
	>> Всего лишь заголовочный файл. > П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h > в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу > той, с которой ему удобно сражаться, и понеслось... Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали? /* fprintf macros for signed integers */ #define PRId8                   "d"             /* int8_t */ #define PRId16                  "d"             /* int16_t */ #define PRId32                  "d"             /* int32_t */ #define PRId64                  "lld"           /* int64_t */ И т.д. >[оверквотинг удален] > классический fprintf. > В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод > типов size_t, off_t и int16_t, я дождался от Вас только предложения > форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных > мне, в общем, сведений о том, как форматировать ptrdiff_t и предложения > таскать за собой _реализацию_ fprintf'а из glibc (или *BSD libc или > любой другой открытой реализации С-шного рантайма, непринципиально). Вам что, очевидные вещи разжёвывать надо? Так за этим вы не по адресу, это к Марьиванне из детского сада. Или сделать printf("%" PRIdLEAST64, some_value) религия не позволяет? Или скажете, что это не даст гарантированно искомое? > Ещё Вы порадовали меня предложением не использовать MSVC++. Как самый простой способ не связываться с кастратом под названием msvcrt. Впрочем, в нём есть свои фишки, спорить не буду. Поэтому это было лишь предложение, для _поставленной_ задачи. > Мне кажется, Вы уже исчерпали допустимый лимит неправильных ответов на такой простой, > не правда ли, вопрос? Да ну? А вы-то что умеете, кроме как задавать вопросы и напускать на себя важный вид? (что-то я опять язвительный сверх меры... пойду-ка посплю)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	69. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Морозов Алексей on 23-Окт-10, 11:38
	> #define PRId8                   "d"             /* int8_t */ > #define PRId16                  "d"             /* int16_t */ > #define PRId32                  "d"             /* int32_t */ > #define PRId64                  "lld"           /* int64_t */ Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали: > printf("%" PRIdLEAST64, some_value) религия не позволяет? увы, религия не позволяет. Потому что: 1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность - главное достоинство printf-like форматирования) подобный код - задача не для слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь модификаторами для разнообразия, и результат показать здесь. А потом оценить количество людей, которым понравится портабельность _такой_ ценой. 2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет, "стандартная для платформы" реализация printf не научится волшебным образом понимать эти самые 64битные значения. 3. в исходной задаче говорилось про size_t, off_t и int16_t. Случай int16_t разобрали выше. Для size_t и off_t, по факту, требуется {configure/compile}-time проверки с выбором между этими типами, и "обычными" int/long/etc там, где рантайм не в курсе POSIX'овых умностей. Опять же, см. пп.1 и 2. 4. Впереди ещё форматирование многобайтных строчек и непрямое (через *) указание аргументов. >>> Всего лишь заголовочный файл. >> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h >> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу >> той, с которой ему удобно сражаться, и понеслось... > Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали? Ну, макросов этих не помню, но, честно, они не помогают, см. возражения выше. > (что-то я опять язвительный сверх меры... пойду-ка посплю) Давайте. Авось, язвительность ненужная поутихнет. P.S. буквально в среду разглядывал реализации такого форматирования сначала в сысоевском коде, а потом в ещё одном проекте, претендующем на переносимость. И чего это люди не горят использовать стандартные механизмы в своих проектах ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	70. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Окт-10, 13:13
	>[оверквотинг удален] >> #define PRId32                  "d"             /* int32_t */ >> #define PRId64                  "lld"           /* int64_t */ > Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали: >> printf("%" PRIdLEAST64, some_value) религия не позволяет? > увы, религия не позволяет. Потому что: > 1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность > - главное достоинство printf-like форматирования) подобный код - задача не для > слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь > модификаторами для разнообразия, и результат показать здесь. А потом оценить количество > людей, которым понравится портабельность _такой_ ценой. Этот вопрос не ставился. Был вопрос о реальности портабельности «родными» средствами языка. Это не говоря о том, что описываемые вами ситуации в рамках нормальной программы — редкость. Часто повторяющиеся *printf() выносятся в отдельные функции, и т.д. Впрочем, я могу не представлять себе какого-то проблемного класса программ — продемонстрируете? > 2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет, > "стандартная для платформы" реализация printf не научится волшебным образом понимать эти > самые 64битные значения. Если «стандартная для платформы» реализация *printf не умеет понимать 64-битные значения (что, вообще говоря, нонсенс; пусть операции с 64-битными числами не будут атомарными, но они будут; впрочем, я не слишком большой спец в embedded-разработках), то и в программе не будет встречаться int64_t и иже с ним, так? Иначе ведь она всё равно на данной платформе даже не скомпилируется. А если не будут встречаться 64-битные числа, то тогда используем макрос PRIdLEAST32... Ну и т.д. > 3. в исходной задаче говорилось про size_t, off_t и int16_t. Случай int16_t > разобрали выше. Для size_t и off_t, по факту, требуется {configure/compile}-time проверки > с выбором между этими типами, и "обычными" int/long/etc там, где рантайм > не в курсе POSIX'овых умностей. Опять же, см. пп.1 и 2. Эм-м-м... Рантайм, он вообще, не в курсе size_t, off_t и так далее. Это чисто компиляторные заморочки. Оператор sizeof() ещё никто не отменял. Зачем делать выбор между типами size_t/off_t/etc. и int/long/etc., когда достаточно просто объявить size_t/off_t/etc. в случае их отсутствия (во время того же конфигурирования, или компиляции, например)? > 4. Впереди ещё форматирование многобайтных строчек А какое отношение имеют многобайтные строчки к размеру переменных? Для начала, какие у вас вообще строчки? char*? wchar_t*? А то вы всё пугаете, пугаете... Стандартная библиотека предоставляет средства для форматирования строк в некоторых форматах. Если вам нужна экзотика — you're on your own, как в любой другой среде. Собственно, давно есть (портабельные, хе-хе) библиотеки для работы со специфическими кодировками, так что велосипед, опять же, изобретать не требуется... > и непрямое (через *) указание аргументов. И в чём здесь проблема? Не все платформы поддерживают? Ну простите... Возьмите тогда заодно точно так же BSD-шную реализацию *printf и таскайте с собой для таких случаев, в чём проблема-то? Не вижу серьёзных причин для того, чтобы всё с нуля переписывать. >>>> Всего лишь заголовочный файл. >>> П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h >>> в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу >>> той, с которой ему удобно сражаться, и понеслось... >> Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали? > Ну, макросов этих не помню, но, честно, они не помогают, см. возражения > выше. Они помогают, а единственное возражение было — «плохо читается». Хотя в общем случае я с этим аргументом согласен (удобочитаемость кода очень важна), всё же позволю себе заметить, что использование альтернативной системы для форматирования строк повышает сложность программы, что тоже не есть гуд. > P.S. буквально в среду разглядывал реализации такого форматирования сначала в сысоевском > коде, а потом в ещё одном проекте, претендующем на переносимость. И > чего это люди не горят использовать стандартные механизмы в своих проектах > ;) Это их выбор, я их не спрашивал, вы, по всей видимости, тоже (иначе бы не вопрос задавали, а давали факты). Люди ещё пишут тысячи однотипных CMS на PHP, и эти CMS от своего количества лучше не становятся.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	58. "про fprintf"	+/–
	Сообщение от Морозов Алексей on 21-Окт-10, 06:18
	Да, готовьтесь к тому, что во второй части нашей увлекательной викторины "а умеешь ли ты программировать на C" мы коснёмся таких интересных возможностей, как fprintf и многобайтные строки, возможность непрямого указания аргументов и других вроде бы стандартизованных возможностей *printf
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Идеи по усовершенствованию реализации библиотек на языке Си"	–2 +/–
	Сообщение от Фкуку on 18-Окт-10, 01:40
	Нет слов... :( VM... POSIX?.. Ничего не говорят? ИМХО, код на Си, НЕ ЗАДУМАННЫЙ СРАЗУ, как мультиплатформенный - дебилизм. п.1 меня ваще вводит в оторопь. Расти Рассел откровенно страдает фимозом головного мозга.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "Идеи по усовершенствованию реализации библиотек на языке Си"	+6 +/–
	Сообщение от www2 (??) on 18-Окт-10, 07:42
	Если думать обо всём и сразу, то есть риск вообще не сдвинуться с места, погрязнув во второстепенных вопросах. В Free Software принят подход Release Early, Realease Often. Выпускай раньше, выпускай чаще. Пусть код будет работать уже сейчас хотя бы на части платформ, чем теоретически будет работать на всех платформах, но через неопределённое время. То, что уже выпущено - это не окончательный вариант, а материал для дальнейшей работы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от ананим on 18-Окт-10, 14:20
	код на анси С сам по себе кроссплатформеннее некуда. и анси С полностью соответсвует посиккс. собственно посикс для программиста на С - это и есть сишная библа аля глибси. вот оно наше образование.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	47. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:24
	Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools это вообще дикость. Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая последовательность эвристик, тупо повторяющаяся для каждого пакета. А за предложение делать примитивные интерфейсы вместо простого API, основанного на сложном, автору надо что-нибудь оторвать. Как и за идею отказаться от вменяемой диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна. А вообще говоря - лучше бы сразу закладывались на плюсы в варианте "С с классами". Как минимум, глупостей вроде mylib_myfunction можно было бы избежать, используя нормальные пространства имён. В общем, по поводу фимоза - согласен.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	56. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от ананим on 20-Окт-10, 04:16
	>Вместо того, чтобы держать в среде информацию о ней же и модифицировать при изменениях среды, остаётся только заставить все целевые платформы следовать этому, не побоюсь сказать, благородному порыву. ну а пока они не следуют, приходится по старинке, но ~100% рабочим способом. >А за предложение делать примитивные интерфейсы вместо простого API, вы уверены в понимании аббревиатуры API? в общем, автор статьи как-то больше импонирует, чем ваш комментарий.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	75. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 03-Ноя-10, 05:59
	Ничего страшного. К pkg-config приучается же народ понемногу. А если на паре-тройке основных платформ будет, то и остальные потянутся. А пока можно просто смотреть - если что-то определено - брать инфу, если нет - автотулзы, по старинке. В общем, вопрос маркетинга в основном.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	73. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Aleksey Cheusov on 25-Окт-10, 17:45
	> Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools > это вообще дикость. http://sourceforge.net/projects/mk-configure/ http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf > Вместо того, чтобы держать в среде информацию о > ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая > последовательность эвристик, тупо повторяющаяся для каждого пакета. Состояния среды можно держать в mkc-mk/sys.mk, но в конкретно imake даже хуже на практике. > Как и за идею отказаться от вменяемой > диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация > свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна. +2
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Идеи по усовершенствованию реализации библиотек на языке Си"	+5 +/–
	Сообщение от 2Nike (ok) on 18-Окт-10, 02:02
	> Если разработчик не потрудился проверить работу на нескольких платформах, то он может завязать свою разработку на специфических функциях, работающих лишь на одной платформе. Проблема в том, что разработчик не всегда имеет одинаковый скилл на всех платформах. И портирование может занять продолжительное время, которое разработчик может потратить на добавление новых возможностей, исправление ошибок. А вот если кому то _реально_ нужен будет этот софт, он его допилит для своей платформы. Я так понял, то имелось в виду.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от z (??) on 18-Окт-10, 14:34
	>Если разработчик не потрудился проверить работу на нескольких платформах >Зачем усложнять другим жизнь, когда можно сразу сделать всё по-нормальному? какие сложности - бери да пиши всё с нуля
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	55. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от andr.ru on 19-Окт-10, 12:17
	Как минимум надо переходить от Си на С++, кодом гораздо проще управлять. А вообще давно пора искать альтернативы лексическому программированию - это получается не математика, а литературный жанр. Писано миллионы и миллиарды строк кода, которые приходится всё время переписывать и дописывать - изъян в самой системе кодирования. Надо смотреть в сторону UML и FSM. Один раз решённые задачи не придется никогда пересматривать и решение будет математически точным и конечным, исключающим бесконечное "улучшение кода", "рефакторинг" либо использование кода непредусмотренным образом вирусами. Прошло полвека с рождения фортрана и Си, нужен качественный скачок. Индустрия в застое, бурно растущие базы кода непомерно дороги и недолговечны в использовании, содержат массу ошибок и дыр. Надо менять систему. Тогда не надо будет долго ломать голову над названием очередной главы писательского труда - MyLibForCoolHacker() или mylib_fch() :), можно будет просто написать ряд "математических формул", строго задающих поведение системы. http://www2.research.att.com/~fsmtools/fsm/
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
Сообщение от Aesthetus Animus (ok) on 17-Окт-10, 22:39
Очень здравая и ясная идея! То, что перечислено в списке, - в общем то очевидно, но наконец это все сказано в одном ключе и в слух.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от 310dej on 17-Окт-10, 23:40
	Очевидное зло :-) Есть библиотеки хорошие, и есть не хорошие, а есть и корпоративные. Примут ли это к сведению корпорации, работающие на Си? Для меня большой вопрос.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Андрей (??) on 18-Окт-10, 00:42
	если им это покажется здравым и полезным - то "ВайНо?"
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
Сообщение от Ariel (ok) on 17-Окт-10, 23:58
>mylib_free() Так нужно: MyContextFree(MyContext *con)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от www2 (??) on 18-Окт-10, 07:36
	Там же ясно написано, что в Plain C не принято использовать CamelCase.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "Идеи по усовершенствованию реализации библиотек на языке Си"	–4 +/–
	Сообщение от klalafuda on 18-Окт-10, 08:00
	> Там же ясно написано, что в Plain C не принято использовать CamelCase. Простите - кем написано? Расти Раселом? Пардон, но при всем уважении к его творениям он явно далек от позиции чтобы диктовать, что в языке C принято а что - нет. Это у него - не принято. И бога ради. Это его личная позиция. Но - не более того.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "Идеи по усовершенствованию реализации библиотек на языке Си"	+3 +/–
	Сообщение от www2 (??) on 18-Окт-10, 08:11
	Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от klalafuda on 18-Окт-10, 08:17
	> Это не его личная позиция, это общепринятая практика. Посмотрите на стандартные библиотеки ANSI C, посмотрите на POSIX API, не используется там CamelCase. Есть два типа имён - макросы пишутся полностью ЗАГЛАВНЫМИ_БУКВАМИ, и всё остальное, пишется строчными_буквами. Названия типов данных дополняются суффиксом _t. Использование CamelCase в Plain C может быть скорее вашей личной позицией, но не более того. При всем уважении к стандартам ANSI C и POSIX, описываемое ими API и принятая в нем стилистика - это лишь мизерная часть от того, что было так или иначе разработано с использованием языка C в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..' - да, и ядро Linux/BSD/etc это так же очень небольшая часть от. Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых и закрытых и ещё бог знает каких. И вот так вот с легкой руки ровнять всех под одну гребенку и заявлять что мол 'в языке C что-то принято или не принято' - это мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Идеи по усовершенствованию реализации библиотек на языке Си"	+3 +/–
	Сообщение от www2 (??) on 18-Окт-10, 08:26
	>> При всем уважении к стандартам ANSI C и POSIX, описываемое ими API > и принятая в нем стилистика - это лишь мизерная часть от > того, что было так или иначе разработано с использованием языка C > в глобальном масштабе. Предвидя аргумент a'la 'А вот в ядре Linux/BSD/etc..' > - да, и ядро Linux/BSD/etc это так же очень небольшая часть > от. Такой стиль был принят: - создателеми языка (Д. Ричи), - всей группой разработчиков Unix (К. Томпсон, Б. Керниган и т.д.), для разработки которой и был изначально придуман Си, - в стандарте ANSI C, - в стандартах POSIX API. Если этого авторитета вам не достаточно, то разговаривать с вами дальше не имеет смысла. > Есть огромное количество самых разнообразных проектов, которые используют язык C. И открытых > и закрытых и ещё бог знает каких. И вот так вот > с легкой руки ровнять всех под одну гребенку и заявлять что > мол 'в языке C что-то принято или не принято' - это > мягко говоря несколько самоуверенно. Слишком самоуверенно. На грани фолта. Вы точно не путаете Plain C и C++? И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от klalafuda on 18-Окт-10, 08:58
	> Такой стиль был принят: > -создателеми языка (Д. Ричи), > -всей группой разработчиков Unix (К. Томпсон, Б. Керниган и т.д.), для разработки > которой и был изначально придуман Си, > -в стандарте ANSI C, > -в стандартах POSIX API. > Если этого авторитета вам не достаточно, то разговаривать с вами дальше не имеет смысла. Вообще то 'мир C' распространяется существенно дальше K&R, ANSI C, POSIX etc и мягко говоря ими не ограничен. Думаю, с этим фактом никто спорить не будет? Вспомнить хотя бы WinAPI и прикинуть, сколько на его базе было написано самого разнообразного софта. И принятый в нем стиль имеет ни чуть не меньшее право на существование, чем скажем стиль POSIX. А сколько ещё существует стилистических подходов к оформлению кода на C? Масса. Замечу, я сейчас не расставляю оценок какой из подходов лучше а какой хуже. WinAPI vs POSIX, CamelCase vs other etc. Оставим это бессмысленное занятие кому-нибудь другому. Но факт остается фактом: проектов на C существует огромное количество равно как и подходов к их стилистическому оформлению. И нельзя однозначно утверждать, что мол 'в C принято так то и так то и никак иначе'. Популярность и реальная применимость языка в тех или иных живых проектах давно уже шагнула бесконечно дальше чем те рамки и проекты, в которых он изначально разрабатывался. > И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный. Все течет, все меняется.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от www2 (??) on 18-Окт-10, 09:19
	> Но факт остается фактом: проектов на C существует > огромное количество равно как и подходов к их стилистическому оформлению. И > нельзя однозначно утверждать, что мол 'в C принято так то и > так то и никак иначе'. Вообще-то, именно так и принято. Хотя я конечно не говорю, что всё остальное запрещено. Крупные самостоятельные проекты могут пользоваться своим стилем. >> И вообще, что-то вы не похожи на klalafuda, он был более сдержан в высказываниях и всегда подписывался. И "На грани фолта." он бы не сказал, он грамотный. > Все течет, все меняется. Культурного, образованного и разумного человека сложно так быстро испортить.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "Идеи по усовершенствованию реализации библиотек на языке Си"	+3 +/–
	Сообщение от Аноним (??) on 18-Окт-10, 16:02
	>Вспомнить хотя бы WinAPI Вот уж что точно не надо вспоминать! Все эти ужасные BOOL и BYTE, всяческие hViewInstance, какие-то велосипеды и костыли на каждом шагу. Буэээ... Ещё ни разу не слышал чтобы стиль WInAPI хоть кому-то нравился.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:28
	Ну, их в основном за длину названий и венгерскую нотацию ругают. Кстати, венгерская нотация в сях, с их слабой типизированностью, иногда даже смысл имеет. Хотя очень редко :-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	48. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:26
	Вы будете удивлены, но в плюсах точно так же принято функции стандартной библиотеки и буста писать через подчёркивания. Это даёт возможность чётко видеть, что стандартно, а что - пользовательские функции, написанные в camelCase. И это удобно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от Аноним (??) on 18-Окт-10, 10:16
	Расти в комментариях поправляется: > Author comment by rusty | October 15, 2010 at 8:48 pm > I assume you’re being sarcastic? But just in case… > “standard” meaning “normal practice”. And also “as used by the standard”, since anyone familiar with the C standard library will be aware how prevalent this practice is (and also how weird exceptions like “FILE *” look). > I don’t think there’s a point in the standard saying “thou shalt not use BumpyCaps”; there are so many more effective ways to write ugly code which can’t be banned even if you wanted to. But if you use the standard libraries, your code won’t be consistently BumpyCaps anyway, so why start?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Идеи по усовершенствованию реализации библиотек на языке Си"	–7 +/–
Сообщение от VoDA (ok) on 18-Окт-10, 00:05
Странно, что описанные выше "проблемы" еще существуют в этом веке. на java многое из этого уже решено. А оставшееся - учить разработчиков как писать адекватный код. сложилось впечатление что CCAN это аналог подсистемы maven отвечающей за сбор проекта. PS совпадение src и test считаем просто совпадением ;)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от 2Nike (ok) on 18-Окт-10, 02:02
	> Странно, что описанные выше "проблемы" еще существуют в этом веке. на java > многое из этого уже решено. А оставшееся - учить разработчиков как > писать адекватный код. Когда появился java, а когда си.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	41. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от segoon (ok) on 18-Окт-10, 20:21
	Для чего существует Java, а для чего си :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	42. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от User294 (ok) on 18-Окт-10, 20:54
	> на java многое из этого уже решено. Только на java нельзя написать многое из того что на сях пишется только в путь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	51. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:31
	Да хоть бы и так. Чего ж не взять идею, если она хороша. Главное глупости не тянуть, вроде здоровенных нечитабельных XML-конфигов, сборщиков мусора и связывания рук разработчиков ;-) Но могу порадовать - CCAN эти названия каталогов содрал у перла :-) Как и название.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
Сообщение от Аноним (??) on 18-Окт-10, 01:16
"аналога архива CPAN для языка Си" кажется, опечатка...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
Сообщение от klalafuda on 18-Окт-10, 07:56
Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем же CPAN-ом. Пока же это даже на страничку Васи Пупкина не тянет.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от www2 (??) on 18-Окт-10, 08:13
	> Что-то как-то IMHO многовато шума для столь мелкого проекта. По крайней мере > если судить по содержимому их 'репозитория'. Вот выйдет народ на какой-то > более-менее вменяемый объем - ОК. Будет повод сравнивать их с тем > же CPAN-ом. Пока же это даже на страничку Васи Пупкина не > тянет. Всегда приходится с чего-то начинать. Linux начинался с эмулятора терминала, работающего в многозадачном режиме на i386. Я лично эту инициативу приветствую.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Идеи по усовершенствованию реализации библиотек на языке Си"	–1 +/–
Сообщение от Аноним (??) on 18-Окт-10, 09:46
>"наш код не должен быть уродливым" >Plain C Слегка поделили на 0.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	36. "Идеи по усовершенствованию реализации библиотек на языке Си"	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 18-Окт-10, 14:40
	>>"наш код не должен быть уродливым" >>Plain C > Слегка поделили на 0. На Си можно писать изящно. А можно не изящно. А можно не писать. Их цель достижима, а уж то, насколько их это ограничивает, если ограничивает, это их проблемы, а не тех, кто не видел изящного кода на Си. P.S.: Если какая-то задача решается одной-двумя строчками на Си против десятка на ЯВУ, то это потому что Си неизящный, да?..
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	40. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от gegMOPO4 (ok) on 18-Окт-10, 20:14
	По сравнению с бытовавшими в то время языками -- да, Си изящный. И сейчас в определённых областях он едва ли не лучшее решение. Просто появились новые области, и приоритеты изменились.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	44. "Идеи по усовершенствованию реализации библиотек на языке Си"	–3 +/–
	Сообщение от User294 (ok) on 18-Окт-10, 20:59
	> появились новые области, Да, выписывать веб-приложение типа Ынтерпрайзной CRM на голых сях можно и подзадолбаться. Впрочем удобный для такого [быдло]кодинга пых половина местных почему-то обсирает :).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от User294 (ok) on 18-Окт-10, 20:56
	>>"наш код не должен быть уродливым" >>Plain C > Слегка поделили на 0. Только совсем слегка. На сях порой попадается отличный код. Простой в понимании, читабельный, где грабельки успешно и изящно обрулены и прочая.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
Сообщение от anonymous (??) on 18-Окт-10, 12:43
>Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла. Это он про extern "C"
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	38. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от anonymous (??) on 18-Окт-10, 18:14
	мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla);
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	53. "Идеи по усовершенствованию реализации библиотек на языке Си"	+1 +/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:35
	> мне кажется, это он про C++ обёртки blabla->make_zashibis(); для blabla_make_zashibis(blabla); А вот такие "обёртки" делаются только с горя. Как правило гораздо больше толку, если автор позаботился предоставить плюсовый API, работающий непосредственно с внутренностями библиотеки. Можете как пример на libev глянуть.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от Crazy Alex (??) on 19-Окт-10, 00:32
	>>Не стоит загромождать заголовочные файлы конструкциями C++ - если вдруг ваша библиотека понадобится разработчику на C++, будет не сложно такую конструкцию добавить непосредственно в код разрабатываемой пользовательской программы, непосредственно перед #include вашего заголовочного файла. > Это он про extern "C" Ну тогда логично. Я уж подумал, что он наезжает на те библиотеки, которые предоставляют ещё и плюсовый интерфейс.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

72. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
Сообщение от Aleksey Cheusov on 25-Окт-10, 17:29
Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта. http://sourceforge.net/projects/mk-configure/ Один (под)проект -- один Makefile. Одна команда для сборки проекта -- mkcmake. Все.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	74. "Идеи по усовершенствованию реализации библиотек на языке Си"	+/–
	Сообщение от nuclight (ok) on 02-Ноя-10, 18:30
	> Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта. > http://sourceforge.net/projects/mk-configure/ > Один (под)проект -- один Makefile. > Одна команда для сборки проекта -- mkcmake. > Все. Ээ, он уже больше не на bmake? или стал таскать с собой?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема