Ларс Нол (Lars Knoll), создатель KHTML и директор по развитию фреймворка Qt в Nokia, анонсировал (http://labs.qt.nokia.com/2011/09/12/qt-project/) план по переводу проекта на более открытую модель разработки, предполагающую более тесное сотрудничество Nokia, сообщества и компаний, заинтересованных в развитии проекта.
Для достижения этой цели будет создана новая эксосистема, включающая в себя репозиторий исходных текстов, wiki, несколько дискуссионных листов, инструмент отслеживания ошибок, систему рецензирования, автоматического тестирования и включения изменений в код. Все это будет привязано к домену qt-project.org (http://qt-project.org). Управлением инфраструктурой будет заниматься специально созданная некоммерческая организация.
Дальнейшее развитие проекта будет координироваться управляющей группой, в которую войдут мэйнтейнеры, крупнейшие контрибьюторы и люди, ответственные за принятие патчей. Группа будет сформирована на основе принципов меритократии (http://ru.wikipedia...URL: http://labs.qt.nokia.com/2011/09/12/qt-project/
Новость: http://www.opennet.me/opennews/art.shtml?num=31734
Может теперь они откажутся от V8 в core и прочего тормозного уродства, которым хотят набить Qt5.
Нет, все верно делают. Плохо только то что завязано все будет на один язык, тогда как более мощные фреймворки как .NET дают возможность выбора любого языка.
Так там и компиляция не в нативный код идёт, как в Qt
> Так там и компиляция не в нативный код идёт, как в Qtв нативный, с промежуточной стадией
нет
Ничего нативного там нет и небыло. Генерится байткод, который выполняется в подобии виртуальной машины. Вы бы книжки почитали.
> Ничего нативного там нет и небыло. Генерится байткод, который выполняется в подобии
> виртуальной машины. Вы бы книжки почитали.Лишь бы ляпнуть.
Человек всё верно написал. В сборке лежит байткод, а исполняется таки нативный код полученный JIT-компилятором. Существуют также AOT-решения - тот же monotouch например.
>В сборке лежит байткод, а исполняется таки нативный код полученный JIT-компиляторомТо есть по вашему все таки технология правильно формулируется "исполняется нативный код"? Ну вы даете, facepalm.jpg. По вашему так же и жава выполняет нативный код. Да, процессор то выполняет нативные для себя инструкции, но технология формулируется правильно словами "выполнение байткода в виртуальной машине". Стыдно за вас.
А вот как раз qt генерит нормальный нативный код. Компилируется С++ компилятором в нормальный нативный код под платформу, использует свои библиотеки, обычный бинарник. В отличает от дотнетов и жавы, тьфу противно.
Это не всегда безопасно. .NET - хорошая технология.
> Это не всегда безопасно. .NET - хорошая технология.Да конечно, 30 лет это было безопасно, но потом появляется дотнет и все остальное становится вдруг "не всегда безопасным", ага. Итого: программировать надо уметь, ошибки не допускать надо учиться, но те, кто попробовал "программирование" на .net - этого им уже не понять и не нужно им это, потому что у них нет цели программировать хорошо и безопасно, а есть цель выпускать продукт для покупателя, предлагать решения для заказчика, и тд, в общем - зарабатывать деньги. И тогда они пишут "Это не всегда безопасно. .NET - хорошая технология", опуская слова "потому что позволяет делать прибыль очень малыми силами, работниками невысокой квалификации, быстро, дешево, просто, не нужно думать о бла-бла, и нанимать хороших программистов, которые умеют программировать, и не шлепать формы"
> Да конечно, 30 лет это было безопасно30 лет назад компы были маленькими, а программы уже требовались большие. Отсюда и всякие небезопасные функции и методы, ибо в противном случае производительность просаживалась дико. И опасными они стали не потому что появился .net, а потому что иметь стали через дыры, в результате появились, например, те же strn* функции.
> программировать надо уметь, ошибки не допускать надо учиться
Это конечно хорошо, но работает только в теории. На практике вдруг резко оказывается что все мы люди и ошибок нет только в проектах уровня hello world и то потому что их никто там не искал.
> у них нет цели программировать хорошо и безопасно
Хорошо и безопасно это значит долго и/или дорого. А клиенту нужно сейчас и подешевле, потому что задачи которые нужно решать появились вчера.
> Хорошо и безопасно это значит долго и/или дорого. А клиенту нужно сейчас
> и подешевле, потому что задачи которые нужно решать появились вчера.Ну вот вы все и сказали. Стыдно за вас, и наверное не одному мне.
>> Хорошо и безопасно это значит долго и/или дорого. А клиенту нужно сейчас
>> и подешевле, потому что задачи которые нужно решать появились вчера.
> Ну вот вы все и сказали. Стыдно за вас, и наверное не
> одному мне.Да мне как-то пофиг стыдно вам или нет. Просто у вас перфекционизм - код нужно писать хорошо и качественно. Но мои клиенты (да и не только мои) умеют считать деньги. И вдруг резко оказывается что быстро сделать работающий вариант и потом его допиливать и добавлять функционал всяко выгоднее чем сразу пытаться сделать супер-пупер версию.
В случае JVM/.NET окончательная компиляция из байт-кода происходит непосредственно перед/во время работы приложения, а не во время работы компилятора типа gcc (который один фиг должен держать внутри AST в бинарном виде), всё остальное остаётся таким же. «Ну вы даете, facepalm.jpg». Привет!
это частности реализации, jit не обязателен.
если я пройдусь ngen-ом по сборке в результате чего будет создан native image и покладен в соответствующее место в gac-е. При исполнении данной сборки VM и JIT ясный красный не используются. Дык что будет исполняться? :)
> выбора любого языка.И любой платформы. При условии что это виндоус.
C++ уже большое тормозное уродство.
Use pyQt, Luke.
> Use pyQt, Luke....и большим тормозным уродством станет ваша программа :)
Биндинги - это костыли из прошлого века. Платформа должна быть спроектирована так, чтобы в биндингах не было необходимости - .NET. Любую библиотеку можно использовать из любого языка.
Кроме того в pyqt уже отпала необходимость. В qt5 высокоуровневый код пишется на js, а ворочать мешками можно на С++.
> Биндинги - это костыли из прошлого века. Платформа должна быть спроектирована так,
> чтобы в биндингах не было необходимости - .NET.Да чо там, яву сразу давай. На ее VM куча всякого фуфела запускается. При том тормозное и кривое все как на подбор. Кстати с пиаром дотнета вы немного опоздали. Разве ваши менеджеры еще не вправили вам моск? Новый хит сезона - хтмл5. Поэтому в виндоус8 в центре внимания именно он, а не какие-то там сраные дотнеты.
В MS ещё те троли работают. HTML5 это тру, это будущее, cutting edge и всё такое, вам об этом любой птушник скажет. И что по вашему должна MS делать? Сказать пошли все в жопу юзайте сервелат? Дык народ не поймёт, да и зачем отдавать место под солнцем если можно занять малыми силами. При этом, смею заметить, никто не отказывается ни от сервелата (ждём пятый к концу года), ни от .net (ждём 5-й в следующем году), ни от WinForms и WinAPI (которые дописываются и расширяются).
>Платформа должна быть спроектирована так, чтобы в биндингах не было необходимости - .NET. Любую библиотеку можно использовать из любого языка.Ога, например, из джавы :)
> C++ уже большое тормозное уродство.Лучше для навернутых десктопных программ пока ничего не придумали. На яве и прочих питонах - тормозить будет до усрачки. А так - даже юзабельно получается.
Придумали, и даже раньше плюсов - Си.
Утечки и проблемы выходы за границы. Прошлый век же.
> Утечки и проблемы выходы за границы. Прошлый век же.Я и Торвальдс смотрим на вас с удивлением?
Мы про ядра говорим или про десктопные приложения?
Выход массива за границы и разыменование нулевого указателя - едва ли не самые частые ошибки в программах на С, и они отлично устранимы в принципе. Человеку, если он хочет быть производительным, не стоит заниматься рутиной и повторением одних и тех же паттернов кода 20 раз только потому, что его язык не позволяет ему их абстрагировать - он ОБЯЗАТЕЛЬНО ошибется на 16-й раз, забудет или опечатается. Рутину разумно поручать автоматике: оптимизирующему компилятору, макропроцессору и т.п. - собственно, вся история программирования и идет вдоль идей абстрагирования и модуляризации. Я не говорю, что непременно следует использовать мешанину под названием C++ (хотя его подмножество без особо запутывающих код наворотов - возможно), но С как-то слишком низкоуровнев для этого
>[оверквотинг удален]
> Выход массива за границы и разыменование нулевого указателя - едва ли не самые частые
> ошибки в программах на С, и они отлично устранимы в принципе. Человеку, если он хочет
> быть производительным, не стоит заниматься рутиной и повторением одних и тех же
> паттернов кода 20 раз только потому, что его язык не позволяет ему их абстрагировать -
> он ОБЯЗАТЕЛЬНО ошибется на 16-й раз, забудет или опечатается. Рутину разумно поручать
> автоматике: оптимизирующему компилятору, макропроцессору и т.п. - собственно, вся
> история программирования и идет вдоль идей абстрагирования и модуляризации. Я не говорю,
> что непременно следует использовать мешанину под названием C++ (хотя его подмножество
> без особо запутывающих код наворотов - возможно), но С как-то слишком низкоуровнев для
> этогоА у меня как-то нет таких проблем. Может из-за того что абстрагируют от рутины - заменяя их макросами или заворачивая в функцию. Вы попробуйте - думаю понравится.
Главный плюс С в отличии от плюсов в том что при внятной архитектуре программы Вы не получите порно-шапито из-за навязанного стиля языка и Вам не придется ломать архитектуру из-за этого (именно из-за этого стараюсь избегать плюснутый си).P.S.: Пишу на С с удовольствием сохраняя (там где оправдано) объектную концепцию.
> Утечки и проблемы выходы за границы. Прошлый век же.Внезапно, память может утекать и в языках с автоматическим управлением памяти. Лично видел как сайт оставленный на ночь утром выжирает 1Gb памяти. На любом браузере. При том что просто показана страничка. Если это не "утечка памяти", а хотя-бы и в JS - я тогда уж и не знаю.
А я видел как заходит солнце. Или оно падает за горизонт?
Си, какими свистулями его не обкладывай - другая весовая категория по сравнению с Qt. Вы, наверно, это знаете... И все равно пишите...
> Си, какими свистулями его не обкладывай - другая весовая категория по сравнению с Qt.Вы сравниваете вкусное с тяжелым.
- Ваш Кэп.
> Придумали, и даже раньше плюсов - Си.Для именно навернутых, типа гамез с задрюченной логикой, плюсы получше будут. Хотя мастера своего дела типа Кармака и на Си не тушуются. На то и мастер, чтоб голыми руками гвоздь в доску одним ударом загонять.
"Лучше для навернутых десктопных программ"
Я вам скажу, придумали, это Delphi :) правда выбор платформ очень ограничен :)))А вот как раз на яве, например, очень "навернутая" десктопная программа вряд ли будет тормозить больше чем такая же на последнем QT :) а вот геммора при написании вполне может быть меньше
Ну, жаба на десктопе тормозить будет. Ее достоинства в обработке данных и клиент-серверных решениях. Хотя Sun для солярки делала на жабе основной рабочий стол со всеми менюшками, панелями, лотками и пр. На вид было что-то среднее между гномом и кде3. И работало достаточно быстро.
Java Desktop - это гном
> Я вам скажу, придумали, это Delphi :) правда выбор платформ очень ограничен :)))Не, спасибо, такими платформами и программами - пользуйтесь пожалуй сами. Ведь свое - не пахнет, правда? А я ни 1 нормальной программы на дельфи еще не видел. Дельфисты вообще давно стали эталоном отстоя.
>> Я вам скажу, придумали, это Delphi :) правда выбор платформ очень ограничен :)))
> Не, спасибо, такими платформами и программами - пользуйтесь пожалуй сами. Ведь свое
> - не пахнет, правда? А я ни 1 нормальной программы на
> дельфи еще не видел. Дельфисты вообще давно стали эталоном отстоя.Точнее, не замечали. Total Commander, QiP, Inno Setup, KMPlayer, The Bat!, Skype... А вообще, гугль подсказывает, например, такое: http://delphi.wikia.com/wiki/Good_Quality_Applications_Built...
А насчёт эталона отстоя - никто и не спорит, что в своё время было море разливанное "начинающих программистов", которые ушли немногим дальше тыканья по редактору форм. Сейчас такие умы вместо Delphi и Visual Basic чаще "пишут" (рука не подымается убрать кавычки) на PHP, Python и JavaScript. И это не отменяет того факта, что есть и хорошие специалисты по всем перечисленным языкам. :)
> Точнее, не замечали. Total Commander, QiP, Inno Setup, KMPlayer, The Bat!, Skype...Ну сейчас то Скайп плюсовый и даже Кьютовый
>> Точнее, не замечали. Total Commander, QiP, Inno Setup, KMPlayer, The Bat!, Skype...
> Ну сейчас то Скайп плюсовый и даже КьютовыйВерно. Но начинал он, будучи ещё не "раскрученным", с Delphi. :) Сейчас-то его хоть на JS перепиши, будут пользоваться...
для винды версия по прежнему на делфе
Чем проще средства разработки, тем больше студентов и школьников будет их осваивать. Как следствие появляется куча "крутых" программ от них. Вот эти программы и сослужили дурную славу Delphi.
У Delphi есть масса плюсов, и не вина среды разработки в целом и OP в частности, что сделала доступным программирование для "самых маленьких".
Хотя в России почему то исстари больше любили учить Турбо Паскалю, нежели Турбо С.
Потому, что например, на моей ec-1841 (pc-xt) этот самый турбо паскаль в отличии от остальных турбо и не турбо с..с++, работал шустренько и довольно неплохо
а С ни чем не лучше паскаля (не считая религиозных проблем и разницы в синтаксисе в мелочах)
> а С ни чем не лучше паскаля (не считая религиозных
> проблем и разницы в синтаксисе в мелочах)традиционно — оптимизатором лучше.
Извините, конечно, но это бред,
современные компиляторы оптимизируют все и вся
Жду пример перегрузки операторов(+ - * = == и т.п., а особенно new и delete) в паскале.
А можно в паскале сделать operator int()? А шаблоны?
Это навскидку.
> Жду пример перегрузки операторов(+ - * = == и т.п., а особенно
> new и delete) в паскале.
> А можно в паскале сделать operator int()? А шаблоны?
> Это навскидку.жду пример того же в си. это навскидку.
А зачем оно в Си? В посте, на который я ответил, проскользнул с++. К тому-же в том-же турбопаскале есть понятие объекта, что уже не делает его чисто структурным языком, в отличие от Си. Так что резонно сравнивать с плюсами нежели с С.Если же говорить о делфе, то и там вышеперечисленное появилось в кривейшем исполнении только с одотнетчиванием делфи.
> А зачем оно в Си?а вот зачем, цитирую: «а С ни чем не лучше паскаля». камент не читай @ наезжай, ага?
А кто-то еще жаловался, что MS душит опенсорс.
Перевожу из кулуаров: в Нокии обстановка накаляется, и патроны Qt видя это попросили обеспечить гарантию независимости, гарантию от ухода под крыло Майкрософт (что смерти подобно, ибо .NET только и ждет устранения конкурентов).
Изначально планировали дождаться 5-ки, т.к. в ней много кардинальных изменений и кодерам надо на них сконцентрироваться. А значит вмешательство со стороны при открытии доступа к репозиториям может усложнить и удлинить процесс ревизии кода, его гарантированной стабильности, координации и проч. Есть уже наглые американские компании, которые хотят своих фич в Qt и имеют свои виды на "светлое будущее" фреймворка (ну-ну) - схема понятна "лебедь, рак и щука" и в итоге пшик...
В результате, так как M$ прижимает, решили начать постепенный процесс перехода к коммунити разработке. Все кодеры Qt и Meego на нервах. Тем более упертые финны, у них опенсорс - это "святое". Никто не ожидал что M$ так быстро устранит Symbian. Думали она стабильно продержится еще года два, что будет запас на переход в Meego. Но M$ пошел напролом (см письмо о "горящей платформе"), и теперь вплотную занялся устранение Линукса (Meego) в Нокии (собственно, как я понимаю - главная цель). Инвесторы негодуют, хотя им не важны технические стороны в войне осей...
Менеджеры молчат в тряпку, ибо после показательных увольнений руководителей и скрам мастеров в Meego - особо ретивых - все поняли что к чему...
Короче как в России 90-х: приехали богатые американские капиталисты, сделали "an offer, he won't refuse", и слили конкурентов (или конечной целью все-таки был "социалистический" Линукс?). Никому такого не желаю!
> Никому такого не желаю!А я склонен считать что каждый сам пи...ц своего счастья. Если у компании в руководстве стадо кретинов - наверное логично что она потом тонет. Поздравляю гааряячиих фиинскиих паарнеей. Они отпустят тормоз только когда Элоп вообще утопит их контору.
Результатом "зарезания ягненка" акулами капитализма стало то, что европейцы (финны в данном случае, думающие по крайней мере) почувствовали на своей шкуре то, что почувствовали в России 90-х, когда "цивилизованные" Штаты скупали в России по дешевке усе через мутные схемы капиталистов, при этом мурлыкая что-то убаюкивающее про "демократический ценности".
А при относительно сытой и размеренной жизни в Европе, чувства европейцев будут особенно резкими... Учитывая открытое информационное давление США (которые тащат всех с собой в дефолтную могилу) на "кровоточащие" Греции, Испании, (PIGS), в старушке Европе идет явная переоценка капиталистических ценностей...
как бэ намекает : Nokia отдельно, qt отдельно. Хотя это даже к лучшему
В свете последних событий не могу без содроганий читать новости, содержащие в заголовке одновременно "Qt" и "Nokia". Слава богу, пока ничего плохого не случилось. Новость хорошая, давно всё к этому шло.
Отличный фреймфорк. Даже более чем. Кроме того видел компании, которые отлично продают программы сделанные и поддерживаемые еще на делфи 3 , а QT в текущей новой версии работает на ура и под винду и под линух и под другие програмные и аппаратные платформы.
(Шепотом) Как бывший дельфист - уверяю: именно третья версия делала самые быстрые и компактные программы, если понятие "компактный" и "быстрый" вообще применимо к дельфи. Дальше шли уже сплошь убогие сетевые и клиент-серверные недо-решения.
Странно, вполне себе юзал Дельфи с первой и по 2010 версию, да много можно было бы просто выкинуть без потерь, но не скажу что сильно мешает, а о компактности, ну DOS 6.22 занимал 3 дискеты, а Win95 уже 16, так что 5-7 мб на винте думаю не очень страшно для программы которая РАБОТАЕТ ТАК КАК ДОЛЖНА.
PS: Этим начинают грешить почти все без исключения браузеры, разве что кроме Links, превращаясь в монстров :)
> Отличный фреймфорк. Даже более чем. Кроме того видел компании, которые отлично продают
> программы сделанные и поддерживаемые еще на делфи 3 , а QT
> в текущей новой версии работает на ура и под винду и
> под линух и под другие програмные и аппаратные платформы.А тот кто помнит Kylix, помнит и то, что он использовал Qt вместо VCL
> А тот кто помнит Kylix, помнит и то, что он использовал Qt
> вместо VCLне «вместо», а «вместе». Qt использовали в основном как низкоуровневый апи, обёрнутый сверху vcl-ем.
И называлось все это CLX
в Qt огорчает лишь одно, что нет кроме Python и C++ другого языка, один медленный, второй устаревшийхотел бы видеть в Qt 5 такие вещи:
1) базовый язык - нечто вроде D или например Vala (с адаптацией на QObject а не GObject), вот один из этих двух языков очень подходит для такой роли - современного типа и при том нативные
2) конечно желательно как опцию процессоро-независимый и независимый от ОС байт код, например на базе LLVM, с соответствующими модульными и оффлайн-онлайн инсталляторами под разные ОС...вот тогда Qt выживет в будущем и будет конкурировать на равных
> 1) базовый язык - нечто вроде D или например Vala (с адаптацией
> на QObject а не GObject),JS видимо таковым станет, с C++ для heavy lifting.
> в Qt огорчает лишь одно, что нет кроме Python и C++ другого
> языка, один медленный, второй устаревшийНе пойму, что значит "в Qt"? Писать программы, использующие Qt, можно на куче языков: http://en.wikipedia.org/wiki/Qt_%28framework%29#Bi... . А на чём написан сам Qt, мало кого волнует, пока он хорошо работает. А Qt работает всё-таки хорошо.
> хотел бы видеть в Qt 5 такие вещи:
> 1) базовый язык - нечто вроде D или например Vala (с адаптацией
> на QObject а не GObject), вот один из этих двух языков
> очень подходит для такой роли - современного типа и при том
> нативныеЧто значит "базовый"? Что значит "устаревший"? Без встроенного сборщика мусора, что ли? Дык пользуйтесь биндингом для того языка, в котором есть вам нужные фичи. И это будет наверняка работать быстрее, чем если бы Qt был изначально написан на том же Python или D.
> 2) конечно желательно как опцию процессоро-независимый и независимый от ОС байт код,
> например на базе LLVM, с соответствующими модульными и оффлайн-онлайн инсталляторами под
> разные ОС...А ещё было бы здорово, чтобы мой холодильник квартиру пылесосил. Вы вообще понимаете, о чём говорите?
> вот тогда Qt выживет в будущем и будет конкурировать на равных
Угу. Потому что сейчас ему альтернатив (по связке "портируемость + удобство + скорость") практически нет, но если следовать вашим советам, наверняка конкуренты догонят и обгонят.
> И это будет наверняка работать быстрее, чем если бы Qt был изначально написан на том же Python или D.Python — допустим. Но почему Вы решили, что Qt будет медленнее, будучи написан на D? Даже наоборот, кое-что точно ускорится — процесс компиляции, из которого полностью устранён препроцессор.
>> И это будет наверняка работать быстрее, чем если бы Qt был изначально написан на том же Python или D.
> Python — допустим. Но почему Вы решили, что Qt будет медленнее, будучи
> написан на D?Просто потому, что C++ - это мейнстрим, который оптимизируют в хвост и в гриву. При этом язык даёт полное управление над программой, что позволяет выжимать каждую каплю производительности. В D же имеются неподконтрольные или слабо контролируемые сущности (вроде того же сборщика мусора, или ), которые иногда добавляют удобства и скорости разработки, но не бесплатно. :)
Я вовсе не говорю, что D - это плохо. Но для Qt, ИМХО, C++ - самый оптимальный вариант. Это как раз тот случай, когда C++ наиболее уместен. По соображениям портабельности (как в плане компиляции собственно Qt, таки в плане доступа из других сред), производительности, а также контролируемости и гибкости исходного кода.
> Даже наоборот, кое-что точно ускорится — процесс компиляции,
> из которого полностью устранён препроцессор.Заменили #include на import, и ждём ускорения процесса сборки. Ну-ну. Покажите цифры, которые бы подтверждали реальное ускорение, а там уже можно будет говорить не впустую.
> В D же имеются неподконтрольные или слабо контролируемые сущности (вроде того же сборщика мусора, или ), которые иногда добавляют удобства и скорости разработки, но не бесплатно. :)Как раз подконтрольные. В D есть возможность ручного выделения памяти, а также сборщик можно отключить при желании.
>> В D же имеются неподконтрольные или слабо контролируемые сущности (вроде того же сборщика мусора, или ), которые иногда добавляют удобства и скорости разработки, но не бесплатно. :)
> Как раз подконтрольные. В D есть возможность ручного выделения памяти, а также
> сборщик можно отключить при желании.Если его отключить (кстати, о том, что это возможно, я почему-то не знал, прошу прощения), то о преимуществе в виде его использования говорить будет странно. :) А ручное выделение памяти по сути предназначено только для взаимодействия с другими платформами, пользоваться им не очень удобно... во всяком случае, было. Как сейчас - не знаю, может, что-то и изменилось (хотя на digital mars сейчас зашёл, и на скорую руку нового в этой сфере не увидел).
Иными словами: из D можно сделать C++. Но зачем, если C++ уже есть? :)
Из D нельзя сделать С++, пока в плюсах есть препроцессор, а в D — грамотная поддержка модулей. Конечно, добавить в D препроцессор и убрать модульность можно. Но зачем? Ведь препроцессор — это плохо, а модульность — это хорошо.
> Из D нельзя сделать С++, пока в плюсах есть препроцессор, а в
> D — грамотная поддержка модулей.Ну, положим, никто не мешает использовать препроцессор для D-исходников. ;) Он ведь не вникает в код...
> Конечно, добавить в D препроцессор и убрать модульность можно.
В D добавлять ничего не нужно, это вопросы чисто к процессу компиляции. :)
> Но зачем?
Именно. Незачем. D - это одно, C++ - другое. И для Qt C++ подходит, ИХМО, больше. Не говоря о том, что Qt появился, насколько помню, раньше D. ;)
> Ведь препроцессор — это плохо, а модульность — это хорошо.
Грузовик - это плохо, а теплоход - это хорошо, да?
> Заменили #include на import, и ждём ускорения процесса сборки.Сравнили тёплое с мягким. #include указывает на текстовый файл, который следует включить в данный файл (обычно включается заголовочный файл). При включении одного и того же заголовочного файла его приходится окружать #ifdef-ами, дабы не множить сущности без необходимости. import необходимость использования этого костыля устраняет — модуль в процессе сборки подключается ровно один раз. При этом import-у не приходится работать с большими блоками текста, при которых неизбежно многократное копирование одного и того же всякий раз, когда из текста удаляется одна строчка или наоборот, добавляется.
>> Заменили #include на import, и ждём ускорения процесса сборки.
> Сравнили тёплое с мягким. #include указывает на текстовый файл, который следует включить
> в данный файл (обычно включается заголовочный файл). При включении одного и
> того же заголовочного файла его приходится окружать #ifdef-ами, дабы не множить
> сущности без необходимости. import необходимость использования этого костыля устраняет
> — модуль в процессе сборки подключается ровно один раз.Что это костыль - согласен (правда, почти современные компиляторы знают про "#pragma once", но это всё же не так портабельно). Но речь была о производительности.
> При этом
> import-у не приходится работать с большими блоками текста, при которых неизбежно
> многократное копирование одного и того же всякий раз, когда из текста
> удаляется одна строчка или наоборот, добавляется.Не понял насчёт удаления-добавления строчек. Если имеется в виду многократное включение заголовочного файла, то таки это фича, которой в D нет. :) Если же имеется в виду, что import не пересчитывает заново все исходники, так и ccache никто не отменял... Да, это отдельная от языка сущность, но по факту результат сравнимый. :)
Повторюсь, я не против этих возможностей. Всего лишь говорю, что на производительность реального продукта, который делается реальными инструментами, они не особо влияют.
> Что это костыль - согласен (правда, почти современные компиляторы знают про "#pragma
> once", но это всё же не так портабельно). Но речь была
> о производительности.Нет, речь была о скорости. Причем о скорости компиляции, а не только скорости исполнения. Она тоже важна.
> Не понял насчёт удаления-добавления строчек. Если имеется в виду многократное включение
> заголовочного файла, то таки это фича, которой в D нет. :)
> Если же имеется в виду, что import не пересчитывает заново все
> исходники, так и ccache никто не отменял... Да, это отдельная от
> языка сущность, но по факту результат сравнимый. :)Имеется в виду следущее: #include в файле подобен %s в строке для форматирования. Когда в строке встречается что-то вроде "текст %s еще текст %s снова текст", магического раздвигания строки не будет. Вместо этого будет создана новая строка, в которую кропотливо будет вставляться искомая строчка по кускам. Это не быстро. И тут хоть ccache, хоть не ccache — работа со строками при использовании препроцессора неизбежна.
> Повторюсь, я не против этих возможностей. Всего лишь говорю, что на производительность
> реального продукта, который делается реальными инструментами, они не особо влияют.А при чем тут производительность реального (то бишь уже готового) продукта? Она-то как раз отличаться не будет, ибо, собственно, все оптимизации и в плюсах, и в Ди одинаковые, нового никто ничего не придумал (а если кто придумал, это сразу же повторили остальные). Речь ведь шла о скорости компиляции, а на неё как раз наличие/отсутствие препроцессора влияет.
>> Что это костыль - согласен (правда, почти современные компиляторы знают про "#pragma
>> once", но это всё же не так портабельно). Но речь была
>> о производительности.
> Нет, речь была о скорости. Причем о скорости компиляции, а не только
> скорости исполнения. Она тоже важна.Гм. ИМХО, термин "прозводительность" чуть точнее, чем "скорость", ну да не суть. Речь об одном и том же. И таки да, я тоже говорил о скорости компиляции.
>[оверквотинг удален]
>> заголовочного файла, то таки это фича, которой в D нет. :)
>> Если же имеется в виду, что import не пересчитывает заново все
>> исходники, так и ccache никто не отменял... Да, это отдельная от
>> языка сущность, но по факту результат сравнимый. :)
> Имеется в виду следущее: #include в файле подобен %s в строке для
> форматирования. Когда в строке встречается что-то вроде "текст %s еще текст
> %s снова текст", магического раздвигания строки не будет. Вместо этого будет
> создана новая строка, в которую кропотливо будет вставляться искомая строчка по
> кускам. Это не быстро. И тут хоть ccache, хоть не ccache
> — работа со строками при использовании препроцессора неизбежна.Это достаточно быстро, с учётом: а) дискового кеша; б) потерь времени на оптимизацию и связывание кода (которые примерно одинаковы будут для C++ и D при условии сравнимой по сложности и качеству реализации). Повторюсь, приведите цифры (вы, видимо, с D работаете? Компилятор и какой-нибудь проект на десяток-другой тыщ строк хотя бы под руками?), а там уже можно будет о чём-то говорить. Я могу ошибаться. Вы можете ошибаться. Пока что вся дискуссия состоит из умозаключений.
>> Повторюсь, я не против этих возможностей. Всего лишь говорю, что на производительность
>> реального продукта, который делается реальными инструментами, они не особо влияют.
> А при чем тут производительность реального (то бишь уже готового) продукта?А вот тут я некорректно выразился, прошу прощения. Имелась в виду, разумеется, конечная скорость (здесь именно "скорость") сборки.
> Она-то как раз отличаться не будет, ибо, собственно, все оптимизации и в
> плюсах, и в Ди одинаковые, нового никто ничего не придумал (а
> если кто придумал, это сразу же повторили остальные). Речь ведь шла
> о скорости компиляции, а на неё как раз наличие/отсутствие препроцессора влияет.Скажем так: можно подготовить тесты, которые покажут убедительное преимущество как варианта с препроцессором, так и (сюрприз!) наоборот. :)
А оптимизации местами отличаются, хотя чтобы заметить разницу в реальном приложении, надо очень постараться. :)
>2) конечно желательно как опцию процессоро-независимый и независимый от ОС байт код, например на базе LLVM, с соответствующими модульными и оффлайн-онлайн инсталляторами под разные ОС...Да не нужны эти фреймворк-виртуальные машины с их байткодами в опенсорсе. Это же мир открытых исходников - берёте исходники и компилируете в нативный машинный код, интересующих вас процессора и ОС.
> Ларс Нол (Lars Knoll), создатель KHTML и директор по развитию фреймворка Qt в NokiaВот откуда в Qt пошла вся вебизация. Записал в тетрадку.
Теперь открыта даже коробка!