LINUX.ORG.RU

[C++?] Серьезный вопрос.


3

2

Просьба ответит серьезно, желательно с аргументами за или против.

Предистория:
Когда то давным давно (я тогда еще только закончил 9-ый класс) я увидел в газете объявление о наборе в летнюю группу по изучению классического программирования. В тот момент я был с компьютером на ты и "очень" хорошо в них разбирался (переустанавливал Windows каждый месяц, хаял Microsoft просто потому, что после моих настроек W приходилось постоянно переустанавливать). Группа по классическому программированию так и не набралась, но набралось 1 человек на Visual Basik for Applications. Я соглсился быть вторым и начались занятия.
Все, что мне там объясняли я схватывал быстро. Меня пригласили продолжить обучение в сентябре на курсе "моделирование".
Там уже был Pascal, который я тогда совсем не знал. Сам курс был очень разношорстный: мы изучали и использование мыши через прерывание, готовились к различным олимпиадам. Параллельно я изучил Pascal.
Потом был Delphi. К концу 10-го класса я уже неплохо владел приемами программирования и вовсю клепал бесполезные программулины. Потом поступил в универ на программиста. Там тоже был Delphi, и я особо не напрягаясь писал все лабы (к моменту поступления я уже был знаком с логикой указателей, самописные стеки и графы, etc).
На 2-ом курсе в гостях у знакомого я разобщался с человеком, который уже насколько лет работал в нерезиновой программистом. Он мне и открыл глаза на мир: "Delphi здох. Его уже похоронили и забыли. Сейчас необходимо знание C++, C#. Необходимо занание паттернов проектирование". Вобщем много чего он мне наговорил. Книжек умных насоветовал, подкинул MSVS 2008, кучу электронных книжек. Я изучил C# по книжке Шилдта. Читал "Идеальный кол" (автора уже не помню). Потом купил(!) себе книжку Шилдта про С++. Мне понравился язык. Тем более что мне казалось, что именно он и есть общепринятый стандарт. Наиболее удобный язык для программиста.

А недавно в соседней теме за упоминание это С++ меня чуть было не съели со всем чем можно. Так-то.

Собственно вопрос: Так стоит ли изучать дальше С++ (а я уже достаточно углубился в книжку Страуструпа, подробно изучая все подводные течения)? Какой язык стоит изучать? Какие из них более востребованны?

Спасибо всем, кто осилил это многобукаф.

★★★★★
Ответ на: комментарий от linuxfan

> Пишите на них лабы или подручные скрипты -- я не против, но пихать эти недоязыки в серьезные задачи и говорить с умным видом: "Отстаем на 40% -- херня! Это же не 36 раз." -- это полный 3.14здец и деградация сознания.

В обычной серьёзной задаче бОльшая часть времени - это ожидание на i/o. Если в задаче i/o мало, то, опять же, бОльшая часть программ занимается манипуляциями с памятью и структурами данных. И тут опять не ясно, программа на каком языке больше прососёт.

mv ★★★★★
()
Ответ на: комментарий от kemm

> > И это C++ников здесь обвиняют в завышенном самомнении.

> Ты не чувствуешь разницы между высказыванием "окамлщики пока люди с интеллектом выше среднего" и своим "не любишь плюсы -- херовый программист"?

1. Не чувствую.

2. Пруфлинк с моим утверждением "не любишь плюсы -- херовый программист" в студию.

eao197 ★★★★★
()
Ответ на: комментарий от mv

>Изучение Окамла после крестов...

Судя пофразам: "На C++ писать сложно.", "Программы на C++ текут памятью и сегфолтятся", изучение окамля пошло не после крестов, а вместо крестов.

linuxfan
()
Ответ на: комментарий от mv

> > И это C++ников здесь обвиняют в завышенном самомнении.

> Куда деваться, это естественный эффект обладания чем-то социально значимым...

Мы будем чморить C++ников, которые думают, что обладают чем-то социально значимым, потому что мы думаем, что мы обладаем чем-то социально значимым.

eao197 ★★★★★
()
Ответ на: комментарий от kemm

> > 2. Пруфлинк с моим утверждением "не любишь плюсы -- херовый программист" в студию.

> http://www.linux.org.ru/jump-message.jsp?msgid=4088836&cid=4141127

Смотрим:

>> С++, как настоящий друг, говорит тебе всю правду -- мол, херовый ты программист, и програмка твоя херовая -- и неделю не проработает.

Где здесь что-нибудь про любовь к C++?

eao197 ★★★★★
()
Ответ на: комментарий от linuxfan

> RAII в крестах воплотили. А в каких еще языках это сделано? C -- нет, Pascal -- нет, Lisp -- нет, Java -- нет, Python -- нет, Haskell -- нет, Ocaml -- видимо, тоже нет.

В managed-языках и так всё хорошо. RAII в крестах - это слёзы по хоть какой-нибудь автоматизации управления времени жизни объектов.

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


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

> Утекание памяти и сегфолты -- это миф.


Зал апплодирует стоя!

mv ★★★★★
()
Ответ на: комментарий от mv

>В обычной серьёзной задаче бОльшая часть времени - это ожидание на i/o.

Это, пардон, какая у тебя "серьезная задача"? Показать маме за соседникм компьютером клевый векторный гипертекстовый фотоальбом на своем любимом скобочном брейнфаке? В таком случае согласен.

Но бывают и правда серьезные вычислительные задачи. Взять хотя бы декодирование jpeg. Только представь себе: заходишь на страничку с фотками и система встает колом, шуршит свопом, завывает кулерами. Почему? А все потому что сейчас jpeg лениво декодируется хацкилем и теперь по интернету можно ходить только с четырехъядерным core i7, иначе тормозит сильно.

linuxfan
()
Ответ на: комментарий от linuxfan

> Только представь себе: заходишь на страничку с фотками и система встает колом, шуршит свопом, завывает кулерами. Почему? А все потому что сейчас jpeg лениво декодируется хацкилем и теперь по интернету можно ходить только с четырехъядерным core i7, иначе тормозит сильно.

Т.е. если всё переписать с нормальных языков на плюсы, то по интернету можно будет ходить только с C2D минимум, и то будет ощутимо подтормаживать? Я правильно понимаю? У нас ведь разница на 30%, как бы тебе в угаре не казалось, что в 36 раз.

kemm
()
Ответ на: комментарий от mv

>> RAII в крестах воплотили. А в каких еще языках это сделано? C -- нет, Pascal -- нет, Lisp -- нет, Java -- нет, Python -- нет, Haskell -- нет, Ocaml -- видимо, тоже нет.

> В managed-языках и так всё хорошо. RAII в крестах - это слёзы по хоть какой-нибудь автоматизации управления времени жизни объектов.

Таки хотелось бы видеть подтверждение вот этому:

> Ты ещё скажи, что RAII в крестах изобрели =)

Где RAII появилось до C++?

eao197 ★★★★★
()
Ответ на: комментарий от linuxfan

> Это, пардон, какая у тебя "серьезная задача"?

Мессейджинг на бирже, которая ворочает триллионами у.е. Чистой воды i/o. Ядро операционной системы - опять i/o и работа со структурами, числодробилок нет.

> Но бывают и правда серьезные вычислительные задачи.


Бывают. Но в том же браузере сетевого кода, который чистый i/o, больше, чем сугубо вычислительного.

mv ★★★★★
()
Ответ на: комментарий от eao197

> Где здесь что-нибудь про любовь к C++?

В контексте и в процитированной там строчке, что "с++ не дружелюбный к программисту язык"

kemm
()
Ответ на: комментарий от kemm

> В контексте и в процитированной там строчке, что "с++ не дружелюбный к программисту язык"

Т.е. додумано вами.

Зато есть другая цитата:

> Нет, плюсовщики давно лисперов оставили далеко в хвосте. Лисперы обычно заканчивают на "ты не умеешь готовить и лисп, и вообще <твой любимый ЯП> -- говно", а плюсовщики считают, что если тебе не правятся кресты -- то ты хреновый программист по определению.

http://www.linux.org.ru/jump-message.jsp?msgid=4088836&cid=4141197

Сказать, кто автор?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

> Где RAII появилось до C++?

В аде вроде было, нет?

kemm
()
Ответ на: комментарий от mv

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

Во-первых, код пишется человеком определенной квалификации и компилятор тебе ясно указывает на строку, где что-то не так, при этом выдавая еще какую-то более-менее внятную причину ошибки (в данном случае это будет из разряда "blah-blah-blah was not declared in this scope").

Во-вторых, невнятное сообщение об ошибке получает пользователь. Представь, если бы cp вместо сообщения "permission denied" гордо падал бы с bus error или floating point exception? А хацкилевское поделие поступало именно так.

В-третьих, ваша "встроенная безопасность" -- полная херня. О какой безопасности может идти речь, если мне приспичило вздрочнуть на порнуху, а плеер вместо сисек показывает длиннющий backtrace? Да мне похер, будь то лаконичный signal 11 или unhandled exception с простыней на 2kb. Я не получил желаемого и не получил внятного ответа, почему не могу удовлетворить свое хотение.

В-четвертых, утечки памяти проявляются со временем. Допустим, если недельку не перезапускать firefox, он отожрет 1Gb. Плохо, Но возьмем Vuze: он уже через пол-часа имеет RSS в 400+Mb. Это что, хорошо? Мне похрен, что в ff есть фрагментация или утечки: я перезупщу его -- и вуаля, он снова в тонусе (в пределах 120-150Mb) еще на пару дней, а перезапусти я Vuze -- и через полчаса снова 400Mb лениво ушло к GC. Как пользователю, мне удобнее медленные утечки в FF, чем GC в Vuze при отсутствии утечек.

linuxfan
()
Ответ на: комментарий от mv

>> Это, пардон, какая у тебя "серьезная задача"?

> Мессейджинг на бирже, которая ворочает триллионами у.е. Чистой воды i/o.

Это вы из собственного опыта или по чьим-то рассказам?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

> Где RAII появилось до C++?

Я имел в виду идею. Само название RAII появилось в крестах, но идею явно не дядька Бьярно изобрёл.

mv ★★★★★
()
Ответ на: комментарий от eao197

> Это вы из собственного опыта или по чьим-то рассказам?

Ну расскажи нам, какая числодробилка есть в мессейджинге? Джпеги расжимает?

mv ★★★★★
()
Ответ на: комментарий от eao197

Извини, я не могу работать по типу переводчицы в "Москва 2042". Не умею я с русского на русский переводить.

kemm
()
Ответ на: комментарий от linuxfan

> Во-первых, код пишется человеком определенной квалификации и компилятор тебе ясно указывает на строку, где что-то не так, при этом выдавая еще какую-то более-менее внятную причину ошибки (в данном случае это будет из разряда "blah-blah-blah was not declared in this scope").

Сообщение от g++ о банальной очепятке в коде при использовании шаблонистого кода давно не читал?

> Во-вторых, невнятное сообщение об ошибке получает пользователь. Представь, если бы cp вместо сообщения "permission denied" гордо падал бы с bus error или floating point exception? А хацкилевское поделие поступало именно так.


Это от неграмотности. Неграмотному юзеру bus error ничего не говорит, а неграмотный русский юзер ещё и permission denied прочитать не может. У каждого человека свой уровень некомпетентности.

> В-четвертых, утечки памяти проявляются со временем. Допустим, если недельку не перезапускать firefox, он отожрет 1Gb. Плохо, Но возьмем Vuze: он уже через пол-часа имеет RSS в 400+Mb. Это что, хорошо?


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

mv ★★★★★
()
Ответ на: комментарий от mv

>Мессейджинг на бирже, которая ворочает триллионами у.е. Чистой воды i/o.

И подумаешь, какая мелочь -- надо принимать, проверять и осуществлять тысячи транзакций в секунду. Главное же подождать io в течении 0.00001 секунды :D

>Ядро операционной системы - опять i/o и работа со структурами, числодробилок нет.

Ты начитался новости "теперь модули ядра можно писать на хацкиле"? У меня для тебя плохие новости: писать низкоуровневые вещи, приближенные к железу, на языках с высоким градусом абстракции никто в здравом уме не будет.

>Но в том же браузере сетевого кода, который чистый i/o, больше, чем сугубо вычислительного.

Да неужели? А странички святым духом рендерятся?

linuxfan
()
Ответ на: комментарий от mv

>> Это вы из собственного опыта или по чьим-то рассказам?

> Ну расскажи нам, какая числодробилка есть в мессейджинге? Джпеги расжимает?

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

А сам мессейджинг там всего лишь одна из подсистем, зачастую там используют уже готовые вещи типа TIBCO RV.

Впрочем, финансовые приложения, в том числе и биржевые, очень разные. И не только C++ там рулит, но и K, к примеру.

eao197 ★★★★★
()
Ответ на: комментарий от mv

>> Где RAII появилось до C++?

> Я имел в виду идею.

Слив защитан.

> Само название RAII появилось в крестах, но идею явно не дядька Бьярно изобрёл.

ООП и обобщенное программирование тоже не Страуструп придумал. И даже ключевое слово virtual, вроде бы он из Simula взял.

eao197 ★★★★★
()
Ответ на: комментарий от linuxfan

> И подумаешь, какая мелочь -- надо принимать,

Ожидание io.

> проверять


Пара сотен-тысяч циклов процессора.

> и осуществлять


Ожидание io.

> тысячи транзакций в секунду.


> Главное же подождать io в течении 0.00001 секунды :D


Ты будешь огорчён, но на нагруженном сервере система будет бОльшую часть времени торчать в пространстве ядра, занимаясь приёмом-передачей данных. На сколько там процентов будет медленней работать брокер в коротких перебежках от сисколла к сисколлу - это никого не волнует. Хорошей иллюстрацией является сравнение производительности AMQP-брокеров qpidc (C++) и rabbitmq (erlang) - разница на уровне статистического шума.

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

mv ★★★★★
()
Ответ на: комментарий от linuxfan

> У меня для тебя плохие новости: писать низкоуровневые вещи, приближенные к железу, на языках с высоким градусом абстракции никто в здравом уме не будет.

Дык, а кто то разве это предлагает? С++ тут тоже не очень то уместен, не?

Hjorn
()
Ответ на: комментарий от eao197

> Слив защитан.

Детский сад. Идея, лежащая в основе RAII, существовала в MacLisp - предтече Common Lisp. Штука называется unwind-protect.

mv ★★★★★
()
Ответ на: комментарий от linuxfan

> петун
> петон

> петун

> .....


Вас точно питон покусал. Ну как его вообще можно сравнивать с С++ и даже хаскелем, это ж абсолютно другая ниша.

Hjorn
()
Ответ на: комментарий от linuxfan

> Ты начитался новости "теперь модули ядра можно писать на хацкиле"? У меня для тебя плохие новости: писать низкоуровневые вещи, приближенные к железу, на языках с высоким градусом абстракции никто в здравом уме не будет.

Отчего-то запахло метаном... Как на счёт systemtap?

mv ★★★★★
()
Ответ на: комментарий от eao197

>>> Где RAII появилось до C++?

>> Я имел в виду идею.

> Слив защитан.

Берём gcc, делаем s/c/e/g, говорим, что изобрели два новых языка E и E++, обзываем RAII каким-нибудь PREI, и радостно вопим, что это мы придумали, и до E++ никакого PREI в помине не было. Так, получается? Аналогично можно поступить и с классами, темплейтами и прочим.

kemm
()
Ответ на: комментарий от mv

>Это от неграмотности. Неграмотному юзеру bus error ничего не говорит, а неграмотный русский юзер ещё и permission denied прочитать не может. У каждого человека свой уровень некомпетентности.

Я тебе на всякий случай напомню, что "permission denied" -- это "отказано в доступе". Фактически, это достаточно дружественное сообщение. А вот "разрывы шаблонов" в хацкиле никому ни о чем не скажут.

>В динамических средах можно ограничивать объём памяти, который gc позволяет отожрать до срабатывания.

Дооа. И задавать его можно в командной строке. И довеском получить тормоза из-за слишком частого gc.

linuxfan
()
Ответ на: комментарий от linuxfan

> Я тебе на всякий случай напомню, что "permission denied" -- это "отказано в доступе".

Я английский знаю. Но большинство русских людей его не знает.

> Фактически, это достаточно дружественное сообщение. А вот "разрывы шаблонов" в хацкиле никому ни о чем не скажут.


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

mv ★★★★★
()
Ответ на: комментарий от mv

>Ты будешь огорчён, но на нагруженном сервере система будет бОльшую часть времени торчать в пространстве ядра, занимаясь приёмом-передачей данных.

Твое утверждение верно, если речь идет о тупом прокси-сервере. Эти -- да, только и занимаются переливанием из пустого в порожнее. А вот как только появляется потребность произвести полезную деятельность...

>сравнение производительности AMQP-брокеров

Я смотрю, у тебя задачи не сложнее работы со значениями в хэш-таблице.

>Дела с io обстоят на столько плохо

Наверное, ты забыл добавить "в эрланге". Лично я особых проблем с IO при обслуживании 2k запросов в секунду не наблюдаю.

linuxfan
()
Ответ на: комментарий от mv

>Идея, лежащая в основе RAII, существовала в MacLisp - предтече Common Lisp. Штука называется unwind-protect.

Извини, а где там выделение ресурсов? По-моему, это далекий предок try..finally, которых нету в C++, ибо RAII.

linuxfan
()
Ответ на: комментарий от mv

> Идея, лежащая в основе RAII, существовала в MacLisp - предтече Common Lisp. Штука называется unwind-protect.

Судя по ее описанию, это не RAII, это то, что сейчас реализуется с помощью finally.

eao197 ★★★★★
()
Ответ на: комментарий от mv

> Ты - скучный зашоренный тролль.

Это смело можно отнести ко всем выжившим на данный момент участникам данного срача.

eao197 ★★★★★
()
Ответ на: комментарий от mv

>Отчего-то запахло метаном... Как на счёт systemtap?

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

BTW: описываемый ими язык -- это не окамль, не хацкиль, не эрланг и даже не пистон (да, еще я могу python называть пистоном), а какой-то отдельно взятый DSL. Я где-то высказывался против написания DSL?

linuxfan
()
Ответ на: комментарий от eao197

> Это смело можно отнести ко всем выжившим на данный момент участникам данного срача.

Если спор сейчас перекинется на lisp vs ocaml/haskell, и я буду утверждать, что изкоробочный паттерн-матчинг - это моветон, потому что в лиспе его можно нагородить на destructuring-bind, то тогда я буду зашоренным троллем.

mv ★★★★★
()
Ответ на: комментарий от eao197

>> Идея, лежащая в основе RAII, существовала в MacLisp - предтече Common Lisp. Штука называется unwind-protect.

>Судя по ее описанию, это не RAII, это то, что сейчас реализуется с помощью finally.

Управление файловыми дескрипторами не имеет ничего общего с управлением памятью. Это притягивание концепта за уши.

Absurd ★★★
()
Ответ на: комментарий от mv

>Я английский знаю. Но большинство русских людей его не знает.

[code]$ LC_MESSAGES=ru_RU.UTF-8 cp /bin/{cp,mv} cp: невозможно создать обычный файл `/bin/mv': Отказано в доступе[/code]

Или gettext и локализация звучат незнакомо? Хацкилевское поделие же говорило со мной не по-русски и даже не по-человечески.

linuxfan
()
Ответ на: комментарий от mv

>Ты - скучный зашоренный тролль.

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

Если ты хочешь, чтобы я тебя покормил, сбавь градус абстракции и включи соображалку, чтобы она подсказала тебе, что стоит за словами "message queuing" и почему оно имеет к бирже весьма расплывчатое отношение.

linuxfan
()
Ответ на: комментарий от linuxfan

> Не поверишь, я такого же мнения о местных скриптовиках-затейниках

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

> у них ни одной своей мысли, сплошные "ссылки на бенчмарки из гугля"

Деточка, у тебя даже такой аргументации-то нет.

kemm
()
Ответ на: комментарий от mv

>Если спор сейчас перекинется на lisp vs ocaml/haskell

Не перекинется. Все упомянутые языки -- это экзотика, приверженцы которой трясутся в бессильной злобе, глядя на то, как мейнстрим проносится мимо них. Вы все в одной лодке и скорее начнете закидывать говном сишное ядро Linux, чем спорить о преимуществах/недостатках мертворожденных никому не нужных ЯП.

linuxfan
()
Ответ на: комментарий от Absurd

>Управление файловыми дескрипторами не имеет ничего общего с управлением памятью. Это притягивание концепта за уши.

Если ты считаешь, что try..finally -- это RAII в чистом виде, мне тебя даже не жалко. Следующий логичный шаг -- утверждать, что Java насквозь пропитана концепцией RAII.

linuxfan
()
Ответ на: комментарий от kemm

>Итак, чем С -- менее скриптовый быдлоязык

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

linuxfan
()
Ответ на: комментарий от linuxfan

И какое это отношение имеет к скриптовости? Из него следует, что C++ -- скриптовый язык, тогда уж.

kemm
()
Ответ на: комментарий от Hjorn

> сейчас можно вовсю тащить фишки ФП в быдлоязыки и иметь профит, пусть даже хаскель с окамлем никогда не станут мейнстримом. А то глядишь, F# переведут из статуса экспериментального в промышленный, и вот вам "сбылась мечта идиота".

Уже. F# собираются включить в новую версию студии (почти мэйн-стрим). Я немножко поигрался с ним. Довольно интересно. Похоже на OCaml, но система классов - дотнетовская. Также доступны lex и yacc.

dave ★★★★★
()
Ответ на: комментарий от eao197

> Т.е. писать маленький проект в одиночку, под одну платформу, для какой-то конкретной задачи -- OCaml и Haskell сейчас вполне привлекательны. Но увеличте команду до 10 человек, перенесите свой продукт на несколько платформ и ситуация серьезно изменится.

Там, где нужно много народу, Cи ++ тоже не очень подходит. Наверное, либо просто Си, либо Java с .NET.

dave ★★★★★
()
Ответ на: комментарий от linuxfan

>Если ты считаешь, что try..finally -- это RAII в чистом виде, мне тебя даже не жалко.

finally это чисто техническая фича для освобождения дескрипторов по выходу из блока, не представляющая никакого интереса. А RAII это притянутый за уши бесполезный концепт.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>А RAII это притянутый за уши бесполезный концепт.

Есть мнение, что RAII -- офигительно полезный концепт, который позволяет минимизировать утечки ресурсов по причине человеческой невнимательности.

linuxfan
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.