Здравствуйте, Alexey.Os, Вы писали:
AO> 1) требования к ресурсам (память и вычислительные)
Скажем так: древний и кривой рантайм Mono, который используется в предпоследней версии Unity, позволяет создавать играбельные (и очень хорошо продаваемые) кроссплатформенные 3D-шутеры на мобильных платформах.
AO> 2) наличие/удобство технологи
Есть такой критерий качества языка — возможность средствами языка выразить абсолютно некорректные взрывоопасные вещи. Си в этом смысле — полный и безоговорочный фейл.
AO> 3) ключевые моменты разработки/отладки
C#/Roslyn в этом смысле поприятнее будет.
AO> 4) перспектива будущего сопровождения
При прочих равных условиях сопровождать C#-код проще, чем C++-код.
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Alexey.Os, Вы писали:
TK>>Кроссплатформенность может помочь в случае если у вас frontend будет от backend отделен. TK>>А будет это написано на c++ или c# не важно — c++ в этом плане даже более кроссплатформенным оказаться может...
AO>Тоже интересный момент, я полагал, что кроссплатформенность — это конек .NET, но уже несколько человек написали, что для этого лучше C++ и QT. AO>Или они только GUI имели в виду?
Для C++ кроссплатформенность это в первую очередь backend — если не завязываться на win api то, stl / boost и т.п есть практически под любую платформу. Кросплатформенный GUI оно обычно бывает, но в большинстве случаев получается "страшненько" везде
GUI для .net это либо устаревший winforms или откровенно спорный wpf. Тут идея простая — есть стабильный backend, а gui лепится под конкретную платформу из того, что есть
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[3]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Alexey.Os, Вы писали:
AO>Скажу по секрету, я поднял эту же тему на другом программерском сайте(не на RSDN), но в разделе C++. AO>Там форумчане не согласны с вашим мнением. AO>
AO>Кому поверить?
Они просто считать не умеют. По плюсам C# в два раза лучше простого С++
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[3]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, bazis1, Вы писали:
B>>Минусы плюсов: B>>* Нет нормального garbage collector-а. EP>Есть консервативные сборщики мусора, причём им не первый десяток лет, но их никто не использует, потому что нет такой необходимости.
Ими никто не пользуется, потому что из вот такого объявления:
class Inner : public ManagedObject<Inner>
{
};
class Outer : public ManagedObject<Outer>
{
public:
Inner::ref m_pInner;
}
Outer::ref pOuter = new Outer();
нельзя получить вот такой граф, без которого никакой сборщик мусора никогда не разрулит ни одну круговую зависимость:
Это можно сделать через макросы и специальные конструкторы, но это усложнит задачу до уровня непрактичности.
EP>Нужно держать и что-то там разруливать в исключительных случаях, а никак не постоянно.
Если это не делать постоянно, то потом будете полдня отлавливать memory leaks в дебаггере.
EP>99% случаев разруливаются scope-based lifetime, даже без всяких *_ptr и прочего ref-counting.
Ага, реализуйте мне MVC GUI без reference-counting.
B>>и таких примеров много. Соответственно, одинаковый по функционалу код получается более громоздким и дорогим в поддержке. EP>Это типа 4k строк нагенерированных на ровном месте?
Ничего не понял. Вы дали ссылку на какую-то левую библиотеку с непонятным нагенерированным кодом, который очень похож на то, что делает Linq. Что это должно означать, что на C++ не написано тонн подобных библиотек?
EP>Для этого есть Boost.Fusion/Hana EP>
Но со встроенным compile-time reflection было бы конечно красивее.
B>>* Нет yield return, async/await, EP>Во-первых есть библиотечные (например на базе Boost.Coroutine). А во-вторых если речь про MSVS — то там начиная с ЕМНИП 2015 есть встроенное расширение.
Вопрос в том, насколько лаконично они выглядят. Давайте, что ли, пример, аналогичный вот этому:
IEnumerable<int> MakeSquares(int max)
{
for (int i = 0; i < max; i++)
yield return i * i;
}
...
foreach(var s in MakeSquares(10))
{
if (s > 10)
break;
}
B>>LINQ
EP>Для in-memory последовательностей есть Boost.Range. А для взаимодействия с DB есть как отдельные библиотеки с декларативным описанием запросов, так и целые системы а-ля ODB.
Я не про ДБ, а про упрощение работы с данными. Что-то вроде такого:
var surnamesByFrequency = fullNames
.GroupBy(fn => fn.Surname)
.Select(pair => new {Surname = pair.First, Count = pair.Second.Unique().Count()})
.OrderBy(rec => rec.Count);
Т.е. берем массив структур "имя, фамилия", группируем по фамилиям, потом считаем количество уникальных имен для каждой фамилии, потом сортируем и получаем массив объявленных на ходу структур.
На плюсах будет раз в пять больше кода.
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Alexey.Os, Вы писали:
AO>Бюджет будет и будут лицензии от MS. AO>Т.е. выбор технологий (.NET или Win32) — это не финансовый вопрос, идеологический ...
зачем вам в наше время win32? microsoft перенесла sql server на linux, сделала linux подсистему в win 10, выпускает готовые docker контейнеры с .net core,
в tfs есть поддержка git, vs code работает на всех платформах и никаким win32 и .net там вообще не пахнет...
все еще мало намеков?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[4]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
AO>>Например, C++ не требует прослойки, и работает с чистой виндой. AVK>Чистой современной винды без дотнета нынче не бывает — даже на относительно старых версиях оно приходит автоматом через апдейт.
Даже nano server теперь с полноценным .net приходит?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[2]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, bazis1, Вы писали:
AO>>Я пытаюсь собрать информацию, оценить ”минусы” и “плюсы” и сравнить перспективу. B>Если нужен кроссплатформенный GUI, то C++ и Qt. Но по времени выйдет в 3 раза дольше, чем на WPF.
Еще можно sciter взять или веб с angular / react. В отличие от wpf на них не забили.
AO>>Например, C# требует .NET. Что здесь хорошего, а что плохого? AO>>Какие еще ключевые отличия C++ от C# ? B>Плюсы плюсов: B>* Кроссплатформенность (в т.ч. GUI с Qt). C# сносно работает на Linux и Mac, но с GUI там большие проблемы.
"сносно" это та еще характеристика...
B>* Нет нормального garbage collector-а. Поэтому нужно постоянно держать в голове, что и когда удаляется. Всякие shared_ptr и т.п. частично эту проблему решают, но держать это в голове все равно придется. Простейший пример на C#: B>
B>2 объекта, первый делает что-то в фоне, второй подписан на его события. Оба удалятся автоматически, когда станут не нужны.
А откуда такой вывод, что они станут не нужны одновременно? В любом случае — для С++ тоже есть сборщики мусора. Mono с одним из таких "сносно" жило какое-то время.
B>На C++ вы тут же упретесь в то, что: B>а) Нельзя просто так взять указатель на метод и автоматически увеличить reference count для объекта. Можно, используя шаблонную магию, но вы замучаетесь. B>б) Если myHandler держит ссылку на myEventSource, то получается circular reference. Надо разруливать руками: или делать weak reference, или shutdown() который сбросит (опять же руками) всякие вспомогательные smart-указатели. B>* Меньше синтаксического сахара. К примеру, вот такая строчка в C# B>
руки за такое отрывать надо.
B>и таких примеров много. Соответственно, одинаковый по функционалу код получается более громоздким и дорогим в поддержке. B>* Нет reflection. В C# я могу объявить вот такую структуру: B>
тоже мне достижение... можно взять Microsoft Bond и кидать такие структуры хоть xml, хоть в json с минимальными накладными расходами. Зачем тут reflection — не очевидно.
B>Это позволяет эффективно разделять алгоритмы и данные, сохраняя всякие настройки, policy, и т.п. в легкочитаемой форме, которую можно зачекинить в git. Более того, форма не привязана к порядку и размеру полей внутри структур, т.е. добавив в середину новое поле, я не сломаю сохраненные файлы.
B>* Нет yield return, async/await, LINQ и прочих вещей, которые часто экономят сотни строк кода.
сэкономят на отладке и профилировании
B>* Существенно дольше компиляция, если Вы часто редактируете header-ы. Можно частично побороть через precompiled headers, но все равно будет медленно.
А не надо менять контракты на каждый чих
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, bazis1, Вы писали:
B>>>* Нет нормального garbage collector-а. EP>>Есть консервативные сборщики мусора, причём им не первый десяток лет, но их никто не использует, потому что нет такой необходимости. B>Ими никто не пользуется, потому что из вот такого объявления: B>
B>class Inner : public ManagedObject<Inner> ...
B>
B>нельзя получить вот такой граф, без которого никакой сборщик мусора никогда не разрулит ни одну круговую зависимость: B>
B>Это можно сделать через макросы и специальные конструкторы, но это усложнит задачу до уровня непрактичности.
Консервативные сборщики мусора это всё разруливают, для этого не нужны никакие макросы и прочие "ManagedObject" (они нужны для точных библиотечных GC).
Смотри например Boehm GC.
EP>>Нужно держать и что-то там разруливать в исключительных случаях, а никак не постоянно. B>Если это не делать постоянно, то потом будете полдня отлавливать memory leaks в дебаггере.
Во-первых GC не спасает от утечек. Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
В-третьих, вот пример кода:
Здесь никакого ref-counting и прочего, все значения имеют простой life-time привязанный к scopes — как и >90% всех объектов в программе.
В некоторых случаях да, нужны unique_ptr, ещё в более редких shared_ptr, ещё реже нужен weak_ptr — но это не означает что на каждый new в C# программе в аналоге на C++ будут *_ptr и прочие заморочки.
EP>>99% случаев разруливаются scope-based lifetime, даже без всяких *_ptr и прочего ref-counting. B>Ага, реализуйте мне MVC GUI без reference-counting.
GUI обычно не является какой-то огромной частью кода C++, более того для формочко-ориентированной разработки я именно C# и советовал в соседнем сообщении.
B>>>и таких примеров много. Соответственно, одинаковый по функционалу код получается более громоздким и дорогим в поддержке. EP>>Это типа 4k строк нагенерированных на ровном месте? B>Ничего не понял. Вы дали ссылку на какую-то левую библиотеку с непонятным нагенерированным кодом, который очень похож на то, что делает Linq. Что это должно означать, что на C++ не написано тонн подобных библиотек?
Для C++ в этом случае не нужна никакая генерация кода, в этом реальном примере именно C# показывает свою громоздкость и дорогую поддержку (текстовую кодогенерацию поддерживать сложнее).
B>>>* Нет yield return, async/await, EP>>Во-первых есть библиотечные (например на базе Boost.Coroutine). А во-вторых если речь про MSVS — то там начиная с ЕМНИП 2015 есть встроенное расширение. B>Вопрос в том, насколько лаконично они выглядят. Давайте, что ли, пример, аналогичный вот этому: B>
B>IEnumerable<int> MakeSquares(int max)
B>{
B> for (int i = 0; i < max; i++)
B> yield return i * i;
B>}
B>...
B>foreach(var s in MakeSquares(10))
B>{
B> if (s > 10)
B> break;
B>}
B>
auto make_squares(int max)
{
return coroutine<int>::pull_type{[=](auto &yield)
{
for (int i = 0; i < max; i++)
yield(i * i);
}};
}
...
for(auto x : make_squares(10))
{
if(x > 10) break;
cout << x << endl;
}
Вот Live Demo. Причём yield здесь не ограничен лишь одним уровнем как yield return, и может быть вызван на произвольно-глубоком уровне callstack'а, даже сквозь сторонний код который об этом yield ничего не знает.
B>>>LINQ
EP>>Для in-memory последовательностей есть Boost.Range. А для взаимодействия с DB есть как отдельные библиотеки с декларативным описанием запросов, так и целые системы а-ля ODB. B>Я не про ДБ, а про упрощение работы с данными. Что-то вроде такого: B>
B>Т.е. берем массив структур "имя, фамилия", группируем по фамилиям, потом считаем количество уникальных имен для каждой фамилии, потом сортируем и получаем массив объявленных на ходу структур. B>На плюсах будет раз в пять больше кода.
Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Консервативные сборщики мусора это всё разруливают
Консервативные сборщики имеют очень печальную производительность.
EP>Смотри например Boehm GC.
Да насмотрелись уж в Моно.
B>>Если это не делать постоянно, то потом будете полдня отлавливать memory leaks в дебаггере. EP>Во-первых GC не спасает от утечек.
Смотря что понимать под утечками.
EP> Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
Тут видишь какое дело — подтекающий или страдающий уявзимостями типа переполнения буфера плюсовый софт попадается постоянно, а вот со страдающим утечками ресурсов дотнетный софт я пока не встречал. Не скажешь почему?
EP>GUI обычно не является какой-то огромной частью кода C++
EP>Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так: EP>[ccode] EP>auto surnames_by_frequency = full_names EP> | group_by(PROJ(surname)) EP> | view::transform([](const auto &ys) EP> { EP> return NEW( (surname, first(ys).surname) (count, distance(ys | view::unique)) ); EP> }) EP> | order_by(PROJ(count));
Макросы, да? Что ты там про текстовую кодогенерацию только что написал?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AO>Т.е. со сторонними библиотеками у C++ получше, чем у C#?
Сторонних библиотек у C++ море. Поэтому придётся ещё с ними разобраться чтобы взять именно ту которая вписывается в проект. Даже выбор какой-нить парсилки json без хорошего опыта может встать в отдельную задачу — вам header-only с бустом, или header-only без буста, или обычную с std, с минимумом аллокаций но требующую загрузку всего файла в память и портящую его при парсинге, или потоковую, и т.п. Хороший C++-ник с этим всем знаком, и выберет на автомате. Плохой — будет каждый раз выбирать то что первым гугл/so даст, и быстро загонит проект в несобираемое состояние.
А ещё в трэнде у C++ библиотеки опен-сорс, качество немного предсказуемо и нужно быть готовым найти и починить багу в этих библиотеках если что. А учитывая что укушенный Александреску рано или поздно перекусает всех вокруг в сколь разных стилях их пишут, это может быть задача для специалиста способного читать самопальную шаблонную магию, бустовую, и старую на препроцессорах. В общем понадобится для этого программист уровнем несколько выше среднего. Чтобы не быть голословным — лично совсем недавно чинил pugyxml (сохранённый и потом загруженный файл был не равен самому себе, из-за особенностей интерпретации пустых нод), до того вносил правки в lidgren network, и т.п. — это при том что я с C++ почти не работаю, а сами библиотеки вполне популярные и в общем-то качественные. .NET-ом конечно тоже везде доволен не будешь, но конкретно вникать и править чисто библиотечный код типа сети или XML обычно не требуется.
Re[2]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, DreamMaker, Вы писали:
DM>но тем не менее попробую ответить. ключевое отличие C# от C++ в том, что C# лучше чем C++. особенно на этом форуме
C# хорош тем, что на волне хайпа за него неплохо платят. Ну и для разработчиков он хорош тем, что они будут знать C#, а на волне хайпа за него неплохо платят. С точки зрения конторы при создании долгоиграющего продукта — тут уже много спорных моментов всплывает
Здравствуйте, AndrewVK, Вы писали:
AO>>Скажу по секрету, я поднял эту же тему на другом программерском сайте(не на RSDN), но в разделе C++.
AVK>Почему по секрету и какой смысл шифроваться? Почему бы просто не дать ссылку? AVK>http://www.sql.ru/forum/1244295/visual-c-vs-c-nado-sravnit-perspektivy
sql.ru — программерский форум? А на delphi.ru ТС не пробовал спрашивать? Я адрес delphi.ru сам придумал, если что. Там какая-то реклама сейчас висит, но, чисто теоретически, гипотетический delphi.ru на порядок более программерский. На дельфях, вон, до сих пор некоторые шароварщики пишут. А много ли есть шаровар на чистом SQL? Я ни одной не знаю
Здравствуйте, Marty, Вы писали:
M>sql.ru — программерский форум?
Да.
M> А много ли есть шаровар на чистом SQL? Я ни одной не знаю
Тематика сиквел.ру давным давно не ограничивается сиквелом. Нас, собственно, 15 лет назад и было то три основных русскоязычных девелоперских сайта, мы, сиквел и готдотнет.
Здравствуйте, Alexey.Os, Вы писали:
AO>В рамках будущего проекта будем создавать ПО под Windows. AO>Решаем, какой инструмент разработки выбрать Visual C++ или Visual C#
Учитывая что писать вы собираетесь что-то под Windows, то и писать лучше на чем-то под Windows.
Простите, но какой вопрос, такой и ответ.
По сути — лучше всего рассматривать какие технологии потребуются и наиболее подходят для решаемой задачи. Из этого выбирать уже язык (плюс поглядывать на местный рынок специалистов, на его цены и число предложений). Если проектов больше одно, то не исключено что и команды могут писать на разных языках.
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Консервативные сборщики мусора это всё разруливают, для этого не нужны никакие макросы и прочие "ManagedObject" (они нужны для точных библиотечных GC). EP>Смотри например Boehm GC.
it must scan parts of storage (most notably the execution stack) where there are words of storage that MIGHT be an object address and make the CONSERVATIVE assumption that if it looks like a valid address, and there is an object that has that address, then the object should not be collected.
Не-не-не-не-не, Девид Блейн. Такой магии нам не надо. Получается, что если случайное 32-битное слово внутри какого-нибуть сжатого блока, хранящегося в памяти, вдруг совпало с адресом внутри другого блока, то второй блок никогда не удалится? Я понимаю, почему этим никто не пользуется. Потому что worst case здесь — это вылетание с OutOfMemoryException, и кастомеру нафиг не впырилось слушать ваши оправдания о крутости сброщика мусора.
EP>Во-первых GC не спасает от утечек. Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще).
В C# просто немного другая парадигма:
1. Там, где реально надо, чтобы оно освободилось, как только стало ненужным, используется IDisposable и using.
2. Во всех остальных случаях достаточно добавить освобождение в финализатор и если чего, вызвать GC.Collect().
EP>Здесь никакого ref-counting и прочего, все значения имеют простой life-time привязанный к scopes — как и >90% всех объектов в программе.
Ага, вот только если я хочу заполнить массив из фонового потока, а потом результат отобразить в GUI, то в C# я добавлю Task.Create() и await и дальше это не моя проблема. А в C++ придется городить огород.
EP>GUI обычно не является какой-то огромной частью кода C++, более того для формочко-ориентированной разработки я именно C# и советовал в соседнем сообщении.
Часто бывают, что формочки переплетены с хитроумной логикой и выбор языка для логики автоматически определяет язык для формочек.
EP>Для C++ в этом случае не нужна никакая генерация кода, в этом реальном примере именно C# показывает свою громоздкость и дорогую поддержку (текстовую кодогенерацию поддерживать сложнее).
Для какого случая? Кто-то зачем-то нагенерил кучу каких-то helper-ов, забив на синтаксический сахар. Скажите мне, какую задачу нагенеренный код решает, и я покажу, как это сделать проще.
EP>
EP>auto make_squares(int max)
EP>{
EP> return coroutine<int>::pull_type{[=](auto &yield)
EP> {
EP> for (int i = 0; i < max; i++)
EP> yield(i * i);
EP> }};
EP>}
EP>...
EP>for(auto x : make_squares(10))
EP>{
EP> if(x > 10) break;
EP> cout << x << endl;
EP>}
EP>
О, это красиво. Надо будет взять на учет. Хотя boost немного напрягает монстроидальностью.
EP>Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так: EP>
"Примерно" потому что у group_by и unique из Range немного другая семантика, но при необходимости можно сделать клон с такой же семантикой.
Тоже довольно неплохо.
Итого: с LINQ и yield Вы меня убедили, но отсутствие нормального GC — все равно большая проблема.
Re[5]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, Alexey.Os, Вы писали:
AO>Этот момент я попробую проработать, неужели MS не может предложить собственный фреймворк для C++, вынуждая пользоваться сторонним QT?
Оно им не надо. Десктоп, как горячая массовая тема, умер.
Re[6]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
EP>>Консервативные сборщики мусора это всё разруливают AVK>Консервативные сборщики имеют очень печальную производительность.
Я знаю о их проблемах, тем не менее:
а) им не нужны никакие специальные макросы и подобное
б) имеют область применения
в) это ещё вопрос что производителей — быстрый C++ с медленным GC, или медленный C# с быстрым GC.
B>>>Если это не делать постоянно, то потом будете полдня отлавливать memory leaks в дебаггере. EP>>Во-первых GC не спасает от утечек. AVK>Смотря что понимать под утечками.
Ну конечно же тебе ближе определение где утечка на C++ это УТЕЧКА, а утечка на C# это вообще никакая не утечка, а даже фича такая
EP>> Во-вторых утечка памяти это минорная проблема, особенно по сравнению с утечкой ресурсов (которую на C# получить проще). AVK>Тут видишь какое дело — подтекающий или страдающий уявзимостями типа переполнения буфера плюсовый софт попадается постоянно, а вот со страдающим утечками ресурсов дотнетный софт я пока не встречал. Не скажешь почему?
Без понятия, может избирательная память такая, а может особенности кругозора
Да и при чём тут переполнение буфера? Это во-первых проблема скорее свойственная C коду, а во-вторых речь шла про утечки
EP>>Я же говорю, в случае не-БД ближайшем аналогом будет библиотека Range, примерно так: EP>>[ccode] EP>>auto surnames_by_frequency = full_names EP>> | group_by(PROJ(surname)) EP>> | view::transform([](const auto &ys) EP>> { EP>> return NEW( (surname, first(ys).surname) (count, distance(ys | view::unique)) ); EP>> }) EP>> | order_by(PROJ(count)); AVK>Макросы, да?
В PROJ аналогичная лямбда возвращающая соответствующее поле аргумента. Лямбды на C# лаконичней, да, (нет return и т.п.) о чём я неоднократно писал.
В NEW эмуляция анонимных типов, можно без неё — тогда внутри лямбды transfrom объявляется обычная структура, сразу же заполняется и возвращается — лишние несколько строчек.
AVK>Что ты там про текстовую кодогенерацию только что написал?
Мне цитату привести?
Re[6]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, AndrewVK, Вы писали:
M>>sql.ru — программерский форум?
AVK>Да.
M>> А много ли есть шаровар на чистом SQL? Я ни одной не знаю
AVK>Тематика сиквел.ру давным давно не ограничивается сиквелом.
Ну да, там еще по делфи и 1С много тем.
AVK>Нас, собственно, 15 лет назад и было то три основных русскоязычных девелоперских сайта, мы, сиквел и готдотнет.
Извини, забыл <сарказм> поставить
ЗЫ — это у меня в ухах жужжит или на сайте стало (похоже, при появлении новых сообщений, или как-то так) что-то бдзинькать?
