Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, adontz, Вы писали:
ME>>>memory footprint, мобильные ус-ва приходят тут же на ум. Просто вот так (шелчок пальцами) все приложения, которые используют FILE* будут больше кушать памяти? A>>Реализация несколих списков да и сами списки вряд ли займут сущесвенное количество памяти. Если ты отроешь 250 файлов и будешь хранить валидные указатели в виде RB дерева (чтобы быстрее искать), то на 32битной платформе получишь (3 указателя + 1 указатель) * sizeof(void *) * 250 = 4000 байт данных. ИМХО даже для мобильных устройств это совершенно смешной объём
K>Расскажите об этом разработчикам встроенных систем всякого рода. Вы их осчастливите запасом хорошего настроения на день. От хохота.
Как как раз тот разработчик встроенных систем, отправлю обоих пить пиво в сторонке и нас не трогать, потому как Линуха у меня не будет и Винды тем более, потому что не поместится да и не нужен мне он. и вообще у самого крутого проца из серии 32К флеш памяти, и около 16К Рам, ну с господа куда вы собираетесь свои дескрипторы засовывать .
Здравствуйте, Stoune, Вы писали:
S>Как как раз тот разработчик встроенных систем, отправлю обоих пить пиво в сторонке и нас не трогать, потому как Линуха у меня не будет и Винды тем более, потому что не поместится да и не нужен мне он. и вообще у самого крутого проца из серии 32К флеш памяти, и около 16К Рам, ну с господа куда вы собираетесь свои дескрипторы засовывать .
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Stoune, Вы писали:
S>>Как как раз тот разработчик встроенных систем, отправлю обоих пить пиво в сторонке и нас не трогать, потому как Линуха у меня не будет и Винды тем более, потому что не поместится да и не нужен мне он. и вообще у самого крутого проца из серии 32К флеш памяти, и около 16К Рам, ну с господа куда вы собираетесь свои дескрипторы засовывать .
K>Встроенные системы тоже разные бывают...
Только вот таких как моя, или даже с ешё большими апаратными ограничениями в количественном выражении будет наверное на порядок больше чем всех остальных вместе взятых(часы, кофемолки, кросовки и очень много всего). Ну и на чьей стороне сила, брат?
Здравствуйте, Кирпа В.А., Вы писали:
КВА>А возмутило меня другое Анализ лога valgrind показал что библиотечные КВА>функции fprintf, fclose вовсю юзают malloc, free
Каким боком функции glibc относятся к Linux ?
Что, других рантаймов нет ?
Здравствуйте, adontz, Вы писали:
A>>>мелочи по сравнению со скоростью ввода-вывода. ДД>>Я уже говорил, дескриптор не обязательно будет дескриптором открытого файла на диске. Это может быть файл устройства, именованый канал, etc.
A>Всё равно, поиск в списке из нескольких десятков элементов это мелочи. Ввод-вывод крайне редко является узким местом. А если является, то меняют аппаратуру, а не переписывают программу.
Бывают открыты и десятки тысяч файлов, например на файл-сервере.
Вы такое впечатление, рассматриваете эту проблему в применении для разных относительно
простых десктопно-офисных программ и не заметили, что ваш подход создаёт на самом деле
серьёзную проблему.
Допустим мы будем всегда проверять на повторное закрытие, тогда мы должны хранить не
только список открытых файлов, но и список всех закрытых. Если списка закрытых файлов не будет, выйдет риск при повторном закрытии закрыть файл, со вновь полученным
дескриптором, то есть, мы не избавимся от неопределённого поведения, а только растратим лишние ресурсы на список и его проверку.
Кроме того, отловить такую ошибку может быть сильно тяжелее. Представьте себе многопоточную программу, в одном потоке закрыли два раза файл, а в другом на ровном
месте возникла ошибка на файловых операциях. Я вас уверяю, сообразить в этом случае
из-за чего возникла ошибка окажется тяжело, тем более данная ошибка будет плохо воспроизводимой, при маленькой вероятности повторной выдаче одинакового номера дескриптора. Самый подлый для отладки вид ошибок, проявляющихся нерегулярно, очень редко, да ещё и в совершенно других файлах относительно места возникновения.
И зачем козе баян, если от ошибок он не избавляет, загоняя их вглубь, делая опасными для работы, а ресурсы лишние тратятся?
А если вы полагаете нужным хранить весь список, в том числе и открытых файлов, то я только руками разведу: утечка памяти и расход ресурсов на ерунду никак хорошим программированием нельзя назвать.
При том замечу, в каких-то частных случаях можно и списки лишние хранить и проверки делать и прочее, для чего делаются обёртки и свой код под эти случаи. Вы же говорили об универсальном подходе.
Мой вывод: всегда проверять на уровне системных библиотек правильность fclose, free и др. на случай неверного указателя, кроме спецзначений (NULL и др.) или их диапазона (области пользовательских/системных данных) в корне неверно и способствует возникновению труднообнаруживаемых ошибок.
.
и очень много всего). Ну и на чьей стороне сила, брат? 
