Russian Qt Forum

Раньше я программировал на С++ и Qt все устраивало, да захотелось новых ощущений - решил попробовать D - понравилось настолько что теперь возвращаться на плюсы абсолютно не хочется. Это тема отдельного разговора.
С D я использовал долгое время gtk - все устраивало вроде, по возможностям это очень близкие тулкиты, но если начинать копать в глубь - то гтк намного отстает от Qt. Родилась идея сделать биндинг. Последнюю неделю занимаюсь этим вплотную и столкнулся с большой проблемой - виртуальные функции. С обычными методами Qt классов все в порядке - создаем extern C прослойку для каждого метода:
А далее цепляем этот набор Си функций в коде D и воссоздаем новый объект обертку с реализующий такой же набор методов.
С виртуальными функциями сложнее:
Dispatch_QWidget_MousePressEvent - это extern C функция объявленная в Ди которая вызывает по умолчанию ancestor_mousePressEvent - то есть реализацию по умолчанию для виджета. Если мы унаследуемся в Ди коде - то все будет в порядке - будет вызвана новая реализация.
Проблема начинается тогда когда мы таким же методом создадим к примеру QPushButton_Proxy - он будет наследоваться от QPushButton, а этот в свою очередь от QWidget. Но реализацию виртуальных методов мы же сделали для QWidget_proxy - то есть для унаследованных классов схема с proxy - не  будет работать. Где-то слышал, что в биндингах перехватывают виртуальные функции - но это ведь связано с модификацией vtable[] - что большое зло. У кого-нибудь есть какие-нибудь соображения на этот счет?

Может не страдать а писать просто на C++?
Мне вот тоже хочется писать под Qt на C# вместо C++, но ничего, терплю :)

Создали бы топик - зто за язык D.

PS: А лучше начать с языка A. Что за мода называть язык 1 буквой - я раньше еле находил статьи по C. Сорри, отвлекся.

http://www.digitalmars.com/d/index.html
Вам не кажется что писать биндинги к такой библиотеке как Qt непосильная задача для одного человека? Не вдаваясь в детали в Qt очень много специфичных решений (но если так хочется думаю вам можно посмотреть на Qt Jambi, PyQt(+SIP) и т.д.)

[offtop]
"я написала этот вирус на связке паскаля, объектного си, жавы, ассемблера и некоторых малоизвестных языков..." ©какой-то_старый_тупой_фильм

надо это xintreya показать :)
[/offtop]

я не понял почему схема с прокси не будет работать (точнее, в чём сама суть проблемы).
и хотелось бы услышать чем д превосходит с/с++, что плюсы уже обзывают "устаревшим" языком?

Вроде как D - сверхвысокий язык программирования. :)

Что мешает? По крайней мере под Linux: http://qyoto.org/

У D, насколько я понял, есть в C компиль. Хотя утверждать не буду. Легче в вики посмотреть.

Линукс мешает :)

Что такое D, и с чем его едят ??? Может кто кинет ссылочку на обзорную статью.

НАшел немного инфы на википедии: D (язык программирования) (http://ru.wikipedia.org/wiki/D_(язык_программирования))

Предлагаю перенести обсуждение языка D и С++ в другую тему: http://www.prog.org.ru/topic_7933_0.html

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

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

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

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=13832
мне сложно представить как можно писать на Д и получать удовольствие, если между обновлениями _столько_ изменений (в т.ч. и в сторону синтаксиса/логики)!
и ещё мне интересно: Д стандартизован? где-нибудь можно почитать стандарты языка Д?

Я также заинтересовался этим вопросом. Искал - не нашел.

По поводу прокси - я уже получил ответ на свой вопрос у разработчиков Smoke либы, на которой основаны qyoto, perlqt и qtruby. В данной схеме не работает то, что виртуальный функции обработанные для QWidget_proxy не будут работать для QButton_proxy так как он наследуется от QButton, а QButton в свою очередь от QWidget, но не от QWidget_proxy.
По поводу С++ - я прекрасно понимаю что поскольку вы используете С++ - трудно понимать очевидные вещи - то что язык устарел к примеру. Могу подробнее написать - более менее окончательно язык стабилизировался к 1991 году - 17 лет. Немало. Далее, если смотреть когда язык появился - в 1983 году - уже 25 лет. Но что наиболее важно - большая часть концепций С++ перекочевала из Си, которому уже почти 40 лет - то мне абсолютно непонятно почему вы так удивляетесь что я называю С++ устаревшим.
Насчет преимуществ D подробнее напишу во вновь созданном топике.

>>и ещё мне интересно: Д стандартизован? где-нибудь можно почитать стандарты языка Д?
Cтандарт - это далеко не показатель качества. Python имеет стандарт? Руби? язык D определяется спецификациями, и референсной реализацией - dmd.


>>мне сложно представить как можно писать на Д и получать удовольствие, если между обновлениями _столько_ изменений (в т.ч. и в сторону синтаксиса/логики)!
Стоит вначале разобраться в предмете разговора а потом уже писать... Есть 2 ветки языка - D1 И D2. D1 - стабильный, который используется в реальных проектах со стабильной спецификацией. D2 - это бета-версия второй версии языка с множеством нововведений, пока еще носит экспериментальный характер и мало используется.

могу навскидку привести десятки примеров, доказывающих, что новое далеко не всегда лучше старого :)
но мне лениво...

ограничусь таким фактом: gcc развивается уже не первый десяток лет группой профессиональных разработчиков и, тем не менее, каждая новая мажорная версия лучше предыдущей и поддерживает всё больше технических наворотов, методов оптимизации и т.п.; дмд развивается всего несколько лет небольшой группой энтузиастов...

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

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

Хотел бы заметить что gcc отнюдь не показатель. Это ужасн для разработчиков. Есть такой проект - llvm.org - он активно развивается при поддержке apple - можете подробнее посмотреть - но он намного прогрессивнее gcc.
Новое всегда лучше старого. Потому что
1)нет ничего идеального в этом мире, и новое исправляет ошибки
2) то что было актуально 10 лет назад может быть бессмысленным сегодня
Конечно этот принцип не применим к сравнению Led Zeppelin и King Crimson c Бритни Спирс и 50 цент, но в данном случае это так.

Насчет убогости дельфи - я бы попросил не делать скоропалительных суждений..
Плюсы в фаворе лишь в связи со сложившейся обстановки, существующей инфраструктуры, но никак не объективных преимуществ языка. Представьте на секунду - нет ни одной библиотеки и программисты не знают ни одного языка программирования - и выбрать между С++ и D.
Далее насчет компиляторов - автор языка Уолтер Брайт - автор первого компилятора С++ - который появился 20 лет назад. Вам не кажется что он понимает в С++ несколько больше вас с нами. У него есть уже отлаженный годами бэк-енд, компиляторы С++ и D различаются фронтендами. Но даже не за этим компилятором будещее.
Есть компилятор D для gcc - но он плохо развивается и заниматься им никто не хочет. Почему - разработчики это объясняют сложностью и непомерной запутанностью gcc. Вместо этого основная ставка сейчас делается на фронтенд для llvm. За этим будущее. Здесь вам и оптимизации о которых вы говорите, и технические навороты и прочее. И поддерживается крупным вендором.
Вы можете и через 100 лет продолжать писать на с++ - но времена меняются. Я начинал свой проект на С++ и Qt, но после знакомства с D принял решение переписать то что сделано на нем - и скажу что писать на D - это огромное удовольствие, несмотря на некоторые проблемы с инфраструктурой.

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

это не "скоропостижное" суждение - я говорил о непотребности делфи, когда оно ещё было популярно...

пару примеров, пожалуйста.

Может быть вы говорить верно, но я невижу столь существенного преимещуства D перед С++, чтобы кидаться на него. С\С++ не устарел, он находиться в зрелом возрасте :). Милионны программистов выбрали его, милиарды строк кода написано на С\С++, существует миллионы библиотек и приложений. Несмотрю на солидный возрас - он востребован. Те вещи которые невостребованы - они умирают, взять тотже Делфи (что язык ни к четру, что среда убогая, для домохозяек). D очень молодой и сырой язык, инструместальные средства сырые. Дай Бог конечно ему прожить хоть четверть от возраста С\С++ )))

>>пару примеров, пожалуйста.
сигналы-слоты? QString? QVector? QStl? foreach?
Преимущества С++ на сегодня сводятся только к миллиардам строк написанных на нем. А язык устарел, и не заметить это невозможно.

А у Дельфи есть вполне очевидные преимущества перед С++(как и у С++ перед дельфи), и это никак не связано с тем что Дельфи удобен для домохозяек.

searching...

Result: Not found

> сигналы-слоты? QString? QVector? QStl? foreach?
это уже фанатизмом отдаёт...зачем же смешивать в кучу различные технологи, по разным причинам не попавшие в "ядро" языка?
Си - сравнительно низкоуровневый язык. упрекать его за отсутствие встроенной поддержки кодировок строк и т.п. - это несерьёзно - с/с++ не для того писались!
если такими темпами будем двигаться, скоро кто-нибудь упрекнёт плюсы за невозможность использования JS/VBS-вставок и т.п. :)

Ди тоже системный язык. Но это не мешает ему иметь вменяемые строки. Так же как и все остальное.
А сигналы/слоты это тоже фанатизм? По разным причинам не попавшее в ядро языка. Здесь уже попахивает фанатизмом с вашей стороны и нежелание видеть очевидного. Повторюсь, я разубеждать не буду никого здесь и повторять уже сказанное.

> Повторюсь, я <...> не буду <...> повторять уже сказанное
:)

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

мне надоела эта ветка. кроме убеждений в том, что С устарел, а Д - это круто, я больше ничего здесь не вижу.
проблема с биндами разрешилась без нашего участия - вот и прекрасно.

ветку сносить не буду, но просьба впредь писать здесь исключительно по теме биндов Д и Кутэ!

Ну надо сказать, я ОЧЕНЬ боюсь того что Вы снесете ветку...  ;D  Я считаю, что следует отсылать патчи в подлинно свободный тулкит -  GTK+ и совершенствовать его. Что касается D, очень сложно разубеждать людей, которые уже натерли мазоли на преодолении недостатков С++. Мир движется дальше. Если кому-то хочется геморроя с С++ - добро пожаловать. Я - ни-ни. И лично для меня намного интереснее написать биндинг чем писать на этом языке.

/* я почти и не сомневался, что последует коммент примерно такого содержания */

> Повторюсь, я разубеждать не буду никого здесь <...>
>> Что касается D, очень сложно разубеждать людей, которые <...>
не могу понять в чём подвох...

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

приглашаю пообщаться на этом же форуме лет через десять, когда Д покорит мир...а может быть это будет Е или Ф?..

"Ребята, давайте жить дружно" (Кот Леопольд)
Зачем переходить на личности и оскорблять другого? Пусть человек даказывает, что Ди лучше, от этих слов С++ хуже не станет. Если ему так хочется, пусть переубеждает.
С++ будет жить еще очень много лет, не одна программа или операционка будет на нем написана. Но это не значит, что не может быть других языков, может даже и лучше его. Почему автор "наезжает" на С++? Просто в сравнении легче объяснять.
Я заинтересовался Ди, и, возможно, в ближайшее время поизучаю его. Хотя бы для себя.
Константин, может покоцаешь посты с руганью? Они ни к чему и топик засоряют. А вот сам топик лучше оставить, все таки альтернативы всегда нужны.

panter_dsd
Спасибо за адекватный пост. Я не собирался доказывать ничего и никому, просто мне не понравилась волна скепсиса и непонимание очевидных недостатков С++. Я сам не программист, и мне не по душе изучать перипетии С++ и отлов багов с указателями. Мне приятнее кодить свои мысли - и Ди в этом отношении превосходен.

Появился вопрос по поводу биндинга. В Qt есть свое управление памятью? Как я понимаю, если объект имеет родителя, то родитель прибивает его когда надо?
Кстати говоря в случае с D, по сравнению с биндами к скриптовым языкам достаточно небольшое пенальти по производительности. Многие вещи делаются напрямую. в qtruby и qyoto каждый вызов связан с поиском в большом хэше и прочими процедурами, здесь же цена - пара лишних вызовов, что не может не радовать.

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

Ну так вы ведь неназвали недостатки С++. В этой теме, в другой теме вы кричите "недостатки С++, недостатки С++". А в чем недостатки-то? Я попросил вас назвать недостатки - ответа нет! Так что это только голые слова.... Ничего личного

По аккуратнее в выражениях, уважаемый. Никто здесь не кричит.  То что я считаю недостатками С++ я написал в соответствующем треде http://www.prog.org.ru/topic_7933_0.html  на который здесь была ссылка.
И я  могу говорить о недостатках С++ и премуществах D, потому что я пользовался и тем и другим. Вы - нет.

Приведите ссылку на Ваш пост где указаны недостатки  C++, а не голые фразы

offtop
че вы на человека накинулись? зашел спросить про кьюти... с такими наездами скоро суда вообще заходить никто не будет.  ;D

Никто не накинулся... Тема весьма интересна для всех. Но просто нужно оперировать фактами и объективно сравнивать два языка. Сранение не должно базироваться на личных ощушениях. А так у нас получаеться игра в одни ворота "С++ плохой, одни костыли, и непонятно для всех почему он плохой и в чем проявляються его костыли; D классный язык". Да, мы увидели список нововведений в D, обсудили это нововведения. Но так и не увидели список костылей и подпорок в С++, неуслышали в чем он именно плох. То что он "лично мне не нравиться" это не есть довод, имхо.

Извените, ни в коем случае не хотел вас обидеть

http://www.prog.org.ru/index.php?topic=7933.msg41537#msg41537
Также на первой странице той ветки хорошие посты(много лучше моего :) )

Кстати говоря - многим здесь не нравится амбициозное название языка - D. Автор языка назвал его Mars, но комьюнити убедило его переименовать в D  :P

Сорри, но я невижу из вашего поста описания недостатков С++ :). Нашел следующее ваши высказывания:


Как вы сами понимаете, это не есть ответ на мой вопрос. Ладно, возвращаемся к теме биндинга :)

По теме биндинга, упоминали что можно вызывать слоты и сигналы по имени. Это через QMetaObject делается?

Да, QMetaObject::invokeMethod

про этот метод почитайте
там же есть пример использования

Приступил к оборачиванию строк. У меня есть строка QString str, я ее перегоняю в const char* с помощью str.toUtf8().data(). 2 вопроса - будет ли она null-terminated и второй - это аллоцированная строка, которую я могу безопасно использовать дальше, или нет?

toUtf8() возвращает QByteArray, его метод data() возвращает указатель на внутреннее представление

Проще говоря: да, нет.

Не уверен насчет представления строк в D, но возможно проще будет конвертировать через метод int QString::toWCharArray ( wchar_t * array ) const

Разработка идет размеренным ходом, близок к тому чтобы закончить обертку QObject QCoreApplication и некоторых классов из qt.core. Есть вопрос который хочу задать знатокам Qt - в API Qt есть ли классы кроме потомков QObject для конфигурирования которых используются виртуальные функции. Или это только прерогатива QObject? Какая политика по этому поводу в Qt?

Поясните что значит конфигурирование виртуальными функциями, всмысле изменение поведения потомками путем переопределения виртуальных функций интерфейса класса?
Если так то как минимум классы Graphics View Framework делают это. http://doc.trolltech.com/extras/qt43-class-chart.pdf в помощь

Итак появились первые результаты. Работает около 170 классов из пакетов core, gui и opengl(естественно работает то, что протестировано, то есть не так много). Подкреплено некоторым количеством примеров портированных из С++. К сожалению важная часть, сигналы/слоты еще не реализованы, так как у человека который их должен сделать сейчас мало времени. Работает только на linux, так как я им пользуюсь и опять же времени адаптировать систему сборки и т. д. нету пока. Кому интересно - проект здесь: http://code.google.com/p/qtd/

а разве Qt - это widget toolkit?

2 Константин, выходит, что widget toolkit, раз уж GUI на первом месте.

хмм...несколько неверная трактовка на мой взгляд.
я бы сказал, gtk - widget toolkit, т.к. не может использоваться без гуя. а Qt легко и непринуждённо может использоваться и для CLI/CGI, и для демонов...

У D есть богатая стандартная библиотека которая на полную использует продвинутые возможности языка. Qt - это фреймворк для С++, для D - это только GUI тулкит. Из Qt меня в первую очередь интересует GUI. SQL, некоторые части QtCore, и так далее для меня на втором месте. Конечно было бы неплохо и все остальное сделать, но я в основном этим один занимаюсь и у меня ограниченные ресурсы для такой громадной вещи как Qt. Виджеты то еще далеко не все закончены.
А сигналы слоты я сам сегодня начну пилить, планирую к концу недели закончить.

PyQt делает и поддерживает тоже 1 человек. :)
Причём он поддерживает Qt полностью.
Где-то попадалось интерьвю с ним - он сделал sip - пакет для упрощения привязок C++ Api к python-у. А потом некоторую тулзу, которая автоматом генерит привязки по всему Qt.
Так что ему только остаётся разруливать какие-нибудь редкие сложные места. :)

1. Он профессиональный программист, а я нет, и квалификация у меня ниже.
2. Это его источник доходов(не знал что он один, из этого могу предположить что человек он далеко не бедный ;) ) Для меня же - нет.

Биндинги у меня тоже конечно же автоматом генерируются, иначе это было бы мертвое дело  :) там много ручной работы тем не менее. Да и еще некоторые вещи пока не умеют генерироваться(преобразование из Qt контейнеров в D массивы и обратно, к примеру) Было бы свободное время, неделька или две, я бы возможно закончил.

Прошу помощи у людей, которые использовали cmake и Qt на Windows с MinGW. Я пытаюсь собрать dll содержащую С++ часть биндинга, то есть по сути это должно мало отличаться от сборки программы использующей Qt.
вот файл CMakeLists.txt:
Объектники комилируются успешно а вот на стадии линковки вылезают ошибки типа
undefined reference to '_imp___ZN7QWidget14setAcceptDropsEb'
Судя по всему не связывается dll самого Qt. Что здесь не так?

такое бывает когда dll'ка собрана одним компилятором/РежимомКомпиляции, а программа другим

но я использую для компиляции mingw и Qt которые шли вместе с QtCreator.

В WIKI имеется статью по поводу CMake + Qt - CMake как система сборки для Qt приложений (http://prog.org.ru/wiki/index.php?title=CMake_%D0%BA%D0%B0%D0%BA_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%B4%D0%BB%D1%8F_Qt_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9). Возможно в ней вы найдете ответ. Если нет - обратитесь к автору статьи - Dendy

спасибо за ответ, там тоже самое. Попробовал собрать исполняемый файл, получилось. Дело значит в том что я компилирую dll, которая использует Qt.