Типичные ошибки при написании программ.

[Dale]

Мне опять не удалось донести свои оценки и результаты своих размышлений.
Вижу 2 возможные причины
1. Моя косноязычность
2. Мои проблемы и размышления действительно не стоят выеденного яйца, а тем более затраченного на это времени.

Я бы отдал приоритет третьей причине.

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

Ей-богу, господа, большинство статей Дейкстры по объему короче высказываний вашего дуэта. Я уж не говорю о широте охвата, тут мэтр просто отдыхает. Давайте перед тем, как попытаться наладить отношения с талантом, попробуем сначала подружиться с его сестрой. Помилосердствуйте, если Вы действительно хотите, чтобы другие были способны реально это все прочитать, осмыслить и высказать свои соображения.

Конкретные предложения? Тут я полностью солидарен с Полиграфом Полиграфовичем:

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

Давайте делить, чтобы голова не пухла.

[Dimka]

Вы действительно используете формальные методы доказательства корректности Ваших программ на Си, Яве или даже Паскале? Или без анализа своего кода уверенны в его правильности?

1) Иногда, но крайне редко. 2) Процесс написания и проверки обычно совпадают. Тем не менее, иногда возникают ситуации, когда нужно перечитать ранее написанный код, чтобы "освежить память". Поэтому я отвечу: когда как. Есть ряд случаев (например, использование сторонних малознакомых библиотек), когда я сильно сомневаюсь в правильности того, что пишу - тогда надо попробовать в работе (по сути тестирование). В своём собственном коде обычно уверен в гораздо большей степени. Но от невнимательности никто не застрахован - я ж не машина.

[ezus]

Dale
Абсолютно верно, извинением мне может быть только желание впихнуть необъятное в маленькую коробочку.
Отбросим теоретизированию и умствование на общие темы.

Конкретное предложение.
Существуют сборники различных готовых приемов программирования почти на все случаи жизни.
Предлагаю опытным и не очень программистам поучаствовать в составлении "сборника" различных приемов думания над программой.

Эти приемы могут быть примитивны, и у опытных программистов уже перешли на уровень подсознательного автоматизма, тем интересней будет их от туда выудить и вербализовать.
Если это вообще кому-либо надо.

Приведу примеры.
1. Есть цикл и индекс по массиву.
С индексем связаны 3 операции:

• присвоение начального значение - "0" или "-1"(для Си)
• инкремент - в начале тела или в конце
• использоание индекса по выходу из цикла - "i" или "i-1"

Умственные затраты и ошибки будут существенно меньше, если сначала задать себе вопрос:
"На ЧТО указывает индекс перед входом в тело цикла?"

На первый свободный элемент, первый необработанный
или
Последний занятый, последний обработанный.

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

Если индекс указывает на первый пустой, то ответы: 0, в конце, i-1.
Если на последний обработанный, то: -1, в начале, i.

Похожий вопрос может быть полезен для перемещению указателя по спискам и т.п.

2. Есть несколько вложенных объектов: объект А содержит множество объектов В, В содержит ряд объектов С, а С - D.
Есть также составная фунциональность типа суммирования, состоящая из 3 частей: обнуление счетчика, прибавление очередной дельты, вывод результата.

Размещению этих частей в теле программы поможет ответ на вопрос:
"Сколько раз мне надо выполнить эту часть?" с ответом типа "столько же сколько раз будет встречатся соответствующий объект".

3. Приемы анализа типа "упрощение" и "конкретизации".

И тому подобное.

[Dale]

Приведу примеры.
1. Есть цикл и индекс по массиву.
С индексем связаны 3 операции:

• присвоение начального значение - "0" или "-1"(для Си)
• инкремент - в начале тела или в конце
• использоание индекса по выходу из цикла - "i" или "i-1"

Умственные затраты и ошибки будут существенно меньше, если сначала задать себе вопрос:
"На ЧТО указывает индекс перед входом в тело цикла?"

На первый свободный элемент, первый необработанный
или
Последний занятый, последний обработанный.

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

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

Мне представляется, главная причина здесь кроется в большом семантическом разрыве между высокоуровневыми объектами (не в смысле ООП) реальной задачи (перечень неких сущностей, которые должны быть обработаны в цикле единообразно) и их низкоуровневым представлением в виде массива на языке C (смежная область ячеек оперативной памяти, выделенная для хранения элементов массива и адресуемая при помощи индекса, который по сути является адресом ячейки.

Если должны быть обработаны все элементы, есть прекрасная возможность избежать этой ошибки в принципе - заменить такой массив коллекцией. В современных языках программирования имеется богатый выбор реализации таких коллекций и идиомы работы с ними через итераторы. А в том же C# имеется оператор foreach, который гарантированно перебирает все элементы коллекции без явного участия индексов. Возможно, этот подход применим не в 100% случаев, но там, где он уместен, им стоит воспользоваться.

Таким образом, вместо первоначального вопроса "На ЧТО указывает индекс перед входом в тело цикла?" имеет смысл задаться вопросом: а действительно ли индекс необходим для решения данной задачи, или это лишь вспомогательное средство, навязанное нам конкретным отображением сущностей решаемой задачи на низкоуровневую архитектуру вычислительной системы?

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

P.S. Именно поэтому я и призывал перейти к рассмотрению конкретных типичных классов ошибок, а не некоей абстрактной "сферической ошибки в вакууме", с которой и бороться-то непонятно как. Хорошо, что это наконец было услышано.

[Dale]

2. Есть несколько вложенных объектов: объект А содержит множество объектов В, В содержит ряд объектов С, а С - D.
Есть также составная фунциональность типа суммирования, состоящая из 3 частей: обнуление счетчика, прибавление очередной дельты, вывод результата.

С этого места ясность пропала. "Конгресс, немцы какие-то..."

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

[ezus]

Таким образом, вместо первоначального вопроса "На ЧТО указывает индекс перед входом в тело цикла?" имеет смысл задаться вопросом: а действительно ли индекс необходим для решения данной задачи, или это лишь вспомогательное средство, навязанное нам конкретным отображением сущностей решаемой задачи на низкоуровневую архитектуру вычислительной системы?

Почему "вместо"? Это 2 равноправных вопроса.

Сначала Ваш.
А потом, если ответ на него "Да, индехс необходим, т.к. подходящих стандартных средст не нашлось", то возникает мой.

Кроме того, это не всегда индексы. Это может быть указатель на элементы в цепочке-списке. это может быть гипер-ссылка при циклической обработке страниц.

Суть вопроса от этого не меняется.

P.S. Именно поэтому я и призывал перейти к рассмотрению конкретных типичных классов ошибок, а не некоей абстрактной "сферической ошибки в вакууме", с которой и бороться-то непонятно как.

Частные примеры, конечно, полезны. Но на их основе редко произрастают большие идеи. Для этого все-таки надо иногда подниматься до уровня [абстрактной "сферической ошибки в вакууме"/i]

[Dale]

Кроме того, это не всегда индексы. Это может быть указатель на элементы в цепочке-списке. это может быть гипер-ссылка при циклической обработке страниц.

Суть вопроса от этого не меняется.

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

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

А что касается больших идей, вырастающих из частностей, то одну из них мы сами подробно обсудили - проблема оператора GOTO. При поверхностном подходе это такой же оператор, как и любой другой. Сторонник обобщения сказал бы: а что это вы привязались к одному несчастному оператору? Давайте тогда уж все искореним. И быб бы неправ.

[Dale]

Почему "вместо"? Это 2 равноправных вопроса.

Сначала Ваш.
А потом, если ответ на него "Да, индехс необходим, т.к. подходящих стандартных средст не нашлось", то возникает мой.

По-моему, нелогично получается.

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

[ezus]

По-моему, нелогично получается.

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

Ну, хорошо.
Если это так важно для понимания проблемы, то Ваш вопрос важнее.

[Dale]

Кстати, легко ли подобрать пример, когда использование в цикле массива действительно предпочтительнее коллекции с итераторами? Я навскидку затрудняюсь привести.

[ezus]

Кстати, легко ли подобрать пример, когда использование в цикле массива действительно предпочтительнее коллекции с итераторами? Я навскидку затрудняюсь привести.

Например, буфер в виде массива с прямым методом доступа по индексу: код цеха, номер месяца или код символа при работе с текстами. В этом случае вспомогательные функции типа загрузки и выгрузки буфера, специальный поиск по буферу будут требовать классического цикла.

[Dale]

Например, буфер в виде массива с прямым методом доступа по индексу: код цеха, номер месяца или код символа при работе с текстами. В этом случае вспомогательные функции типа загрузки и выгрузки буфера, специальный поиск по буферу будут требовать классического цикла.

Контейнеры вроде класса vector из STL для C++ или List из .NET Framework предоставляют произвольный доступ к своим элементам по индексам и в то же время поддерживают работу с итераторами, то есть позволяют обойтись без полного перебора по индексу в цикле типа for. Мне кажется, это неудачный пример.

[Dimka]

Давайте сравним записи переборных циклов (типа FOR) на разных языках программирования и попытаемся понять семантику:

Код: (Text)

FOR I=1 TO N STEP 1
NEXT I

В одной конструкции задание начального значения, размер инкремента. Смысл конечного значения N неочевиден, если между начальным и конечным значением не умещается целое число шагов.

Код: (C++)

for(int i=0; i<N; ++i) {}

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

Код: (Text)

1 to: N do: [ :n | ]

Неочевидная семантика на уровне объектов, хотя очевидная на уровне чтения кода человеком. У числа определяется метод перебора до следующего числа с выполнением на каждом шаге параметризированного блока кода.

Код: (Ruby)

N.times {}

Буквально переводится "N раз". Очевидно, но не всегда удобно, поскольку внутри блока кода нет счётчика итераций.

Код: (Ruby)

(1..N).each { | i | }

Определяется новая сущность - region как интервал на упорядоченном конечном множестве (целых чисел, символов и т.п.). Для каждого элемента множества выполняется параметризированный блок.

По-моему, последний вариант - самое точное выражение для цикла FOR, которое ближе всего по смыслу к вышеупомянутому "безопасному" циклу типа FOR EACH. В конструкциях старых языков так или иначе "торчат уши" цикла WHILE, особенно в C, где цикл FOR - не более, чем "синтаксический сахар".

[baldr]

Хочу возразить вот на этот пример:

Код: (Ruby)

N.times {}

Буквально переводится "N раз". Очевидно, но не всегда удобно, поскольку внутри блока кода нет счётчика итераций.

Счетчик итераций есть:

Код: (Ruby)

3.times { |i| puts i }

[Dimka]

baldr, ну тогда хорошо. Правда, range удобнее в том смысле, что правая и левая границы задаются произвольно, да ещё ко всему прочему могут быть не только целыми числами, но и символами, и даже строками.

[Антон (LogRus)]

Кстати, легко ли подобрать пример, когда использование в цикле массива действительно предпочтительнее коллекции с итераторами? Я навскидку затрудняюсь привести.

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

перебор же элементов с шагом 1, практически всегда можно реализовать используя range, а не индекс
в другой теме мы уже затрагивали этот вопрос
собственно большинство (если не все) алгоритмов stl так и делают
мне проще в коде

Код: (C++)

for(T::iterator it = begin; it != end; ++it)
{
.....................
}

что такое begin и end не важно, важно, что они:
1. указывают на интересующие нас данные
2. их можно сравнить не > или < (это не всегда возможно), а именно == или !=
3. позволяют переходить к следующему элементу

Кстати, легко ли подобрать пример, когда использование в цикле массива действительно предпочтительнее коллекции с итераторами? Я навскидку затрудняюсь привести.

Например, буфер в виде массива с прямым методом доступа по индексу: код цеха, номер месяца или код символа при работе с текстами. В этом случае вспомогательные функции типа загрузки и выгрузки буфера, специальный поиск по буферу будут требовать классического цикла.

это заблуждение из заблуждений, совершенно спокойно можно итерироваться без индекса, при загрузке выгрузке и т.д. и т.п.
одни из частых задач, когда нужен индекс, а точнее произвольный доступ к элементу (это разные вещи)
1. быстрая сортировка
2. быстрый поиск в отсортированном массиве или коллекции (не говорим про ассоциативные контейнеры)
слово "быстро" тут ключевое, т.к. для решения этих задач не обязательно иметь произвольный доступ, если нам не важна скорость или объёмы данных ничтожны

ps: ezus, у меня складывается ощущение, что Вы очень давно не программировали

[baldr]

baldr, ну тогда хорошо. Правда, range удобнее в том смысле, что правая и левая границы задаются произвольно, да ещё ко всему прочему могут быть не только целыми числами, но и символами, и даже строками.

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

[RXL]

Можно я свои пять копеек вставлю?

Код: (Perl)

for ($i = M; $i <= N; $i++) { }

for $i (M..N) { }

for (M..N) { }

map { } (M..N);

[Dale]

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

Я к этой мысли и пытался подвести автора темы, но без особого успеха.

Вообще, чтобы эта дискуссия не была простым сотрясением воздуха, пора бы подвести какие-то итоги. Я предлагаю такой вариант.

Задача: Необходимо выполнить сходные действия над совокупностью неких сущностей.

Решение: Объединить сущности в массив, затем в цикле типа пересчета (for) перебрать все элементы массива по индексам и выполнит над каждым элементом требуемые действия.

Типичные ошибки: неправильное задание диапазона индекса (например, в массиве из N элементов индексы перебираются от 1 до N, в то время как фактически в языке C индексы должны принимать значения от 0 до N-1); кроме того, в языках, где вместо явной верхней границы цикла применяется условие продолжения, возможна ошибка при записи этого условия (например, i<=N вместо i<N).

Следствия: в случае ошибочного задания границ цикла либо будут пропущены крайние элементы массива (наиболее вероятно, первый и/или последний), либо будет предпринята попытка обработать несуществующие элементы. В последнем случае все зависит от реализации исполняющей системы: если она умеет контролировать выход индекса массива за границы и ей это дозволено, возникнет ошибка времени выполнения; если же нет, то вместо реальных данных будет обработан случайный мусор из смежных областей памяти с непредсказуемым результатом.

Способы избежать ошибки: безусловно, можно проявлять повышенную бдительность при задании границ цикла, в котором будут обрабатываться элементы массива. А можно сделать подобные ошибки невозможными в принципе, если вместо низкоуровневых массивов использовать более подходящие коллекции. При этом можно воспользоваться конструкцией автоматического перебора всех элементов коллекции, вовсе не используя индексы: применить либо оператор типа foreach, если таковой имеется в языке, либо аналогичную идиому с использованием итераторов в противном случае.

Резюме: проблема представляется мне столь же искусственной, сколь и проблемы, связанные с оператором GOTO: зачастую мы сначала создаем ее сами, затем боремся с переменным успехом. Во многих случаях правильный выбор как более безопасных структур данных, так и соответствующих операторов делает ее неактуальной.

ezus, если Вы еще не утратили интерес к собственной теме, предлагаю проанализировать еще какой-нибудь класс типичных ошибок. Например, что-то вроде  обращения по указателю null, или другой, на Ваш выбор.

[Антон (LogRus)]

тему переименовываем в "типичные ошибки"?

[Dale]

Да, так явно уместнее было бы. Нынешнее название уж больно философское и как-то ни к чему не обязывает.

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

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

[ezus]

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

ps: ezus, у меня складывается ощущение, что Вы очень давно не программировали

Это не совсем так.
После смены 10 лет назад своего места жительства и соответственно статуса, мне пришлось вернуться к классическому программированию. Сначала 4 года на ABAP/4, потом 4 года на Java, и вот последние 2 года, после почти 20 летнего перерыва опять окунулся в С\С++.
Причем в систему, которую разрабатывали до этого тоже почти 20 лет, а это MS VS C++ 6.0 + MFC. Причем о смене платформы или даже библиотек не может быть и речи. Система насчитывает более 15 тысяч исходных файлов ( 850 мегабайт ), причем некоторые  файлы размером до 20 тысяч строчек. Многие модули были написаны просто на С. Причем основная масса текста была написана программистами-пользователями, а не программистами-профессианалами (по моей классификации, которую я приводил ранее). А это накладывает неизгладимый отпечаток  на стиль. Кроме того, проповедуется в общем-то неплохой принцип: не трожь то, что дышит. Но он развит далее: "все изменения и дополнения делай в уже принятом стиле" - и хрен с того, что стилю 20 лет?

Поэтому, я думаю, понятно, почему в моих рассуждениях нет этих  foreach, итераторов и коллекций. Кроме того, я приводил пример НЕ того как ПИСАТЬ, а пример того как ДУМАТЬ.

Да, так явно уместнее было бы. Нынешнее название уж больно философское и как-то ни к чему не обязывает.
Заодно хорошо бы переместить ее в более подходящий раздел. Идея поместить ее по соседству с обсуждением сортов пива и опросом по поводу диет, по-моему, была не самой блестящей.
Впрочем, тему не я придумал, так что хорошо бы выслушать мнение автора.

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

Я задумывал нечто другое - не "Типичные ошибки при написании программ", а "Типичные ошибки при размышлении над программой". Но может быть в новой ипостаси она принесет больше пользы.

ezus, если Вы еще не утратили интерес к собственной теме, предлагаю проанализировать еще какой-нибудь класс типичных ошибок. Например, что-то вроде  обращения по указателю null, или другой, на Ваш выбор.

Вы предложили, на мой взгляд, очень хороший анализ, и было бы не плохо развить этот успех.
Действительно новая тема это кое-что другое. Мой интерес к ней не пропал, но изменился.
Сейчас она меня интересует больше как простого потребителя конкретных рекомендаций. В то время как прошлая тема интересовала меня именно в "филофском" аспекте, т.к. я считаю, что ЗНАТЬ, УМЕТЬ и ПОНИМАТЬ - это разные вещи.

[Dimka]

Кроме того, проповедуется в общем-то неплохой принцип: не трожь то, что дышит.

Система насчитывает более 15 тысяч исходных файлов ( 850 мегабайт ), причем некоторые  файлы размером до 20 тысяч строчек.

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

Кроме того, я приводил пример НЕ того как ПИСАТЬ, а пример того как ДУМАТЬ.

А это не одно и то же? Часто мы думаем на языке; формы языка определяют формы мысли.

[RXL]

Мне тоже по работе приходится поддерживать старое ПО, которому более 10 лет (точно не известно - возможно 10-12 лет). Проектирования не было в помине. Писали не профессиональные программисты-одиночки (ezus, по твоей классификации), куда и себя причисляю. Язык/диалект/среда - Borland C++ Builder. Более сотни модулей на "сумму" 10 МБ (без учета сторонних библиотек), где GUI, данные, логика, SQL и система отчетов перемешаны в кучу. Тоже использую принцип "работает - не трожь", но когда необходимо модифицировать модуль, то первым делом форматирую его код (редактор BCB помогает ленивым создавать ужасно сформатированный, нечитаемый код), изучаю и переписываю. Самое плохое, когда модули взаимосвязанные и обмен данными происходит через свойства GUI-компонентов по числовому индексу. Так вот постепенно уменьшаю энтропию.

[Алексей++]

Так вот постепенно уменьшаю энтропию.

которая, как известно, не уменьшается в принципе

[RXL]

Еще как уменьшается. Не линейно и не к полному нулю, но уменьшается.

[Dimka]

которая, как известно, не уменьшается в принципе

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

[Алексей++]

Рома, теперь я за тебя буду волноваться ((

[RXL]

Dimka, это парадокс, но я сам сплошная энтропия

[Dale]

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

ezus, с возвращением (а заодно, надеюсь, с выздоровлением). Очень интересно пообщаться с человеком, который знаком с другими платформами, кроме IBM PC, и размышляет о том, что делает, не на уровне кнопочек на формочках. Надеюсь, тема не будет зафлужена окончательно.

Поэтому, я думаю, понятно, почему в моих рассуждениях нет этих  foreach, итераторов и коллекций. Кроме того, я приводил пример НЕ того как ПИСАТЬ, а пример того как ДУМАТЬ.
...
Я задумывал нечто другое - не "Типичные ошибки при написании программ", а "Типичные ошибки при размышлении над программой".

Видимо, я упустил что-то главное. Пример, который я анализировал (массивы и т.п.), сам по себе был довольно низкоуровневым. Речь там шла не о предметной области, а о ее отображении на среду программирования уровня 70-х - 80-х годов. Поэтому и анализ свелся к тому, что сегодня эти проблемы просто не возникают, нет для них почвы. Если мы вернемся в 50-е и вновь начнем программировать в кодах, мы получим еще больше проблем. Но вызваны они будут не сложностью задачи как таковой, а несовершенством инструментов, которыми мы пытаемся их решать.

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

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

Да, симптом действительно неважный. Впрочем, давайте уж довольствоваться тем, что есть.