Здравствуйте, Ikemefula, Вы писали:
E>>Другие в данном случае идут лесом. Я прочитал статью сам. Т.е. автор посредством статьи общался со мной. Следовательно, автор не смог _мне_ объяснить суть статьи.
I>Да, а с точки зрения тех, кто понял и с т.з. автора это ты не смог прочитать и понять
пункт второй.
E>>После наводящих вопросов выяснилось, что это деление важно с точки зрения продавца ПО. Что для меня явилось открытием.
I>В статье был небольшой ликбез, на пальцах, потому как девелоперы не являются проф. маркетологами например.
Статья, которой требуются дополнительные комментарии для того, чтобы указать, что там был этот ликбез либо написана о чем-то другом, либо настолько раздута, что ликбез там просто потерялся.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IB, Вы писали:
IB>Да еще эта непрекрытая демагогия в каждом сообщении, аж тошнит.
Я, кстати, заметил, что демагоги любят поминать в своих комментах демагогию. Т.е. чем больше слов с корнем "демагог" в сообщении, тем круче комментатор как демагог. Как я понял, это такой демагогический приём демагога, когда оппонент демагога объявляется демагогом. Я прав или я прав или я прав?
Здравствуйте, lomeo, Вы писали:
L>Я, кстати, заметил, что демагоги любят поминать в своих комментах демагогию. Т.е. чем больше слов с корнем "демагог" в сообщении, тем круче комментатор как демагог. Как я понял, это такой демагогический приём демагога, когда оппонент демагога объявляется демагогом.
Это демагогический прием направленный на то, чтобы демагога нельзя было уличить в демагогии? Как и всякая демагогия — фигово работает.
L>Я прав или я прав или я прав?
Нет, не прав.
Здравствуйте, netch80, Вы писали:
N>Я не смог найти такого утверждения в документации на strtod. Где Вы его нашли? И я прошу Вас быть точным в терминологии, ибо: N>NUL — ASCII название символа с кодом 0 N>NULL — в Си указатель со специальным значением "никуда" N>null — такого в данном контексте нет и что Вы имели в виду — непонятно.
Не надо притворяться, все Вам прекрасно понятно. Ссылка указывает на описание фирмы Микрософт и там сказано:
Parameters
nptr
Null-terminated string to convert.
1. An initial, possibly empty, sequence of white-space characters (as specified by isspace())
2. A subject sequence interpreted as a floating-point constant or representing infinity or NaN
3. A final string of one or more unrecognized characters, including the terminating null byte of the input string
И с точки зрения здравого смысла — на фиг не нужно искать этот null — как только встретился первый невалидный символ, надо остановиться. Я думаю, что наиболее вероятная причина такого косяка — элементарная небрежность. Так же возможно, что человек не в ладах с формальной логикой и интерпретировал фразу (3) как типа "строка должна быть null-terminated".
Но еще раз подчеркну — это просто пример граблей на ровном месте, которых разложено везде и повсюду. Я их просто не коллекционирую — не очень-то мне это надо.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Нет, требует. Смотрим в начало статьи по Вашей ссылке:
These functions shall convert the initial portion of the string pointed to by
Теперь, если поискать смысл слова "string", который в том же Posix определён так (в Base Definitions -> Definitions):
3.367 String
A contiguous sequence of bytes terminated by and including the first null byte.
получается, что формально они правы: то, что не содержит "null byte" — не string и результат применения к ней string — не документирован, то есть undefined behavior.
MS>И с точки зрения здравого смысла — на фиг не нужно искать этот null — как только встретился первый невалидный символ, надо остановиться. Я думаю, что наиболее вероятная причина такого косяка — элементарная небрежность. Так же возможно, что человек не в ладах с формальной логикой и интерпретировал фразу (3) как типа "строка должна быть null-terminated".
То, что Вы говорите — вопрос _оптимизации_. Чисто формально они имели право так сделать.
MS>Но еще раз подчеркну — это просто пример граблей на ровном месте, которых разложено везде и повсюду. Я их просто не коллекционирую — не очень-то мне это надо.
Вообще-то вопрос про strtod — только один из и не самый важный. Вы не могли бы более внятно объяснить, что не нравится в семействе функций ISO TR 24731?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали: N>>Согласен, правлю формулировку: в средних по отрасли формулировках, а не MS, и всё равно при этом принципиально, что null character (в таком случае null — общепринятое прилагательное), а не просто null. S>Это передёргивание. McSeem2 критикует поведение функции в соответствии с её официальной документацией.
В соответствии с какой именно официальной документацией?
1. ISO/IEC 9899:1999 (стандарт Си, фактически, единственное что можно считать официальной документацией): текст описания strtod() практически дословно соответствует тому, что приведено для Posix (цитату выдрать не могу — на работе только xpdf). Единственное что сомнительно — я в нём не нашёл определения понятия "string", но, может, плохо искал.
2. Приведённая ссылка на Posix не является официальной документацией — MS не заявляла поддержку Posix для CRT.
3. Несоответствия описанию на MSDN нет.
Так что именно не так? Расхождения не найдено, поведение как в CRT допустимо. Неоптимально — да, согласен, но формально ничему не противоречит.
S> Требовать в форумной дискуссии fully qualified name на каждый чих — перебор.
Давайте я всё-таки изложу детальнее, раз так не понимаете. В исходном письме McSeem2 было не одно, а два понятия, которые оба как минимум сомнительно соответствуют стандартам и практике:
1) null (без объяснения, что это null character или что-то другое)
2) "невалидный" символ
Поодиночке я бы проигнорировал, но вместе они создают достаточно основания, чтобы детально уточнить, что имелось в виду по каждому.
В общем, ответ я уже от него получил и к этому вопросу можно не возвращаться.
N>>И ещё всё-таки интересны причины нападок именно на MS за кросс-вендоровский ISO TR 24731. S>А ISO TR 24731 разве регламентирует бездумное применение strlen внутри strtod? Или он описывает только внешний интерфейс?
Он описывает внешний интерфейс для аналогов функций из <string.h> и я не понимаю, к чему Вы упоминаете strtod() в этом контексте.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Sinclair, Вы писали:
S>>А ISO TR 24731 разве регламентирует бездумное применение strlen внутри strtod? Или он описывает только внешний интерфейс?
N>Он описывает внешний интерфейс для аналогов функций из <string.h>
и семантику тоже, конечно — что там не должно быть доступа за пределы указанного диапазона.
N> и я не понимаю, к чему Вы упоминаете strtod() в этом контексте.
Здравствуйте, netch80, Вы писали:
N>получается, что формально они правы: то, что не содержит "null byte" — не string и результат применения к ней string — не документирован, то есть undefined behavior.
Похоже у Вас тоже не лады с формальной логикой. Там, по ссылке совершенно однозначно сказано, что функция прекращает сканирование на первом встретившемся non-digit символе, который, в частности может быть null-byte. Вызывать strlen — это просто противоречит спецификации и здравому смыслу.
N>Вообще-то вопрос про strtod — только один из и не самый важный. Вы не могли бы более внятно объяснить, что не нравится в семействе функций ISO TR 24731?
Ни малейшей дополнительной безопасности эти функции не дают, но приводят к головной боли по поводу совместимости на разных платформах. Но я не против их существования, а у Вас похоже и здесь проблемы с пониманием. Я назвал идиотизмом объявление старых строковых функций как deprecated, а не просто наличие новых. От новых функций как таковых мне ни жарко ни холодно. Вот только не надо убирать старые. Я делаю предсказание, что этот идиотский варнинг так и останется навечно вместе с функциями типа strcpy. И старые функции никогда не перейдут из категории deprecated в категорию prohibited-на-фиг.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, netch80, Вы писали:
MS>>И с точки зрения здравого смысла — на фиг не нужно искать этот null — как только встретился первый невалидный символ, надо остановиться. Я думаю, что наиболее вероятная причина такого косяка — элементарная небрежность. Так же возможно, что человек не в ладах с формальной логикой и интерпретировал фразу (3) как типа "строка должна быть null-terminated".
N>То, что Вы говорите — вопрос _оптимизации_. Чисто формально они имели право так сделать.
Ни фига себе — "вопрос _оптимизации_"! Если мне надо распарсить длинную строку с использованием strtod, то я тут же вместо O(N) получаю O(N^2). Извините, но O(N^2) на ровном месте — это 100%-ное ламерство.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, netch80, Вы писали:
N>>получается, что формально они правы: то, что не содержит "null byte" — не string и результат применения к ней string — не документирован, то есть undefined behavior.
MS>Похоже у Вас тоже не лады с формальной логикой. Там, по ссылке совершенно однозначно сказано, что функция прекращает сканирование на первом встретившемся non-digit символе, который, в частности может быть null-byte. Вызывать strlen — это просто противоречит спецификации и здравому смыслу.
Вы сможете утверждать про "нелады с формальной логикой", если покажете по данной ссылке хоть одно место, где сказано, что данная функция не имеет права анализировать текст дальше первого непонятого символа. На сейчас Вы это не доказали.
Про несоответствие здравому смыслу я не буду спорить, а вот с несоответствием спецификации не соглашусь, пока не докажете (ой сомневаюсь).
N>>Вообще-то вопрос про strtod — только один из и не самый важный. Вы не могли бы более внятно объяснить, что не нравится в семействе функций ISO TR 24731? MS>Ни малейшей дополнительной безопасности эти функции не дают,
Дают. Не сами по себе, а тем, что поощряют правильный стиль и позволяют легко обеспечить проверку корректности их применения, в отличие от старого семейства (особенно таких его кошмаров, как strncat).
MS> но приводят к головной боли по поводу совместимости на разных платформах. MS> Но я не против их существования, а у Вас похоже и здесь проблемы с пониманием. Я назвал идиотизмом объявление старых строковых функций как deprecated, а не просто наличие новых. От новых функций как таковых мне ни жарко ни холодно.
Это неотделимо одно от другого, потому что данный TR мотивирует введение новых функций именно проблемами старых. Текст TR доступен, можете сами убедиться:
1. Traditionally, the C Library has contained many functions that trust the programmer to
provide output character arrays big enough to hold the result being produced. Not only
do these functions not check that the arrays are big enough, they frequently lack the
information needed to perform such checks. While it is possible to write safe, robust, and
error-free code using the existing library, the library tends to promote programming styles
that lead to mysterious failures if a result is too big for the provided array.
2. A common programming style is to declare character arrays large enough to handle most
practical cases. However, if these arrays are not large enough to handle the resulting
strings, data can be written past the end of the array overwriting other data and program
structures. The program never gets any indication that a problem exists, and so never has
a chance to recover or to fail gracefully.
3. Worse, this style of programming has compromised the security of computers and
networks. Buffer overflows can often be exploited to run arbitrary code with the
permissions of the vulnerable (defective) program.
Отсюда, конечно, непосредственно не следует само объявление старых функций как deprecated — для этого нужен ещё один логический переход типа "мы их заставим родину любить!", но этот логический переход неизбежен.
MS> Вот только не надо убирать старые. Я делаю предсказание, что этот идиотский варнинг так и останется навечно вместе с функциями типа strcpy. И старые функции никогда не перейдут из категории deprecated в категорию prohibited-на-фиг.
Наверняка так и будет. И что с того? Использование нового комплекта функций станет (в тех пределах, в которых вообще допустимо использование NUL-terminated strings) такой же базовой необходимостью, как и соблюдение базовых правил программирования — примерно из того набора, как в соседней ветке "Огни разработки". И, наоборот, старые функции будут находиться в том же семействе, как плетёнка из goto, антипаттерны разработки, наплевательство на границы и особые значения, и тэ дэ и тэ пэ.
MS>Здравствуйте, netch80, Вы писали:
MS>>>И с точки зрения здравого смысла — на фиг не нужно искать этот null — как только встретился первый невалидный символ, надо остановиться. Я думаю, что наиболее вероятная причина такого косяка — элементарная небрежность. Так же возможно, что человек не в ладах с формальной логикой и интерпретировал фразу (3) как типа "строка должна быть null-terminated". N>>То, что Вы говорите — вопрос _оптимизации_. Чисто формально они имели право так сделать. MS>Ни фига себе — "вопрос _оптимизации_"! Если мне надо распарсить длинную строку с использованием strtod, то я тут же вместо O(N) получаю O(N^2). Извините, но O(N^2) на ровном месте — это 100%-ное ламерство.
На это, извините, единственное чем можно ответить — это замечательной притчей Джоэла Спольски:
Маляр Шлемиэль подрядился красить пунктирные осевые линии на дорогах. В первый день он получил банку краски, поставил её на дорогу, и к концу дня покрасил 300 метров осевой линии. "Отлично!" сказал прораб, "быстро работаешь!" -- и заплатил ему копейку.
На следующий день Шлемиэль покрасил 150 метров. "Мда, это, конечно, не так здорово, как вчера, но приемлемо." -- сказал прораб и заплатил ему копейку.
На следующий день Шлемиэль покрасил 30 метров. "Всего лишь 30!" заорал прораб. "Это никуда не годится! В первый день было в десять раз больше! В чём дело?"
"Ничего не могу поделать," -- говорит Шлемиэль. "Каждый день я ухожу всё дальше и дальше от банки!"
Не хотите квадратичной зависимости? Не используйте NUL-terminated strings вообще. Иначе она где-то обязательно будет вылазить, не в strtod, так в чём-то другом. Я уж молчу, как они обращаются с кэшами.
Повторюсь: Вы безусловно правы в том, что реализация, которая хочет полную длину — неэффективна. С этим я готов соглашаться и днём и посреди ночи. Но если Вы будете мотивировать свои требования мифической "некорректностью" такой реализации — у Вас ничего не получится.
Взял ближайшую мне доступную реализацию strtod() — во FreBSD — там нет никаких strlen() и лишних просмотров вперёд, код прост и понятен и под BSD-style license. Стащите его себе, раз уж так всё плохо в MS CRT...
Здравствуйте, netch80, Вы писали: N>В соответствии с какой именно официальной документацией?
Ты же сам привёл на неё ссылку. N>Так что именно не так? Расхождения не найдено, поведение как в CRT допустимо. Неоптимально — да, согласен, но формально ничему не противоречит.
Тебе по-прежнему непонятно, что именно не так? Перечитай исходное сообщение McSeem2.
N>Он описывает внешний интерфейс для аналогов функций из <string.h> и я не понимаю, к чему Вы упоминаете strtod() в этом контексте.
Перечитай исходное сообщение McSeem2. Там подробно написано, что именно не так с strtod().
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали: N>>В соответствии с какой именно официальной документацией? S>Ты же сам привёл на неё ссылку.
И что? Ни по MSDN ни по ISO запрета на такой вариант действия нет.
N>>Так что именно не так? Расхождения не найдено, поведение как в CRT допустимо. Неоптимально — да, согласен, но формально ничему не противоречит. S>Тебе по-прежнему непонятно, что именно не так? Перечитай исходное сообщение McSeem2.
Разъясни. Неоптимальность не предлагать — мы её уже обсудили.
N>>Он описывает внешний интерфейс для аналогов функций из <string.h> и я не понимаю, к чему Вы упоминаете strtod() в этом контексте. S>Перечитай исходное сообщение McSeem2. Там подробно написано, что именно не так с strtod().
Здравствуйте, netch80, Вы писали:
N>Вы сможете утверждать про "нелады с формальной логикой", если покажете по данной ссылке хоть одно место, где сказано, что данная функция не имеет права анализировать текст дальше первого непонятого символа. На сейчас Вы это не доказали.
N>Про несоответствие здравому смыслу я не буду спорить, а вот с несоответствием спецификации не соглашусь, пока не докажете (ой сомневаюсь).
Не докажу. Я не силен в риторике и демагогии. Спецификация действительно не запрещает в явном виде использовать strlen в функции strtod. Но из описания, пункты раз-два-три явно следует, что этого делать не надо. Просто не-на-до. И если бы я такое сделал, то я бы выглядел ей богу как мудак. И, кстати говоря, был бы готов это признать.
N>Не хотите квадратичной зависимости? Не используйте NUL-terminated strings вообще. Иначе она где-то обязательно будет вылазить, не в strtod, так в чём-то другом.
Глупость.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, netch80, Вы писали:
N>И что? Ни по MSDN ни по ISO запрета на такой вариант действия нет.
Равно как нет и запрета на разложение двоичного представления строки вплоть до первого нулевого символа на простые множители.
С таким подходом можно очень далеко уехать.
N>Разъясни. Неоптимальность не предлагать — мы её уже обсудили.
Её достаточно.
N>Считай меня непонятливым и разжуй по буквам.
Первое — согласен. Второе — не имею мотивации.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
N>>Про несоответствие здравому смыслу я не буду спорить, а вот с несоответствием спецификации не соглашусь, пока не докажете (ой сомневаюсь). MS>Не докажу. Я не силен в риторике и демагогии.
Не надо быть "сильным в риторике и демагогии", надо всего лишь использовать слова в их основном значении и строить логические связки. К сожалению, подготовка документации — тот процесс, при котором смысл реализации выхолащивается. По-моему, это было Ваше же сообщение здесь, что у MS надо читать только то, что написано явно, и не делать никаких допущений, даже если они кажутся очевидными. Вы всего лишь столкнулись с очередным примером.
MS> Спецификация действительно не запрещает в явном виде использовать strlen в функции strtod. Но из описания, пункты раз-два-три явно следует, что этого делать не надо. Просто не-на-до. И если бы я такое сделал, то я бы выглядел ей богу как мудак. И, кстати говоря, был бы готов это признать.
Вы слишком эмоционально к этому подходите. Собственно, у MS проблема не в качестве кода: оно как раз в среднем достаточно высокое. У них проблема с качеством и типом обратной связи. Для сравнения: в тех системах, с которыми я работаю, при обнаружении подобной ситуации я не пишу подобные "плачи" (ничего личного) в конференцию, я вместо этого составляю PR, где чётко описываю проблему и по возможности предлагаю пути её решения (вплоть до конкретного кода). Система проста и прозрачна, конкретные люди известны, с их свойствами, и практически всегда можно найти как прямой контакт, так и косвенный. В случае MS этого нет, или же оно сильно закрыто, а обновления идут крайне редко и содержат столько нового (как новая ОС или новая версия DevStudio), что новая мода забивает всё полезное.
А "признать, что мудак" — пусть не такими словами (скорее "что я курил, когда это писал?") — происходит постоянно, практически ежедневно. И тем не менее в общем результат положительный. Фигня в том, что никто в MS не почесался исправить первоначальную реализацию (наверно, 25-летней давности, вряд ли более свежую), ибо не заинтересован и на работы типа "разгрести старое дерьмо" вряд ли выделяется даже 5% времени.
N>>Не хотите квадратичной зависимости? Не используйте NUL-terminated strings вообще. Иначе она где-то обязательно будет вылазить, не в strtod, так в чём-то другом. MS>Глупость.
Не глупость, а некоторое художественное преувеличение (простите уж), но основанное на реальной практике применения оных строк с чуть другими целями (например, склейка через strcat). Кстати, не просветите ли, что именно за применение потребовало акцента на неэффективности strtod()? Я плохо представляю себе, откуда может взяться набор чисел в одной строке длиной в тысячу и более знаков (иначе операция поиска в кэшированной памяти занимала бы так мало, что не стоило бы обращать внимание).
Здравствуйте, Sinclair, Вы писали:
N>>И что? Ни по MSDN ни по ISO запрета на такой вариант действия нет. S>Равно как нет и запрета на разложение двоичного представления строки вплоть до первого нулевого символа на простые множители. S>С таким подходом можно очень далеко уехать.
А не надо "уезжать с таким подходом". Надо:
1. Чтобы написание не было _явно_ уходящим в сторону от тех путей, которыми реально решается задача. В этом смысле, я не могу себе представить алгоритм для strtod(), который бы использовал разложение строки на множители. А вот подсчитать длину строки и идти до конца, с одной стороны, является достаточно вероятным для наивной реализации, а с другой стороны — в типичных применениях (строка до сотни символов) не дающей заметного оверхеда.
2. Чтобы реализация корректировалась в соответствии с реальными нуждами текущей ситуации (см. соседнее письмо к McSeem2 насчёт обратной связи).
Можно сравнить ситуацию с, например, менеджером динамической памяти. Примерно в то же время, как MS писала текущую strtod() — начало 80-х, если мне не изменяет склероз — практически основным применяемым методом был линейный список. Сейчас его убрали, потому что он убивал нахер кэш, и используют деревья, двоичное деление, карты мелких выдач и тому подобное. Значит, эти алгоритмы заменены на новые. Почему strtod() не заменён? Видимо, потому, что это никому не было нужно.
N>>Разъясни. Неоптимальность не предлагать — мы её уже обсудили. S>Её достаточно.
Понятно, в таком случае и ты и я сказали уже всё, что можно тут было сказать, и можно эту дискуссию закрывать.
Здравствуйте, netch80, Вы писали:
N>Не глупость, а некоторое художественное преувеличение (простите уж), но основанное на реальной практике применения оных строк с чуть другими целями (например, склейка через strcat). Кстати, не просветите ли, что именно за применение потребовало акцента на неэффективности strtod()? Я плохо представляю себе, откуда может взяться набор чисел в одной строке длиной в тысячу и более знаков (иначе операция поиска в кэшированной памяти занимала бы так мало, что не стоило бы обращать внимание).
Возьмём, к примеру, банальный парсинг CSV. Допустим, он у нас маленький — с полгига, и мы читаем его через Memory-Mapped File. Логично ожидать, что сканер strtod остановится на первой comma, а не будет хреначить аки казак по степи в поисках Access Violation, нет?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
IB>Это демагогический прием направленный на то, чтобы демагога нельзя было уличить в демагогии? Как и всякая демагогия — фигово работает.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>Не глупость, а некоторое художественное преувеличение (простите уж), но основанное на реальной практике применения оных строк с чуть другими целями (например, склейка через strcat). Кстати, не просветите ли, что именно за применение потребовало акцента на неэффективности strtod()? Я плохо представляю себе, откуда может взяться набор чисел в одной строке длиной в тысячу и более знаков (иначе операция поиска в кэшированной памяти занимала бы так мало, что не стоило бы обращать внимание). S>Возьмём, к примеру, банальный парсинг CSV. Допустим, он у нас маленький — с полгига, и мы читаем его через Memory-Mapped File. Логично ожидать, что сканер strtod остановится на первой comma, а не будет хреначить аки казак по степи в поисках Access Violation, нет?
Да, пример показательный (с "ма-аленьким" CSV в полгига;). Ну что ж, пишите майкрософту problem report... не знаю уж как это в ваших краях делается...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>Не глупость, а некоторое художественное преувеличение (простите уж), но основанное на реальной практике применения оных строк с чуть другими целями (например, склейка через strcat). Кстати, не просветите ли, что именно за применение потребовало акцента на неэффективности strtod()? Я плохо представляю себе, откуда может взяться набор чисел в одной строке длиной в тысячу и более знаков (иначе операция поиска в кэшированной памяти занимала бы так мало, что не стоило бы обращать внимание). S>Возьмём, к примеру, банальный парсинг CSV. Допустим, он у нас маленький — с полгига, и мы читаем его через Memory-Mapped File. Логично ожидать, что сканер strtod остановится на первой comma, а не будет хреначить аки казак по степи в поисках Access Violation, нет?
Вдогонку: не заметил одного момента. В случае memory-mapped file, у Вас ведь в самом файле NUL не хранится? Вы его вручную обеспечиваете модификацией одной страницы в конце маппинга, или как?
Мы уже победили, просто это еще не так заметно...
