муки выбора между библиотекой Qt и С# .net

[The Nameless One]

Привет. Надоело каждую кнопочку и ползуночек создавать через DirectX.
Хочется изучить что-нибудь новое для быстрой разработки приложений с GUI.

Никак не могу выбрать между Qt и C#  .Net.

Qt плюсом является уже более менее родной для меня С++. Правда смущают эти SIGNAL и SLOT - т.к. это уже не к стандарту С++ относится.

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

Посоветуйте, пожалуйста, наиболее объективно.

[RXL]

The Nameless One, эти фишки Qt к C++ отношения не имеют - это директивы, которые обрабатывает препроцессор moc, после чего для компиляции имеем полноценный C++ код.

[The Nameless One]

RXL, и ваш совет? )

[RXL]

Не могу такой дать, т.к. с GUI .NET не работал. С Qt работал очень давно и не слежу за текущими возможностями. Об этом лучше спросить Finch-а. Архитектура Qt и подход к расширению мне нравился - удобно и понятно.

Могу только следующее сказать: если в планах есть кроссплатформенность, то .NET отпадает.

[Dimka]

Ну если нужно, чтобы был богатый и удобный для быстрой разработки GUI и при этом этот GUI отрисовывался бы через DirectX, то можно смело брать WPF.NET. DirectX сразу исключает из рассмотрения вопрос кроссплатформенности.

[The Nameless One]

RXL, понятно, спасибо за ответ.

Dimka, главное приложение использует DirectX, все полностью на С/С++, а сейчас пишу тулзы для помощи к основной разработке. Вот эти самые тулзы в основном состоят из GUI.

И еще насчет кроссплатформенности вопрос не стоит, но, насколько я знаю, для .net есть mono?

[RXL]

The Nameless One, Mono в своем развитии не поспевает за .NET.

[The Nameless One]

Скажите, пожалуйста, такую вещь.  Хотя бы просто для интереса.
Есть ли на С++ хорошая библиотека GUI, полностью на нормальном стандартном ANSI C++? Без каких-либо расширений вроде Qt, управляемого С++ для .Net и т.д.?
Я понимаю, что С++ не удобен для написания графических интерфейсов , но все же, может есть такая?
MFC монструозный,  да еще Microsoft перестали его поддерживать и обновлять, если не ошибаюсь.
 

[Алексей++]

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

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

[Джон]

ps Джон всё видит.

Можно по-подробней, откуда сведения о том, что МС перестал поддерживать MFC? Глупости всё это. В 2008 студии MFC такой, что .NET может позавидовать. Эт раз.

Два. Как ты себе представляешь GUI библиотеку на нормальном стандартном ANSI С++?

Любое GUI связано с платформой и, например, под виндой без WinAPI ты никуда не денешься. Всё работает через нго родимого. И MFC, и .NET и прочие извращения а ля Борланд и тп. Если MFC сильно большой монстр, посмотри WTL, она базируется на ATL. Там единственная заморочка (ИМХО) это "множественно-множественные" наследования шаблонных классов.

[The Nameless One]

Рад буду ошибаться насчет MFC. Такой вывод я сделал, читая интродукцию в Qt, где в оправдание расширениям в виде слотов и сигналов в пример привели плохое проектирование MFC, "люди, проектировавшие MFC, обладали поверхностными знаниями о принципах ООП". Далее приводился пример на MFC, где демонстрируется трудно читаемость кода и сложность вносимых изменений.
Про то, что MS перестали поддерживать MFC - читал на C# - форумах, думал, не врут)
И к тому же, а в студии 2010 есть ли MFC и какой он?

"Как ты себе представляешь GUI библиотеку на нормальном стандартном ANSI С++?"

Например удобная ООП-обертка вокруг того же Win32Api, GTK+ и т.д.

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

Насчет WTL - если это только для Борланд, то нет. Потому что полностью соглашусь с вами, что Борланд  С++ - это извращение

C# все таки полноценный язык, к которому надо привыкать. Поэтому поищу решения на С++. В крайнем случае на Win32Api буду сидеть пока. 

[RXL]

The Nameless One, скажи, а чем тебя пугают слоты/сигналы?
Сигнал - это вызываемый метод, слот - фактически выполняемый код. К одному сигналу можно подключить несколько слотов. Простая и удобная система.

Борланд - соглашусь - извращение. Но успешно пишу на BCB6 GUI-программы. Вполне съедобно и расширяемо.

[Джон]

"люди, проектировавшие MFC, обладали поверхностными знаниями о принципах ООП".

Бред сивой кобылы. У людей разрабатывающих MFC была проблема сделать OOP оболочку над НЕ OOP API. Вот в чём проблема. Винда писалась на С. Даже не на С++. Причём эта обобёртка должна была обеспечивать всю гибкость работы с Win API, иначе бы её сразу бы же закопали. Поэтому в MFC ты можешь запросто делать мешанину из объектов и прямых вызовов API ф-ций без всяких дополнительных врапперов а ля .NET, VB, Delphi и тп. Конечно это далеко от чистого ООП, и правы те, кто утверждает, что MFC не есть чистый ООП, но это не было самоцелью. Цель тогда была одна, на тогдашнем уровне (учитывай ресурсы железа тоже) помочь программеру создавать GUI приложения под виндой. И не надо ждать от него большего или идеального.

И к тому же, а в студии 2010 есть ли MFC и какой он?

Понятия не имею. Её ещё не трогал.

Например удобная ООП-обертка вокруг того же Win32Api, GTK+ и т.д.

Удобная для кого? Вот тебе фактик. До недавнего времени два самых больших серьёзных программерских ресурса codeguru и codeproject состояли на 90% из MFC. В последнее время всё больше наседает .NET (отчасти по праву, отчасти благодаря пропихиванию МС). Лично мне нравятся оба. ИМХО они замечательно дополняют друг друга.

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

Понятия не имею, что значит сигналы и слоты.

Насчет WTL - если это только для Борланд, то нет. Потому что полностью соглашусь с вами, что Борланд  С++ - это извращение

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

А WTL это никакой не борланд. WTL - это довольно удобная, компактная библиотека разработчиков MS. Однажды они решили её подарить широкой публике. С тех пор народ её расширяет и дополняет.
http://www.rsdn.ru/article/wtl/wtl-1.xml

C# все таки полноценный язык, к которому надо привыкать. Поэтому поищу решения на С++. В крайнем случае на Win32Api буду сидеть пока.

К С# я "привык" где-то за полгода. Спокойно. Сейчас уже не испытываю никакого дискомфорта и свободно владею и С++ и С#. Это даёт то преимущество, что я уже сразу знаю, на чём делат след. прожку. В зависимости от требований. Если навороченый GUI + DB, то однозначно C#. Если требуется компактная прожка с минимумом зависимостей, то MFC. Ессно всё под винду.

[RXL]

Жень, в Qt сигналы и слоты - это механизм передачи вызовов и событий между компонентами. Этакий конструктор с проводочками: берешь компоненты и соединяешь как надо.
Например, у тебя есть класс формы с компонентом Лампочка с методом-слотом Включить и обычная кнопка. Соединяем в конструкторе метод-сигнал Клик с методом-слотом Включить и больше никакого кода не требуется: по клику на кнопке лампочка включится. Сигнал - это то, что вызывается программно, как метод объекта, а подключенные к нему слоты - методы (причем они могут быть в разных классах и объектах), которые будут выполнены. Такой подход позволяет делать классы Кнопка и Лампочка совершенно независимыми и легко заставлять их взаимодействовать.

[The Nameless One]

The Nameless One, скажи, а чем тебя пугают слоты/сигналы?

В принципе не то что пугают. Qt, конечно, классная вещь, мне тоже понравилась.
Просто хочу посмотреть на альтернативы, пусть и не такие мощные.
А смущает вот что. Мне только GUI нужен, а такое ощущение, что Qt полностью новый язык нам дают, этакий Qt C++. Там и QString, и QVector и мн. д. Т.е. все стандартное замещают своим. Понятно, что это не навязывается, но все же.
И смущает слишком много изменений в родном синтаксисе С++, которые пришлось внести из-за этих сигналов и слотов.
Как я понял, если я пишу объект со слотами/сигналами, то

Код:

class Bob : public QObject   
{
   Q_QBJECT    // первая ласточка.  Дальше все определение класса будет переварено макросом. 
   private slot:    //вторая ласточка

   signal:            //третья
   void anotheSignal(); 
   void fsignal() { emit anotheSignal(); }   //emit 
};

Потом куча статичных методов QObject::connect / disconnect с макросами SIGNAL и SLOT внутри с не привычным синтаксисом для настройки всех связок.

Ещё раз повторю, ничего против не имею, хороший механизм, просто я ещё не очень опытный программист, знающий только С++ и совсем немножко ActionScript3, поэтому меня, наверное, это пока что смущает.


Джон,  спасибо за ответ и зы ссылку, почитаемс

А как вам, владеющему C++ и C# -
Меня тут недавно уверял один товарищ, что если я попишу на С# немножко, то меня начнёт подташнивать от С++.  Даже обидно стало:)

[Finch]

The Nameless One, Меня не подташнивало Писал и на том и на этом.

Джон, Чтобы понять, что такое сигналы и слоты. Это тот же бублик, что и делегаты. Только вид сбоку.

[Dimka]

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

Совершенно верно сказано

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

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

У людей разрабатывающих MFC была проблема сделать OOP оболочку над НЕ OOP API. Вот в чём проблема.

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

Причём эта обобёртка должна была обеспечивать всю гибкость работы с Win API, иначе бы её сразу бы же закопали. Поэтому в MFC ты можешь запросто делать мешанину из объектов и прямых вызовов API ф-ций без всяких дополнительных врапперов а ля .NET, VB, Delphi и тп. Конечно это далеко от чистого ООП, и правы те, кто утверждает, что MFC не есть чистый ООП, но это не было самоцелью. Цель тогда была одна, на тогдашнем уровне (учитывай ресурсы железа тоже) помочь программеру создавать GUI приложения под виндой. И не надо ждать от него большего или идеального.

Вот тут отчасти соглашусь.

Во времена проектирования MFC (90-е годы) на рынке присутствовали неторопливые машины, не владеющие ООП разработчики и имеющий различные родовые травмы WinAPI, на котором в чистом виде без обёрток писать было крайне утомительно. Ну нет в мире совершенства!

А вот выбор цели совершенно неодобряю - торопливость в условиях конкуренции, мировая экспансия MS, продвижение платформы в массы. Это, конечно, всё имеет смысл, но и порождает кучу проблем, висящих историческим грузом на MS и удорожающих их продукцию. Общество от этого не выигрывает.

Меня тут недавно уверял один товарищ, что если я попишу на С# немножко, то меня начнёт подташнивать от С++.  Даже обидно стало:)

Студенты в один голос говорят, что C#/Java в программировании и разработке приложений проще, чем C++. Нет разделённых по файлам заголовков и реализации, нет (вернее, не нужны студентам) директив компилятора, нет заморочек с управлением памятью и указателями. Всё это облегчает старт для вхождения в язык, среду разработки и библиотеки, начало прикладного программирования. К C++ тяготеют лишь любители быть "круче" остальных или те, кто заранее знает, что ему будет нужен C++ в будущей работе.

[The Nameless One]

Бегло пробежался по C#, обратил внимание на делегаты.
Теперь стало ещё понятнее, почему Qt прибегло к слотам и сигналам.

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

Код:

  
delegate string delTest(string s);
...
delTest test = param =>
{
   param += "dddd";
};

Console.WriteLine(test("strochka"));   //будет  strochka dddd
...

Почему их нет в С++ ?

[Finch]

Объясни для чего? Мне нужно именно твое понимание.

[Джон]

Ром, Вить, я не в том плане, что меня интересует, что именно это за штуки, а в том, что мне это в данный момент не надо знать. Партия скажет: "Надо!", - освоим и сигналы, и  шлагбаумы, и другую железнодорожную премудрость. Я уже давно вошёл в тот возраст, когда любят тот язык и IDE, за которые платят бабки. И все эти "уливары" мне по барабану, ими заниаются люди, у которых много дурного времени и им его девать некуда.

Димка, твою любовь к MFC я уже давно знаю, посему большую часть (эмоциональную) оставлю без коментов, ни к чему это. В глубине души ты знаешь, почему так всё получилось. А вот это:

А вот выбор цели совершенно неодобряю - торопливость в условиях конкуренции, мировая экспансия MS, продвижение платформы в массы. Это, конечно, всё имеет смысл, но и порождает кучу проблем, висящих историческим грузом на MS и удорожающих их продукцию. Общество от этого не выигрывает.

в тебе говорит неистреблённый коммунист (в хорошем смысле этого слова). Какая забота о обществе в буржуинской системе? О чём ты? На сегодняшний день факт остаётся фактом - МС заработали на этом деле кучу бабок и, если честно, то глубоко по барабану, как они это сделали. Им конечно. Но такова суровая правда жизни.

Студенты в один голос говорят, что C#/Java в программировании и разработке приложений проще, чем C++.

Ещё бы! Ява форева! Замечательный язык. Для студентов. Кстати, а кто-нить знает, почему логотипом Явы является чашечка с кофе?

А как вам, владеющему C++ и C# -
Меня тут недавно уверял один товарищ, что если я попишу на С# немножко, то меня начнёт подташнивать от С++.  Даже обидно стало:)

В первое время приходилось трудновато. На С#. Всё выискивал в нем аналогию с С++. Потом бросил это занятие. У меня уже был подобный опыт. На С++ я переходил с Турбо Паскаля. Но дело не в языке, к нему-то довольно быстро привыкаешь, особенно если постоянно им занимаешься. Гораздо сложней именно с API. Вот и у меня тогда получилось, что я перешёл с ДОС на Винду.
А с С# уже такой проблемы небыло. Правда С# был под .NET 2.0, сейчас вот уже с 3.5 слезать не хочется с его лямбдами и LINQ. Но с С++ это нельзя сравнивать. Каждый по-своему отлично выполняет свои задачи. Не забывай, что С++ это универсальный язык программирования, а С# - язык специально разработанный для .NET платформы, и ессно учитывает её специфику. Поэтому совет на будущее не заморачивайся сравнением и вопросами а ля "почему тут так, а здесь не так". С таким настроем далеко не уедешь.
Я в таких случаях всегда вспоминаю своего учителя по немецкому, когда я до него докапывался с вопросами в стиле "а почему это так?" или "а из чего это следует?", он всегда говорил: "100 000 человек в год выучивают немецкий язык, не задаваясь подобными вопросами. Поэтому не спрашивай, а бери и учи." И таки выучил.

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

[RXL]

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

[The Nameless One]

Объясни для чего? Мне нужно именно твое понимание.

Не буду заниматься копипастой - поэтому ссылка. Так и понимаю http://habrahabr.ru/blogs/cpp/65798/
Только вот с новым стандартом непонятно, когда появятся компиляторы, реализующие его?

Джон,  большое спасибо, очень информативный для меня ответ И полезный)

[Джон]

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

ps Это объяснение я услышал от нашего доцента по Яве. Чесслово не вру.

[Вад]

Объясни для чего? Мне нужно именно твое понимание.

Не буду заниматься копипастой - поэтому ссылка. Так и понимаю http://habrahabr.ru/blogs/cpp/65798/
Только вот с новым стандартом непонятно, когда появятся компиляторы, реализующие его?

Нескоро, надо думать. Они драфт ещё пока только на всеобщее обсуждение выдвигают: пока поправят, пока примут...
Сами-то компиляторы потихоньку готовят - поддержка фич c++0x уже как бы есть.

Кстати, на редкость мерзкая реализация лямбд, честно говоря.

[Dimka]

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

Это вообще из функционального программирования. В C# появилось недавно - неодобряю. По большому счёту оно там не нужно, поскольку использование вычисленного значения в нескольких местах прекрасно организуется через введение переменной. А смешивать стили в одну кучу - это делать трудночитаемый код. Одобряю лишь анонимные методы в делегатах и yield, правда, последний несколько убого реализован. Лучше бы замыкания развивали, взяв за основу yield - с их помощью можно обойтись без функциональных вставок.

Я в таких случаях всегда вспоминаю своего учителя по немецкому, когда я до него докапывался с вопросами в стиле "а почему это так?" или "а из чего это следует?", он всегда говорил: "100 000 человек в год выучивают немецкий язык, не задаваясь подобными вопросами. Поэтому не спрашивай, а бери и учи." И таки выучил.

Не всё так просто. Я в английском долго и упорно не понимал артиклей, пока, наконец, не объяснили, что a/an - это редуцированный one (один, некий, какой-то), а the - редуцированный this/these (этот/эти, вот этот, он же, тот же самый). Хотя, по большому счёту, без всякой рефлексии о причинах происхождения заучиваются ситуации употребления, особенно если в подходящей среде находишься.

Но аналогия с языками программирования мне не кажется верной. В естественных языках изменение конструкций, структуры связаны с изменением смысла. В языках программирования (формализованных) смысл всегда однозначен, поэтому имеет значение связь формы со смыслом, и очень даже можно задавать вопросы вида "почему так?". Только The Nameless One не о том спрашивает Сравнивать синтаксис языков, в самом деле, пустое занятие. Сравнивать нужно семантику.

[The Nameless One]

Кстати, на редкость мерзкая реализация лямбд, честно говоря.

Может, ещё поправят...  

[Джон]

Да, Димка, совсем забыл.

Другой вопрос, зачем его до сих пор поддерживать.

Я думаю ответ очевиден. Альтернативы у МС нет, а потребности в таком враппере есть. И до тех пор MFC будет обладать некоторыми свойствами дедушки Ленина.

Тут уже небольшое пересечение с другой темой, которую поднял Рома, про ИЕ9. Я хотел было туда втиснуться, да не успел вовремя. Но суть такая же.
Пока существует рынок, потребители, будет существовать продукт. Стоит ли предъявлять претензии к изготовителю? У буржуев (а теперь и у нас с вами) строго соблюдается чёткая причинно-следственная связь. О целеосообразности, практичности и прочим критериям здравого смысла отводится последняя роль. Как сказала героиня в одной киношке: "Плевать, главное чтобы покупали." (с) к/ф "Отрыв по полной". И оно так и есть. IE, МFC и иже с ними будут такими, какие они есть пока есть пользователи, вернее их определённое количество. Готов поспорить, что перейди сейчас 99% юзверей на не МС браузер, они через полгода отреагируют версией IE10 самым быстродействующим с поддержкой HTML6 Аналогичная картина наблюдается и с MFC. Интерес разработчиков (а не теоретиков идеалистов) к ней пока не увял. И МС проводит довольно хитроумную политику, выталкивая на передний план .NET, не забывает и о MFC. Свидетельством тому 2008 студия.

[Джон]

Не всё так просто. Я в английском долго и упорно не понимал артиклей, ...

Не, Димка, аналогия не в этом смысле. Понимание конечно нужно. Я про принцип. Посуди сам, если на сегодняшний день, человек стоящий перед выбором (новичок) начнёт только и делать, что сравнивать все существующие на сегодняшний день решения, к чему он придёт? Если вместо того, чтобы учить язык таким какой он есть будет выискивать его недостатки, или понравившиеся ему в других языках конструкции, отсутствующие в данном языке? Прогресса не будет. Надо брать и делать. И в данном конкретном случае это относилось к вопросу The Nameless One о лямбдах и делегатах в С++. Кстати, на codeproject ребята занимались темой делегатов в С++.

[The Nameless One]

В общем, мой выбор Qt.
C# наскоком не возьмёшь, как я сначала попытался. Поковырял теорию с часик другой, думал после С++ можно быстро "вьехать". Не тут то было. И почему все говорят, что шарпы легче С++?
Трассировки, слушатели, атрибуты...  Ну ладно LINQ после ActionScript3 кажется знакомым, но остальное...
В общем, припрёт - буду учить C#, а сейчас я лучше буду расширять свой кругозор через призму С++.
Главное, проект закончить. Тем более что в дальнейших планах глубокое изучение DirectX, OpenGL, LUA.

А сейчас гораздо быстрее выучить новую библиотеку, чем новый язык + новый frameworк.

Большое всем спасибо!

[Джон]

И почему все говорят, что шарпы легче С++?

Кто все? Фамили, имена, адреса? Найди баааальшой такой камень, и брось его в тех, кто это говорит.

На С# ПРОЩЕ СОЗДАВАТЬ GUI ПРИЛОЖЕНИЯ  ПОД ВИНДУ СО СТАНДАРТНЫМИ КОНТРОЛАМИ, но это ещё не делает сам по себе C# проще. Особенно на стадии обучения (изучения) я бы советовал держаться подальше от лябд и LINQ, да и от всех сокращённых записей. Дебаггером по ним гулять ну очень неудобно.

Очень хорошо, что ты решился взяться за что-то одно и добить до конца. На будущее, вот такая аллегория. Представь себе металлообрабатывающие станки. Бывает токарный, бывает фрезерный, бывает сверлильный. Каждый хорошо подходит для выполнения определённого рода операций (поэтому они и существуют всякие разные), хотя некоторые операции сверления можно выполнять и на токарном станке, а фрезу можно зажать и в патрон сверлильного. А в большинстве случаев можно обойтись напильником.
Так же и со средами разработки ПО. Хорошо, если ты познакомишься со всеми (с большинством) из них, в будущем тебе проще будет сделать выбор для поставленных задач.
А может и наоборот, выбора не будет, а будет стоять один "токарный станок" и либо работай на нём, либо иди жвачку с асфальта отколупывай.

Но в данном случае, при условии:

Главное, проект закончить.

концентрируйся на чём-нить одном и долби, долби, долби...