On Thu, 15 Dec 2005 16:57:18 -0000, adontz <2053@users.rsdn.ru> wrote:
> Здравствуйте, MaximE, Вы писали: > > ME>Лишний footprint только для того, чтобы горстка наивных программистов не раздувала флейм в группах? > > Ты все свои программы написал без ошибок?
Я обычный человек, нам свойственно ошибаться
> ME>Я не хочу платить за то что не использую. Уверен, что большинство зрелых программистов думают также. > > Я не вижу чему тут сопротивлятся. Ну будет fclose что-то проверять в то время как ты будешь всегда передавать правильный указатель. И что?
memory footprint, мобильные ус-ва приходят тут же на ум. Просто вот так (шелчок пальцами) все приложения, которые используют FILE* будут больше кушать памяти?
> ME>Разгребайте баги в своем коде специализированными тулзами, коих навалом бесплатно. > > Максим, ты давно коммерческий софт разрабатывал? Релизы всегда выходят совсем безбажные?
Релизы бывают без критических багов. Но это уже разглагольствование — баги могут быть везде.
> Можно сколько угодно теоретизировать по поводу плохих программистов не умеющих отлаживать код, намекая при этом что ты сам не такой. На приктике же, подобная функциональность никого не стесняя может оказатся весьма полезной.
Тулзы есть для этого. Мне такой функционал нафиг не нужон.
>>> Те же дескрипторы в Windows это сплошь указатели или индексы в таблицах, однако использование левого дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон или детский сад, уж сам выбери. > > ME>Дескрипторы в Windows можно сравнивать с файловыми дескрипторами Unix, но не объектами FILE стандартной библиотеки. > > Почему? Объяснишь великую разницу из-за которой возможное для дескрипторов, для указателей на FILE не выозможно.
HANDLE и файловый дескриптор ссылаются на стр-ры/объекты ядра. FILE* — на объект из user mode библиотеки.
Здравствуйте, MaximE, Вы писали:
ME>memory footprint, мобильные ус-ва приходят тут же на ум. Просто вот так (шелчок пальцами) все приложения, которые используют FILE* будут больше кушать памяти?
Реализация несколих списков да и сами списки вряд ли займут сущесвенное количество памяти. Если ты отроешь 250 файлов и будешь хранить валидные указатели в виде RB дерева (чтобы быстрее искать), то на 32битной платформе получишь (3 указателя + 1 указатель) * sizeof(void *) * 250 = 4000 байт данных. ИМХО даже для мобильных устройств это совершенно смешной объём
ME>Тулзы есть для этого. Мне такой функционал нафиг не нужон.
Устойчивые ошибки и так отладить можно. Ресь о появляющихся иногда. Тут тулзы не особо помогут. Даже unit-testing.
ME>HANDLE и файловый дескриптор ссылаются на стр-ры/объекты ядра. FILE* — на объект из user mode библиотеки.
Если честно, всё равно не понимаю. или ты о чём-то специфичном для linux?
Здравствуйте, cattus, Вы писали:
C>И, насколько я знаю, повторный вызов close для одного и того же C>дескриптора совсем не страшен.
Страшен. Особенно отсутствием реакции. Ибо может привести к закрытию не того дескриптора, что совсем неприятно. Одним словом, такого быть не должно. Равно как и повторных вызовов free() на уже освобожденную память, например. Подобные вещи приводят часто к трудно воспроизводимым ошибкам.
Здравствуйте, adontz, Вы писали:
ME>>memory footprint, мобильные ус-ва приходят тут же на ум. Просто вот так (шелчок пальцами) все приложения, которые используют FILE* будут больше кушать памяти? A>Реализация несколих списков да и сами списки вряд ли займут сущесвенное количество памяти. Если ты отроешь 250 файлов и будешь хранить валидные указатели в виде RB дерева (чтобы быстрее искать), то на 32битной платформе получишь (3 указателя + 1 указатель) * sizeof(void *) * 250 = 4000 байт данных. ИМХО даже для мобильных устройств это совершенно смешной объём
Расскажите об этом разработчикам встроенных систем всякого рода. Вы их осчастливите запасом хорошего настроения на день. От хохота.
ME>>Тулзы есть для этого. Мне такой функционал нафиг не нужон. A>Устойчивые ошибки и так отладить можно. Ресь о появляющихся иногда. Тут тулзы не особо помогут. Даже unit-testing.
Эх, барин, жениться вам пора... Тьфу, тестеров нанять. Которые будут в том числе отслеживать code coverage тестами. Ну и valgrind в зубы, для кумплекту. А то так и утечки памяти спишете на "кривую реализацию".
Здравствуйте, adontz, Вы писали:
A>В данном случае соответсвие стандарту вряд ли можно назвать плюсом.
Когда и unix-like ОС начнут действовать по принципу M$^H^H "если наши функции не соответствуют стандарту — тем хуже для стандарта", то я уже даже и не знаю, куды бечь надо будет. В другую вселенную, не иначе.
C>>Вообще непонятно, как ты хочешь обрабатывать передачу инвалидного УКАЗАТЕЛЯ функции, на нем что написано, что он кривой. A>А подумать, прежде чем писать можно было? Ей передаётся не абы какой указатель, а выделенный fopen. Что мешает хранить где-то внутри список всех указателей выделенных fopen и при вызове fread, fwrite, fclose проверять валидность переданного указателя простым его вхождением в список? Ничего не мешает, кроме лени и желания гнать понты. По сравнению со скоростью ввода-вывода это копейки. Те же дескрипторы в Windows это сплошь указатели или индексы в таблицах, однако использование левого дескриптора не приводит ни к какому краху. UB на сегодня это плохой тон или детский сад, уж сам выбери.
Детский сад — это писать код, не соответствующий стандарту. Мне куда дороже более быстрое выполнение (даже если это 1 процент, хотя может быть значительно больше в Вашем случае), чем детские ошибки. gcov + valgrind творят чудеса, к сведению.
C>>Рекомендую читать маны, особенно по системным вызовам open, close, и не ...здеть о том, что "реализация библиотеки ввода/вывода в Linux — кривовата". A>Рекомендую думать, что говоришь и как говоришь. О того что кто-то в твойм понимании пи@@ит твои слова не стали весомее, а мысли умнее.
Тише, горячие парни. Модератора на вас обоих нет... 8))
LD>>Но его придется делать потокобезопасным, A>Это хорошо проработанная задача. Делается даже без блокировок.
Верится с трудом.
LD>>делать для всех пар подобных функций... A>А их разве очень много? и потом, никто не говорил что дуракоустойчивую библиотеку написать так же легко.
Дело не в сложно/несложно. Не сложнее чем компилятор. Непонятно зачем это нужно.
LD>>И чего добьемся в результате? Программы с трудные для отладки, с плохоповторяемым поведением... A>Пояснишь? А то я не понял из чего ты сделал вывод о трудноотлаживаемости.
Исключительно из опыта. Замаскированная ошибка может выявиться на очень поздних стадиях разработки. А стоимость отладки и устранения ошибок возрастает очень быстро при удалении от начала разработки.
Чтобы приложение не падало. Пусть себе пишет в log файл что была попытка закрыть несуществуещий дескриптор. Скажешь не лучше?
LD>Исключительно из опыта. Замаскированная ошибка может выявиться на очень поздних стадиях разработки. А стоимость отладки и устранения ошибок возрастает очень быстро при удалении от начала разработки.
Надо анализировать как прошло выполнение fclose и если была ошибка логгировать её. Я по лог-айлам отлаживал программу на компьютере к ткоторому не имел доступа. Искажу прямо — очень было удобно. Со всякими Watch/Breakpoint было бы намного хуже.
Здравствуйте, Kemm, Вы писали:
K>Когда и unix-like ОС начнут действовать по принципу M$^H^H "если наши функции не соответствуют стандарту — тем хуже для стандарта", то я уже даже и не знаю, куды бечь надо будет. В другую вселенную, не иначе.
В данном случае расширение касается Undefined Behavior и я не понимаю по какому поводу паника? Вай-вай-вай, где же мой UB?
K>Детский сад — это писать код, не соответствующий стандарту. Мне куда дороже более быстрое выполнение (даже если это 1 процент, хотя может быть значительно больше в Вашем случае), чем детские ошибки. gcov + valgrind творят чудеса, к сведению.
Детский сад это думать что кто-то намеренно пишет такой код. Лог файлы на клиентских машинах творят куда бОльшие чудеса, чем любые утилитки на машине разработчика. Пиши в логи всякий раз когда fclose будет вызвана не к месту. Тебе информация к размышлению, клиенту программа которая не валится. Религия не позволяет использовать или как?
Здравствуйте, adontz, Вы писали:
LD>>Дело не в сложно/несложно. Не сложнее чем компилятор. Непонятно зачем это нужно. A>Чтобы приложение не падало. Пусть себе пишет в log файл что была попытка закрыть несуществуещий дескриптор. Скажешь не лучше?
Напиши обертку вокруг fopen()/fclose(), которая этим будет заниматься. Медленнее не будет, зато будет правильно. А то в лог писать... В какой лог, простите?..
Здравствуйте, Kemm, Вы писали:
K>Расскажите об этом разработчикам встроенных систем всякого рода. Вы их осчастливите запасом хорошего настроения на день. От хохота.
Вот я на днях буду для смартфона писать. На .Net Compact Framework. Ну думаю понятно
K>Тьфу, тестеров нанять. Которые будут в том числе отслеживать code coverage тестами. Ну и valgrind в зубы, для кумплекту. А то так и утечки памяти спишете на "кривую реализацию".
Лог-файлы обойдудтся дешевле команды тестеров, а информации при должном использовании дадут больше.
Здравствуйте, adontz, Вы писали:
K>>Когда и unix-like ОС начнут действовать по принципу M$^H^H "если наши функции не соответствуют стандарту — тем хуже для стандарта", то я уже даже и не знаю, куды бечь надо будет. В другую вселенную, не иначе. A>В данном случае расширение касается Undefined Behavior и я не понимаю по какому поводу паника? Вай-вай-вай, где же мой UB?
Нет. Вай-вай-вай, какого черта вот в этом вот месте этот трижды проклятый someOS не соответствует стандарту? А, решили, что можно произвольно реализовывать все, а не только UB...
K>>Детский сад — это писать код, не соответствующий стандарту. Мне куда дороже более быстрое выполнение (даже если это 1 процент, хотя может быть значительно больше в Вашем случае), чем детские ошибки. gcov + valgrind творят чудеса, к сведению. A>Детский сад это думать что кто-то намеренно пишет такой код.
Еще раз: Тестировать надо. Во всех позах. С использованием утилит, показывающих покрытие исходного текста тестами.
A>Лог файлы на клиентских машинах творят куда бОльшие чудеса, чем любые утилитки на машине разработчика. Пиши в логи всякий раз когда fclose будет вызвана не к месту.
my_fopen()/my_fclose() в помощь, если уж приспичило. Да, а еще покажите мне, как логировать, чтобы отслеживать пресловутые memory leaks, раз уж Вы так утилиты на машинах разработчиков и тестеров не любите.
A>Тебе информация к размышлению, клиенту программа которая не валится. Религия не позволяет использовать или как?
Религия мне не позволяет считать свое видение проблемы единственно верным. И пока есть реализации, не соответствующие ему — кричать на всю ивановскую "кривизна".
LD>>Верится с трудом. A>http://www.google.com/search?q=lock+free+list
Лень углубляться посмотрел несколько первых ссылок. Нигде настоящего lock-free списка не релиизована. Везде основываются на атомарность compare-and-swap. Ниже типичная цитата. Подавляющее большинство аппаратных архитектур такой роскоши не имеют.
Prior list-based lock-free set algorithms involve one or more
serious problems: dependence on the DCAS (double-compareand-
swap)1 atomic primitive that is not supported on any
current processor architecture [5, 14], susceptibility to livelock
[25], and/or dependence on problematic memory management
methods [6, 14, 25] (i.e., memory management methods
that are impractical, very inefficient, blocking (not lockfree),
and/or dependent on special operating system support).
The use of universal lock-free methodologies [1, 2, 8, 11,
22, 24] for implementing hash tables or sets in general is too
inefficient to be practical.
This paper presents a lock-free list-based set algorithm that
we use as a building block of a lock-free hash table algorithm.
The algorithm is dynamic, allowing the object size
and memory use to grow and shrink arbitrarily. It satisfies
the linearizability correctness condition [9].
It uses CAS (compare-and-swap) or equivalently restricted
LL/SC (load-linked/store-conditional)
LD>>Дело не в сложно/несложно. Не сложнее чем компилятор. Непонятно зачем это нужно. A>Чтобы приложение не падало. Пусть себе пишет в log файл что была попытка закрыть несуществуещий дескриптор. Скажешь не лучше?
Лучше конечно, никаких сомнений даже быть не может. Только как это сделать? Чтоб всех устроило.
K>>Тьфу, тестеров нанять. Которые будут в том числе отслеживать code coverage тестами. Ну и valgrind в зубы, для кумплекту. А то так и утечки памяти спишете на "кривую реализацию".
A>Лог-файлы обойдудтся дешевле команды тестеров, а информации при должном использовании дадут больше.
Очень может быть, но причем тут стандартная либа?
Здравствуйте, Kemm, Вы писали:
K>Напиши обертку вокруг fopen()/fclose(), которая этим будет заниматься. Медленнее не будет, зато будет правильно. А то в лог писать... В какой лог, простите?..
Да хоть в файл. Хотя БД конечно лучше, но просто не всегда есть.
K>>Напиши обертку вокруг fopen()/fclose(), которая этим будет заниматься. Медленнее не будет, зато будет правильно. А то в лог писать... В какой лог, простите?..
A>Да хоть в файл. Хотя БД конечно лучше, но просто не всегда есть.
Здравствуйте, adontz, Вы писали:
K>>Расскажите об этом разработчикам встроенных систем всякого рода. Вы их осчастливите запасом хорошего настроения на день. От хохота. A>Вот я на днях буду для смартфона писать. На .Net Compact Framework. Ну думаю понятно
Вы-таки удивитесь, но встроенные системы — это не только смартфоны/КПК и прочие фоны. Да и вообще не они. 8))
K>>Тьфу, тестеров нанять. Которые будут в том числе отслеживать code coverage тестами. Ну и valgrind в зубы, для кумплекту. А то так и утечки памяти спишете на "кривую реализацию". A>Лог-файлы обойдудтся дешевле команды тестеров, а информации при должном использовании дадут больше.
А Вы не подскажете компанию, в которой принят такой подход? Чтоб не купить ничего ненароком...
Было у нас раньше примерно так же, по вине руководства, которое к программированию имело примерно столько же отношения, сколько я к ядерной энергетике. Кончилось, когда жареный петух клюнул и "дело запахло вазелином"(с). До сих пор вспоминаем эту эпохальную фразу начальника: "Зачем нам тестеры? И так все нормально...". С какими мыслями вспоминаем, приводить не буду по цензурным соображениям. До сих пор нормальное тестирование построить не можем, хотя легче стало намного.
Да, ценность логов отрицать я не собираюсь, это просто-напросто глупо. Только не являются они серебряной пулей ни разу. Просто один из равноправных инструментов.
Здравствуйте, LelicDsp, Вы писали:
LD>>>Верится с трудом. A>>http://www.google.com/search?q=lock+free+list LD>Лень углубляться посмотрел несколько первых ссылок. Нигде настоящего lock-free списка не релиизована. Везде основываются на атомарность compare-and-swap. Ниже типичная цитата. Подавляющее большинство аппаратных архитектур такой роскоши не имеют.
Проблемы не увидел. Для x86 это одна команда процессора. Обменять по условию 1, 2, 4 байт — CMPXCHG (поддерживается начиная c 486), 8 байт CMPXCHG8B (поддерживается начиная c Pentium I)
Здравствуйте, Kemm, Вы писали:
K>Нет. Вай-вай-вай, какого черта вот в этом вот месте этот трижды проклятый someOS не соответствует стандарту? А, решили, что можно произвольно реализовывать все, а не только UB...
Я говорил только об UB.
K>Религия мне не позволяет считать свое видение проблемы единственно верным. И пока есть реализации, не соответствующие ему — кричать на всю ивановскую "кривизна".
Пока что ты борешься за реализацию с никому не нужным UB.
