[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]

[Burichan] [Futaba] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PNG
  • Maximum file size allowed is 10240 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1302435749608.jpg -(666141 B, 1875x1375) Thumbnail displayed, click image for full size.
666141 No.57317  

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

>> No.57326  
File: 1302437579988.jpg -(65390 B, 322x411) Thumbnail displayed, click image for full size.
65390

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

>> No.57330  

вообще довольно классная софтина, работает быстрее эклипса и всё есть.

>> No.57333  
File: 1302439621617.jpg -(68090 B, 660x440) Thumbnail displayed, click image for full size.
68090

>>57326
QT претендует на мультиплатформу, включая мобильные устройства. GTK за пределами Линукса выглядит и работает как говно и разработчики не стараются это изменить.

>> No.57335  

Qt больше, чем GTK. GTK это только графика. Более того, GTK базируется на C, а Qt на C++ со всеми радостями ООП.
И да, кросплотформенность имба.

>> No.57340  
File: 1302441724385.jpg -(279299 B, 700x756) Thumbnail displayed, click image for full size.
279299

кстати, кто на чём кодит?
тут где-то был один кодблокс-кун, а больше как-то и неизвестно.

>> No.57351  

>>57340

>где-то был один кодблокс-кун

Я всё ещё здесь.
>>57335

>GTK базируется на C

Есть http://www.gtkmm.org/en/ со всеми радостями ООП.

>> No.57375  
File: 1302459495228.jpg -(21009 B, 430x376) Thumbnail displayed, click image for full size.
21009

>>57335

>C++ со всеми радостями ООП.
>> No.57376  

>>57375
Вот GTK-шная Vala — это серьёзный бизнес.
А С++ — это С на костылях.

>> No.57410  

>>57333

>GTK за пределами Линукса выглядит

Тащемта он и в пределах выглядит как говно.

>> No.57473  

>>57333

>GTK за пределами Линукса выглядит и работает как говно

Да ладно. Под виндой у меня стоит несколько приложений на гтк. Все хорошо работает, жалоб нет.
gtkmm - один из лучших гуевых интерфейсов, с которым я когда-либо работал.
Qt не нравится тем, что это все-таки не C++.

>> No.57485  
File: 1302560674456.png -(115000 B, 451x308) Thumbnail displayed, click image for full size.
115000

>>57473
Мне больше всего Cocoa понравилось из гуёвых интерфейсов, Objective-C напоминает smalltalk. После очищения мозга нормальным ООП смотрю на цирк с костылями в С++ с сочувствием.

>> No.57548  

>>57376
Год назад вала была очень сырая. Не думаю, что сейчас что-то изменилось.
Да и потом, вала гвоздями прибита к glib. Это очень плохо.

>> No.57556  

>>57485
Как раз сейчас работаю с ней. gtkmm все-таки больше нравится даже не смотря на то, что в нем приходится руками сигналы биндить.

>После очищения мозга нормальным ООП смотрю на цирк с костылями в С++ с сочувствием.

ООП, построенное на делегатах, и практически с утиной типизацией. Ручной реф каунтинг тоже порой раздражает (для главного window controller'a, к примеру, пришлось завести специальный метод аля-деструктор, который срабатывает, перед закрытием приложения. Ранее деструктор не вызывался т.к. на объект где-то оставалась ссылка. Ссылка была где-то за пределами моего кода. Почитал на форумах, там пишут, что это нормальная практика обрабатывать сообщение о закрытии приложения таким образом. И кто-то тут после всего этого завел разговор о костылях...).
Мне самому вобщем-то нравится Cocoa, но все-таки она очень далека от идеала.
Кстати, о C++ и его ООП... Что конкретно не устраивает-то?

>> No.57634  
File: 1302651498370.jpg -(184840 B, 800x450) Thumbnail displayed, click image for full size.
184840

>>57556
В С++ нет интерфейсов, объектная модель просто отсутствует, нет метаинформации, делегирования. Зато есть множественное наследование со всеми его проблемами. В Objective-C можно прямо на ходу узнать какие интерфейсы поддерживает объект, какие у него есть методы. Можно даже на ходу добавить новый метод. В плюсах даже нет ссылок на метод класса без костылей.

>> No.57643  

>>57634

>В С++ нет интерфейсов

Это да, хотя никто не мешает писать чисто абстрактные классы. Но на уровне языка эта семантика отсутствует.

>объектная модель просто отсутствует

Не понял, о чем конкретно речь.

>нет метаинформации

Рефлекшен в C++ хоть и можно реализовать разными способами, но это сложно. Это да. Однако стоит заметить, что рефлесия бывает реально необходима только в ограниченном круге задач. В остальных задачах она попросту вредна.

>Зато есть множественное наследование со всеми его проблемами.

Так говоришь, как-будто тебя кто-то заставляет активно и повсеместно применять этот инструмент. Я бы сказал, что отсутствие множественного наследования в objective c есть плохо, а не наоборот. Каждый инструмент имеет свое предназначение.

>В Objective-C можно прямо на ходу узнать какие интерфейсы поддерживает объект, какие у него есть методы. Можно даже на ходу добавить новый метод.

Рефлексия уже была. Это как с множественным наследованием: можно засомневаться, хорошо ли то, что эта фича вообще есть.

>В плюсах даже нет ссылок на метод класса без костылей.

boost::bind я так понимаю отнесен к костылям? Очень зря.

Ты бы лучше упомянул о лямбда-функциях (blocks) из коробки, об отсутствии необходимости декларации приватных методов в заголовке (вот правда необходимость в декларации членов по какой-то причине осталась, иначе была бы pimpl из коробки), а то, о чем ты говоришь, есть практически во всех современных языках.

>> No.57653  

>>57643

>Однако стоит заметить, что рефлесия бывает реально необходима только в ограниченном круге задач.

Например, написание пользовательского интерфейса

>то, о чем ты говоришь, есть практически во всех современных языках.

Речь шла о сравнении С++ и Objective-C в рамках написания gui

>boost::bind я так понимаю отнесен к костылям? Очень зря.

Of course all these snags are not fatal. C++ is a universal and powerful language; it is Turing-complete and thus capable of expressing every possible computational algorithm. Therefore, if an application demands dynamic features such as those found in Tcl/Tk, Scheme/Tk, Postscript, etc., C++ can always emulate them. On the other hand, why not to use a language where all these features are present by design?

http://okmij.org/ftp/c++-digest/CPP-GUI-mismatch.html
>> No.57676  

>>57653

>Например, написание пользовательского интерфейса

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

>Речь шла о сравнении С++ и Objective-C в рамках написания gui

Я лишь хотел сказать, что с такой логикой разные шарпы и явы ничем не хуже.

>http://okmij.org/ftp/c++-digest/CPP-GUI-mismatch.html
>1995

С тех пор много воды утекло. Например, было обнаружено, что он Turing-complete на этапе компиляции! Compile-time вычисления - то, чего очень не хватает в разных динамических языках.

>> No.57743  
File: 1302742336771.jpg -(74424 B, 450x750) Thumbnail displayed, click image for full size.
74424

>>57676

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

А всё остальное в пользовательском интерфейсе "пишется мышкой" во wysiwyg-редакторе.

>Я лишь хотел сказать, что с такой логикой разные шарпы и явы ничем не хуже.

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

>С тех пор много воды утекло.

Вопрос логичности выбора используемого инструмента остался.

  • Зачем в С++ костыли?
  • Программисты на плюсах часто стреляют себе в ногу
>Например, было обнаружено, что он Turing-complete на этапе компиляции! Compile-time вычисления - то, чего очень не хватает в разных динамических языках.

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

>> No.57757  

Коли это гуй-тред, спрошу здесь, а не в треде по программированию. В будущем возможно предстоит писать проприетарные немного-математические гуй-штуки, и вместо того, чтобы заниматься делом, я думаю, как это буду реализовывать. Есть опыт писания на PyQt, и к кутям, как средству разработки сложилось достаточно хорошее отношение(хотя визуально нравится больше гтк). В принципе, склонялся к плюсы+Qt/PyQt, в зависимости от сроков и всяких мелких факторов, но тут вспомнил, что у кутей что-то намудрено с лицензией, хотя, вроде денег хотят только если в само куте лезешь. Так вот, какие еще варианты существуют? Когда-то пробовал тыкать wx, но он оказался без документации и структура его выглядела странно, tk мертвый и неюзабельный для чего-то большого(а еще под линуксами выглядит как говно, да), насчет гтк тоже не знаю, что-то я сомневаюсь, что под win с ним не будет проблем. Ну не на моно же писать, в самом деле.

>> No.57772  
File: 1302768412231.jpg -(101541 B, 736x1000) Thumbnail displayed, click image for full size.
101541

>>57757
Всё правильно думаешь. Из кросплатформенного только qt, остальные варианты хуже. Заодно мобильные платформы охватываешь.

>насчет гтк тоже не знаю, что-то я сомневаюсь, что под win с ним не будет проблем.

Под вин не сталкивался, в маке бывают.

>> No.57782  

>>57743

>А всё остальное в пользовательском интерфейсе "пишется мышкой" во wysiwyg-редакторе.

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

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

У явы проблемы с внятными IDE для формошлепства (netbeans все-таки подлагивает и порой глючит), если мы говорим о гуях. Шарп не кросс-платформенен. Питон выглядит тут интереснее.

>Зачем в С++ костыли?

О чем конкретно идет речь?

>Программисты на плюсах часто стреляют себе в ногу

Где они не стреляют себе в ногу?

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

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



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]