Qt vs. .NET

Лично я сделал для себя выбор: я буду учить и использовать библиотеку Qt. Во-первых, она кросс платформенная. Для меня это очень актуально, потому что приходится сидеть как на виндовс так и, в большей степени, на линуксе. Во-вторых, бесплатная. Впрочем за .NET тоже платить не надо, но все равно приятно. В-третьих, с ней приятно работать. Это уже не мой слова. Я их вычитал из книги, которая учит программировать с помощью Qt. Хочу услышать ваше мнение.
P.S. если вы не знаете ни одну из библиотек, то лучше ничего не пишите.

0

0

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

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

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

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

Сообщение от novi4ok ладно, я все и так понял.

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

По поводу "и эта переносимость, мне кажется, существует на уровне исходного кода" (речь шла о .net) ты в корне не прав. Когда-то я уже пояснял https://www.cyberforum.ru/post504573.html, там маненько про другое, но смысл в том, что java и .net разрабатывались для того, чтобы переносимым был именно бинарник, а не исходный код (хотя исходный код при таком раскладе тоже является переносимым). Переносимость на уровне бинарного кода - это единственный способ сделать приложение по настоящему переносимым. Полноценной переносимости не удалось достичь ни с Си, ни с Си++, но удалось с java и теоретически (потому что практически всё-таки не реализовано) удалось с .net

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

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

0

Сообщение от Evg Потому что резина для бмв отличается от резины для тойоты, грубо говоря, габаритными размерами. И потому дешевле и эффективнее штамповать каждому своё, чем изобретать что-то общее

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

Сообщение от Evg Как раз-таки наоборот. Это раньше каждая платформа жила обособлено, а теперь, когда компьютеры по уровню доступности стали обычной "бытовой техникой" многие разработчики на сегодняшний день пытаются выпускать продукты, работающие на разных платформах. "Самоцель" - это когда принципиально пишут программы без использования goto или когда принципиально пишут на Си вместо Си++, а многоплатформенные приложения (такое термин, как мне кажется, более правильный, чем "кроссплатформенные") в нынешнем мире - это уже необходимость.

я имел ввиду постоянный поиск (с тех пор как народ начал делать эвм и писать на них программы, и оказалось, что это - ужасно ресурсоемкий процесс, причем в человеко-месяцах плохо изменяемый) "простых и понятных" способов, как не начинать создавать каждую программу заново, а возможно эффективнее использовать ранее созданный код (в каком-нибудь виде). многоплатформенность - типичная иллюстрация преимуществ и недостатков стандартизации: с одной стороны, иметь стандарт хорошо (если резьба правая м5 со стандартным шагом, то любой винт и любая гайка м5 друг другу подходят), с другой стороны - должна быть конкуренция и должен быть выбор. поэтому даже в ссср выпускали и победу, и москвич, и (позже) запорожец. так вот, обычно, если предприятие выпускает резину для москвича, то "портировать" производство на резину для волги - не большая проблема. по крайней мере проще, чем, как ты говоришь, изобретать кросмашинную резину. портирование же программ - почти такой же трудоемкий процесс, как и создание новой. портирование с языка на язык, с ос на ос, с библиотеки на библиотеку, ... и вот тогда началось: мы придумаем, как написать что-то один раз, и потом не переписывать "это" никогда более. сперва это был "модуль", "библиотеки подпрограмм", классы, компоненты, "кроссплатформенные технологии". жава - пример такой кроссплатформенной технологии. .net, crl - напротив, не задумывались как кроссплатформенные. их портирование - фактически попытка портировать технологию. причем не копируя архитектуру и концепцию, а именно попытка создания адаптера для москвича, позволяющего цеплять на него колесья от тойоты. при этом можно еще и немножко ездить. "не нужны нам тойоты! мы и на москвиче как на тойете! видите - колесья её родные прикручены!". попытка, изначально обреченная стать игрушкой или геморроем (или одновременно и тем и другим), потому что если создавать нечто кроссплатформенное, то нужно это заложить в концепцию, как это было с жавой. все остальное - напрасная трата времени. юниксы нужно использовать там, где это удобнее, и не обязательно стремиться заставить мир полность отказаться от виндоуз. а главное - такое неуклюжее портирование технологии не ведет к достижению изначальной (забытой, но главной) цели - повторного использования уже созданного программного продукта.
(ого набухтел я! вчера фирма в ресторан водила, видимо так это у меня выходит)

Сообщение от Evg смысл в том, что java и .net разрабатывались для того, чтобы переносимым был именно бинарник, а не исходный код

совершенно верно. разница лишь в том, что для жавы изначально предполагалась кроссплатформенность, для дотнета - нет. кроме того, дотнэт - не просто "виртуальная машина". это скорее "универсальное приложение", которое "умеет делать все", никогда не делает ничего такого, что заваливает ос, и код больше напоминает не программу, а "конфигурацию" для "приложения" .net framework. кроме того, фреймворк - не аналог "виртуальной машины". он теснее привязан к ос, чем виртуальная машина жавы, и выполнение иначе организовано. хотя выделывать фокусы можно и с дотнэтом (как и жава-программу скомпилировать в *.exe. причем как из исходника, так и из жава-кода. не предполагали, но что мешает?)
[QUOTE=Evg;1210972]

Сообщение от Evg Так уже есть коммерческие дистрибутивы, которые со стадии "штампуются" перешли на стадию "вылизываются". Я их своими глазами никогда не видел, но подозреваю, что они более надёжные и устойчивые, чем бесплатные.

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

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

0

Сообщение от novi4ok .net, crl - напротив, не задумывались как кроссплатформенные. их портирование - фактически попытка портировать технологию. причем не копируя архитектуру и концепцию, а именно попытка создания адаптера для москвича, позволяющего цеплять на него колесья от тойоты.

Только здесь есть принципиаильный момент. Портирование фрэймворка - это по сути одноразовая задача и является заботой поставщика операционной системы. Но это НЕ есть задача программиста (который пишет приложение). На любую технологию нужно смотреть с двух позиций: со стороны разработчика и со стороны пользователя. При использовании языков программирования под native-код все потуги, требуемые для переносимости, возлагаются на пользователя (т.е. программиста, который реализует прикладную программу). При использовании технологий типа java или .net на пользователя такие дела не перекладываются и остаются заботами разработчика технологии. Я не специалист по java и .net, возможно там где-то и нужно напрягаться для переносимости, но в любом случае не в таком объёме, как на языках под native-код

.net задумывалось как инструмент для переносимости программ между разными версиями Windows. Насколько я понимаю, это им удалось. В то время как программа написанная на Си скомпилится под линукс 10-летней давности, и не скомпилится под современный линукс (я уж не говорю о том, что не запустится) - это вполне обычное явление. При этом спроектирована технология таким образом, что её можно пернести (портировать) на прочие архитектуры. Другое дело, что политические соображения не дают этому делу нормально разиваться.

Сообщение от novi4ok юниксы нужно использовать там, где это удобнее, и не обязательно стремиться заставить мир полность отказаться от виндоуз

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

Сообщение от novi4ok .net framework. кроме того, фреймворк - не аналог "виртуальной машины". он теснее привязан к ос, чем виртуальная машина жавы, и выполнение иначе организовано.

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

Сообщение от novi4ok но аргументы "за" у него просто никакие. "автор одной книги про qt пишет, что это кайф". а что должен написать автор книги, на обложке которой стоит qt?

Каждый человек на этапе развития своих профессиональных навыков проходит через такую стадию. В этом тоже нет ничего плохого

0

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

ничего плохого, конечно. само название темы достаточно красноречиво говорит за этап развития. "Qt vs. .NET". вроде как "нота ля vs. пятая симфония бетховена", или сравнение зеленого с горячим

0

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

0

Сообщение от demonmov Еще такой вопрос: я так понимаю, если сравнивать прогу написанную на Qt для виндовс и прогу написанную на .нет, то скорость выполнения и размер проги будут меньше во втором случае?

Программа на Qt, как и любая другая в native-коде может быть слинкована динамически или статически. В случае динамической линковки у тебя будет маленький бинарник, но при запуске программы всё равно будут загружаться динамические библиотеки (и памяти, соответсвенно, будет жраться столько, сколько весить программа плюс все динамические библиотеки). Динамические библиотеки, как правило, находятся в специальных системных каталогах и используются многими приложениями. Т.е. при компиляции двух программ мы имеем на диске два коротких бинарника и ожну большу динамическую библиотеку. При исполнении динамическа баблиотека в физическо памяти загружена только один раз,независимо от того, сколько программ ею пользуются

В случае статической линковки все требуемые библиотеки зашиваются в бинарник. И получается большой бинарник. Который при исполнении целиком загружается в память и уже нет возможностиотделить в этом бинарнике коды программы от кодов библиотеки. Для двух программ у тебя получатся два больших бинарника. При запуске каждый бинарник жрёт свою память (потому как нет возможности выделить общие фрагменты). Но такой бинарник можно таскать на любой комп и он уже не будет зависеть от наличия оли отсутсвия на компе требуемых динамических библиотек

В .net'ом по сути дела то же самое, только framework фактически исполняет роль динамической библиотеки. Точно так же можно скомпилять что-то типа статически слинкованного бинарник, но это будет код .net склеенный с кодом framework'а в единый файл.

Принципиальное отличие .net от Qt в этом вопросе состоит только в том, что обычно предполагается, что framework на машине установлен, а Qt - нет. Поэтому Qt'шные программы как правило поставляются либо в статически слинкованном виде (т.е. большой бинарник), либо в динамически слинкованном виде, но вместе со всеми динамическими библиотеками (т.е. целая куча файлов, которая весит примерно столько же, сколько и статически слинкованный код)

Добавлено через 1 минуту
А скрость выполнения - завист от конкретной программы. Где-то может оказаться скорость выше у Qt, где-то - у .net

0

Evg, понятно, спасибо за такой подробный ответ.

0

Сообщение от Evg При исполнении динамическа баблиотека в физическо памяти загружена только один раз,независимо от того, сколько программ ею пользуются

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

0

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

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

0

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

0

Сообщение от alex_x_x таким образом они избавляются от dll hell'a

Чаво?...

0

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

зависит от того, как грузятся дллы: на этапе загрузки приложения (старта), или на этапе выполнения (load time dynamic linking / run-time dynamic linking). во втором случае так и происходит, как ты говоришь. в первом - нет.

Добавлено через 5 минут

Сообщение от alex_x_x винда давно пошла по пути, что у каждой программы - свои dll'и

это очень не так.

Добавлено через 26 минут
кстати, во втором, думаю, тоже не всегда так происходит, но уже не уверен.

0

Сообщение от novi4ok это очень не так.

ну объясните же, я это из здравого смысла и прямой цитаты рихтера сказал
естественно речь не идет о всяких kernel32.dll

Добавлено через 33 минуты

Сообщение от novi4ok зависит от того, как грузятся дллы: на этапе загрузки приложения (старта), или на этапе выполнения (load time dynamic linking / run-time dynamic linking). во втором случае так и происходит, как ты говоришь. в первом - нет.

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

rtfm вообщем

Evg, стандартная ситуация невозможности контроля версий общих dll

0

Сообщение от alex_x_x если два процесса загружают одну и ту же dll, то система проецирует им на адресное пространство одно и то же пространство dll

Сказано немного криво, но именно так и происходит в юниксах. Динамическая библиотека однозначно определяется её полным путём в файловой системе. Далее сегменты кода и Read-only данных маппируются shared-образом, а дальше ОС устраивает таким образом, что в физической памяти один экземпляр библиотеки, но она отмапирована в виртуальное пространство каждого портебляющего её процесса

0

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

0

куда уж там на пальцах, в c# не надо знать, что dll вообще существует

0

Сообщение от alex_x_x куда уж там на пальцах, в c# не надо знать, что dll вообще существует

в принципе, можно и c# не знать. но ведь если чуть дальше хэлло уорлд идти, то без add reference не обойтись. а там эти гадкие dll!

0

Сообщение от novi4ok гадкие dll

И чем же они гадкие?

0

Сообщение от CyBOSSeR И чем же они гадкие?

не кроссплатформенные

0