нет N900 будет продвигать Maemo 5 (c 3д ускорением ) и Maemo6 (Qt-based вместо GTK+ Hildon), таким образом они позволят писать портируемый софт на две платформы с пол щелчка: Symbian и Maemo.
Вайн очень давно уже работает на не x86, как минимум на SPARC и PPC. Под Армом тоже работает и проблемм я с этим не вижу. Он не работает на уровне виртуализации — он просто перекрывает системные вызовы, которые от архитектуры напрямую не зависят, например проект Ubuntu Mid работает на АРМе и в нем есть вайн.
но это вроде не дает запускать приложения Windows Mobile под Wine. Там всетаки API немного отличается и GUI тоже.
Да и думаю ни к чему это. Если можно будет без труда портировать Qt-based приложения и будет стоять kdelibs — то гарантирую — недостатка в софте не будет и тем более бесплатного.
Поддержки виндовз там не будет. Все что они планируют сделать в ближайшее время на платформе Maemo (а это устройсво является его продолжением, до него были N770, N810, N800 — всее без GSM, только таблетки) — это перевести интерфейс Hildon (который сейчас построен на GTK+) на Qt (точнее специально заточеный KDE). И дописать порт Qt для Maemo и допилить SDK (сейчас он только под линукс а эмулятор работает только под QUEMU).
Виндовз там и не ждите, Не будет. Хотя технически возможно так как устройство построено на базе SOC Texas Instruments OMAP3, правда уже сейчас TI продает Devboard'ы под OMAP4 — там помощнее 3д ускоритель и 2 ядра!!! по гигагерцу на ядро, поддержка фотоматриц до 50 мегапикс, и поддержка FullHD — 1920x1080 но правда с битрейтом в 20 Mb (для блюрея не хватит :-) )(это все АРМ архитектура, точнее ARM8 Cortex).
Под OMAP3 линейко построен Palm Pre, Nokia N97, Nokia N900, вроде IPhone (не уверен) HTC HD2, еще какие-то девайсы HTC, телефон от Гугла. Вобщем все новинки.
И кстати замечу, что все они не дешевые. Так чт в принципе падение цен будет, но не сильно. Ну максимум до 20-22 упадет.
никто не говорит что reinterpret_cast так страшен, просто нада внятно думать прежде чем им пользоватся. Вот вроде у Страуструпа читал что такое длинное название вместо сишых простых скобок именно для того чтобы человек четко понимал что он делает. Если бы reinterpret_cast был явным злом его бы и небыло бы :-)
боюсь нет :-) компания маленькая, задачи емкие и у нас набирают только ведущих разработчиков. Простых даже не берут а про джуниоров я даже спрашивать боюсь :-)
Я работаю в ОС. В процессе работы я пользую 45 приложений (например) и вот мне потребовалась одна единственная и не заменимая, которой нет в моем любимом линуксе и маке. И она мне нужна в контексе, не постоянно а так: включил — выключил. Вы предлагаете каждый раз заводить ось? пусть в виде перезагрузки или запуска виртуалки. Извольте — она очень даже ничего себе работает под вайном — почему бы не пользовать. Но если есть аналоги даже немного хуже — то естественно предпочитаю аналоги.
Я опять повторяю — во всем нада знать меру, крайности — удел подросткового или шизофренического сознания (иногда это синонимы :-) ).
this не обязательно идет первым — не забывайте что есть little endian и big endian архитектуры. Но это так к слову. Теперь по сути.
ABI не только calling conversion. Естественно, если интерфейс менятся не будет, а будет менятся только код в cpp файле — то все будет очень хорошо. Имейте ввиду что это не относится к коду, который находится в заголовочном файле. Кстати одна из причин почему не нужно писать его в заголовочном файле, даже если он пустой, потому как надумаете наконец его реализовать, то потеряете эту злощастную бинарную совместимость.
Если вы допустим добавите виртуальный метод в класс и поставите его на первом месте — то виртуальные адреса всех других методов сдвинутся и ваш код, который был слинкован попадет уже в другое место. Если же вы добавите виртуальный метод после всех остальный, то все будет хорошо.
Pimpl — это не панацея и не единственный вариант сохранить бинарную совместимость, я уже приводил ссылку на KDE TechBase где рассказывается что можно делать и останется бинарная совместимость и в каких случаях она поломается. Вот эта статья: techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts
Я планируя посвятить этому тему. Так как это необходимо знать каждому, кто разрабатывает библиотеки для «общего пользования». И расскажу подробней обо всех ньюансах.
Часто встречаются проблеммы с бинарной совместимостью. Как пример — Qt на линукс в бинарниках идет без поддержки Phonon, потому что ни GStreamer ни Xine (которые сейчас поддерживаются как бэкэнды) не заботятся о бинарной совместимости. Поэтому необходимо кути собирать непосредственно с теми библиотеками, которые стоят именно на вашем компьютере. А самое интересно начинается когда вы собираетесь поставлять свою программу со своими кастомными библиотеками Qt на Linux — тут уже наступает «ахтунг», либо тянуть GStreamer с собой или Xine. Либо в качестве зависимостей тянуть девелоперские пакеты для одной из этих библиотек и собирать фонон уже в скрипте при установке либо требовать чтобы пользователь об этом позаботился сам ну или использовать системный фонон и прописать его в зависимости. Все варианты не очень. И все из-за того что кто-то не позаботился о бинарной совместимости. Хотя я слышал что и Xine и GStreaner пообещали впредь относится серьезней и далее ситуация должна изменится.
Проблемма бинарной совместимости есть и ее просто необходимо знать, но увы очень мало документации по этой теме. Так что я собираюсь пятую статью посвятить именно этому вопросу.
достаточно неприметная небольшая компания SmartLabs (http://smartlabs.tv). Кстати есть один продукт популярный, который мой коллега написал — TsMuxeR называется. Служит для пересборки контейнеров для видео. Тоесть по факту можно из ts файла получить mpeg4 обычный без длительного перекодирования, либо собрать BlueRay диск. Ну вобщем вроде популярная утилитка.
Вообще мы занимаемся IpTv. Сейчас одну из наших поделок можно увидеть на приставках у StreamTv. Вот если у кого есть — это все сделано как раз на Qt. Причем Амина 110 достаточно старая и там стоит PowerPC 405 процессор с 16 Mb постоянной памяти (NORFLASH) и 32 оперативной. Туда мы вместили наше приложение операционку драйверы и кути и еще кучу поделок. Не могу выдавать тайны а на каком этапе у нас внедрение я не знаю.
да и кстати мой блог постиг хабраэффект :-) так как большинство посещений из России, Украины и Белорусии. Рейтинг идет в этом порядке, только между Россией и Украиной стоит США (сначала написал а потом понял двойственный смысл :-))
Так что ребята спасибо за хабраэффект :-) Никогда не верил в разный там интернет пиар а тут увидел его в действии.
Спасибо. Честно говоря я собирался писать только на английском. Но потом захотелось стать частью хабра и решил написать статью в двух вариантах. По английски я пишу чтобы подтянуть свой английский, так как собираюсь сдавать IELTS экзамены. Одно из модулей сдачи — написание сочинения. Вот и тренируюсь. Плюс действительно действенно так как приходится вспоминать времена и некоторые слова (точнее часть слов из пассивного словаря переношу в активный).
Но после того как я увидел резонанс (посещаемость моего блога сейчас 400 в день !!!) меня подбило занятся этим на «постоянной основе». Тем более, что рассказать мне еще много чего есть и я лично очень болею за будущее Qt и в моих же интересах вложить свои 5 копеек в популяризацию этого фреймворка. В этом случае востребованость Qt специалистов выростет, чему буду я очень рад :-)
Да кстати кому интересно. Я сейчас тут переписываюсь с Андре Поэтисом, который занимается разработкой Qt-creator по поводу gdbmacroshelper. Он поддерживает меня что он реализован не очень. Поэтому они ведут разработку по его улучшению и уже есть девелоперский вариант, который он выложил в репозиторий по моей просьбе. Суть в том, что теперь испльзуется не call команда gdb, а биндинг питоновго скриптинга в gdb.
Моя основная идея состоит в том, чтобы расширить этот механизм для того чтобы можно было создавать дамперы своих кастомных классов. При существующей схеме единственный вариант — это линговать этот макрос с той библиотекой из которой вы хотите дампить класса. Так вот идея состоит в том чтоб придумать как это сделать так, чтобы можно было не прибегая к добавлению лишнего кода в исходники и не делая зависимым gdbmacroshelper от левого кода дать возможность людям писать собственные дамперы как можно проще.
Вот напишу что и как я нарыл чуть позже, может кто посоветует чего-нибудь.
Можно кстати будет потом вывернуть на изнанку moc предкомпилер и добавить возможность обработки собственного препроцессинга через плагины. Вот такая у меня идея вчера перед сном пришла. Правда прийдется систему плагинов делать чисто C++ ибо на момент сборки moc предполагается что qt еще не собран :-) Но это не остановит настоящего индейца.
в бусте есть точно такое же «ключевое слово» (из-за этого при миксе буста и кутишного кода лучше пользоватся Q_SLOTS вместо slots). Кстати про сигналы и слоты тут перевод есть официальной доки в хабре habrahabr.ru/blogs/qt_software/50812/.
Очень полезный механизм, четко спионереный у NextStep'а, GTK+ и boost тоже повзаимствовали его :-)
Ну вообще то Qt не был портирован ни на один из языков. Он существует, существовал и будет существовать только на C++. Что касается QtJambi, PyQt, QT-D, Qt# и им подобных — это биндинг — тоесть привязка. Само же Qt на С++. В большей степени эти биндинги используются как инструменты для этих хост-языков для реализации GUI (отсюда и миф, что Qt — это GUI Framework).
Но для ясности допишу в начале.
но это вроде не дает запускать приложения Windows Mobile под Wine. Там всетаки API немного отличается и GUI тоже.
Вот VirtualBox\WMVare под арм не портируют. Самый реальный эмулятор — это qemu.
Судя по вот этой ссылке en.wikipedia.org/wiki/Comparison_of_platform_virtual_machines — это единственный эмулятор, позволяющий эмулировать x86 на ARM.
Да и думаю ни к чему это. Если можно будет без труда портировать Qt-based приложения и будет стоять kdelibs — то гарантирую — недостатка в софте не будет и тем более бесплатного.
Виндовз там и не ждите, Не будет. Хотя технически возможно так как устройство построено на базе SOC Texas Instruments OMAP3, правда уже сейчас TI продает Devboard'ы под OMAP4 — там помощнее 3д ускоритель и 2 ядра!!! по гигагерцу на ядро, поддержка фотоматриц до 50 мегапикс, и поддержка FullHD — 1920x1080 но правда с битрейтом в 20 Mb (для блюрея не хватит :-) )(это все АРМ архитектура, точнее ARM8 Cortex).
Под OMAP3 линейко построен Palm Pre, Nokia N97, Nokia N900, вроде IPhone (не уверен) HTC HD2, еще какие-то девайсы HTC, телефон от Гугла. Вобщем все новинки.
И кстати замечу, что все они не дешевые. Так чт в принципе падение цен будет, но не сильно. Ну максимум до 20-22 упадет.
Я опять повторяю — во всем нада знать меру, крайности — удел подросткового или шизофренического сознания (иногда это синонимы :-) ).
ABI не только calling conversion. Естественно, если интерфейс менятся не будет, а будет менятся только код в cpp файле — то все будет очень хорошо. Имейте ввиду что это не относится к коду, который находится в заголовочном файле. Кстати одна из причин почему не нужно писать его в заголовочном файле, даже если он пустой, потому как надумаете наконец его реализовать, то потеряете эту злощастную бинарную совместимость.
Если вы допустим добавите виртуальный метод в класс и поставите его на первом месте — то виртуальные адреса всех других методов сдвинутся и ваш код, который был слинкован попадет уже в другое место. Если же вы добавите виртуальный метод после всех остальный, то все будет хорошо.
Pimpl — это не панацея и не единственный вариант сохранить бинарную совместимость, я уже приводил ссылку на KDE TechBase где рассказывается что можно делать и останется бинарная совместимость и в каких случаях она поломается. Вот эта статья: techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts
Я планируя посвятить этому тему. Так как это необходимо знать каждому, кто разрабатывает библиотеки для «общего пользования». И расскажу подробней обо всех ньюансах.
Часто встречаются проблеммы с бинарной совместимостью. Как пример — Qt на линукс в бинарниках идет без поддержки Phonon, потому что ни GStreamer ни Xine (которые сейчас поддерживаются как бэкэнды) не заботятся о бинарной совместимости. Поэтому необходимо кути собирать непосредственно с теми библиотеками, которые стоят именно на вашем компьютере. А самое интересно начинается когда вы собираетесь поставлять свою программу со своими кастомными библиотеками Qt на Linux — тут уже наступает «ахтунг», либо тянуть GStreamer с собой или Xine. Либо в качестве зависимостей тянуть девелоперские пакеты для одной из этих библиотек и собирать фонон уже в скрипте при установке либо требовать чтобы пользователь об этом позаботился сам ну или использовать системный фонон и прописать его в зависимости. Все варианты не очень. И все из-за того что кто-то не позаботился о бинарной совместимости. Хотя я слышал что и Xine и GStreaner пообещали впредь относится серьезней и далее ситуация должна изменится.
Проблемма бинарной совместимости есть и ее просто необходимо знать, но увы очень мало документации по этой теме. Так что я собираюсь пятую статью посвятить именно этому вопросу.
Вообще мы занимаемся IpTv. Сейчас одну из наших поделок можно увидеть на приставках у StreamTv. Вот если у кого есть — это все сделано как раз на Qt. Причем Амина 110 достаточно старая и там стоит PowerPC 405 процессор с 16 Mb постоянной памяти (NORFLASH) и 32 оперативной. Туда мы вместили наше приложение операционку драйверы и кути и еще кучу поделок. Не могу выдавать тайны а на каком этапе у нас внедрение я не знаю.
Так что ребята спасибо за хабраэффект :-) Никогда не верил в разный там интернет пиар а тут увидел его в действии.
Но после того как я увидел резонанс (посещаемость моего блога сейчас 400 в день !!!) меня подбило занятся этим на «постоянной основе». Тем более, что рассказать мне еще много чего есть и я лично очень болею за будущее Qt и в моих же интересах вложить свои 5 копеек в популяризацию этого фреймворка. В этом случае востребованость Qt специалистов выростет, чему буду я очень рад :-)
Моя основная идея состоит в том, чтобы расширить этот механизм для того чтобы можно было создавать дамперы своих кастомных классов. При существующей схеме единственный вариант — это линговать этот макрос с той библиотекой из которой вы хотите дампить класса. Так вот идея состоит в том чтоб придумать как это сделать так, чтобы можно было не прибегая к добавлению лишнего кода в исходники и не делая зависимым gdbmacroshelper от левого кода дать возможность людям писать собственные дамперы как можно проще.
Вот напишу что и как я нарыл чуть позже, может кто посоветует чего-нибудь.
А во вторых так проще парсить в moc.
Очень полезный механизм, четко спионереный у NextStep'а, GTK+ и boost тоже повзаимствовали его :-)
lists.trolltech.com/qt-interest/2007-09/thread00325-0.html
за поправку спасибо.
Но для ясности допишу в начале.