Re: Среды разработки
16 октября 2012 г., 18:56 пользователь "Артём Н." <artiom14@yandex.ru> написал:
> 16.10.2012 00:51, Sciko Good пишет:
>> Я пишу в основном расчётные консольные приложения, а когда к ним нужна
>> графическая морда, использую GTK, т.к. считаю Qt фактически является
>> одной большой библиотекой, да и последние тенденции к превращению её
>> во фрейморк для JavaScript не радуют.
> Не слежу. Не знаю. В смысле?
Посмотрите на последние версии Qt -- там интерфейс пишется на
JavaScript, а создание интерфейса с помощью С++ уже помечено как
устаревшее. Nokia писала, что в Qt5 вообще интерфейс будет писаться
только на JavaScript.
>> Code::Blocks вообще ужасен.
> Вот здесь возможно сильно подробнее?
Текстовый редактор на уровне блокнота, нет интеграции с DVCS, make не
создаёт, а каждый раз собирает проект сама, нет поддержки других
языков кроме C++. Разве уже это не повод не использовать эту поделку?
>> Netbeans требует таких плясок с бубуном, что убивает
>> всё желение с ним работать.
> Что там не так?
Чтобы что-то там заработало, надо настраивать всю среду. Причём долго
и весьма неочевидными способами.
>> Eclipse страшно тормозит. Именно после него я поверил, что Java тормозит.
> Серьёзно? Eclipse, вроде бы, не на Java написан? И не исключительно для Java?
А почему у неё сырцы сплошь джавовские?
> Где тормозит? На какой системе?
Debian, Ubuntu, AltLinux, Fedora, CentOS, Mandriva, Rosa, openSUSE,
SLE -- тормозит везде. В других на пробовал.
>> Lazarus представляет из себя копию Delphi со всеми его минусами.
> И плюсами.
Фактически единственный сомнительный "плюс" Dephi -- его преподают в
школах и вузах.
>> А их хватает, ведь не зря Dephi называют принцем быдлокодерских IDE.
> Штамп. RAD и "разработка от интерфейса" позволяют быстро наклепать прототип.
Вот именно это и является штампом .Быстро наклепать прототип позволяет
python, perl, lisp, haskell и т.п., но не Dephi, т.к. изначально
паскаль разрабатывался вовсе не для быстрой разработки и не содержит
даже банального синтаксического сахара. Быстро нарисовать интерфейс
позволяют такие программы как Glade, причём без какой-либо привязки к
языку.
> Причём, в виде скомпилированной программы. Это делает низким порог вхождения.
У интерпретируемых языков порог вхождения ещё ниже. И не надо тратить
время на компиляцию.
> И среднее качество кода, считается, гораздо ниже, чем у MSVS (которая считается
> "сложной в освоении").
Кстати, королём быдлокодерских IDE называют именно MSVS ^_^
>> В данном случае я хочу
>> оптимизировать работу там, где вижу возможность оптимизации. Смена
>> редактора кода реально мне может помочь в плане производительности.
> Понятно.
> Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
> Переключиться между cpp и h я могу через Ctrl+F6.
> А в vim?
А в vim ставите скрипт a.vim и получаете этот функционал. Можно
привесить на любое сочетание клавиш.
16 октября 2012 г., 19:07 пользователь "Артём Н." <artiom14@yandex.ru> написал:
> А GLADE только для GTK?
Да.
> Как оно вообще используется и где,
> Что там под windows?
Рисуешь интерфейс в редакторе, подключаешь в коде библиотеку,
описываешь какой сигнал связать с вызовом какой функции, отрисовываешь
окно.
>> Примерно вот так выглядит интерфейс половины программ.
> Нативный интерфейс...
Программа не моя. Просто скриншот похожий.
> Жаль, скриншотов под Linux нет.
Запустите Synaptic. Он тоже использует Glade.
16 октября 2012 г., 19:11 пользователь "Артём Н." <artiom14@yandex.ru> написал:
> 16.10.2012 18:41, Sciko Good пишет:
>> Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
>> C++, Pascal/Delphi и C#.
> Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с C++.
Вы удивитесь, как много на нём всего понаписали и продолжают писать.
> C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а
> спрашивать про его поддержку какими-либо средами, думаю не стоит).
.NET использует фактически один вантуз. В остальных ОС с ним будут
весьма большие проблемы. И в GNU/Linux его не любят. Почему? Читайте
RMS.
> C++ - почти стандарт.
В GNU/Linux стандартом является всё-таки обычный C. Это не учитывая
скриптовые и функциональные языки.
>>>> А тратить
>>>> время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
>>>> времени нет.
>>> На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.
>> Неужели в c++11 добавили автоматические управление памятью? Каюсь, не
>> нашёл. По крайней мере сборки мусора там нет точно.
> Зато есть библиотеки с "умными" указателями, коллекциями и прочим.
Как будто такого нет в C! В той же glib есть и более интересные вещи.
Вот только от ручного управления памятью это не освобождает.
> И классы, в
> которых очистку возможно произвести в деструкторе.
Гладко было на бумаге, но забыли про овраги... Именно такие классы и
порождают массу самых весёлых сегфолдов.
Программист под GNU/Linux будет переписывать на C только критически
важные по скорости участки кода. Остальные он сделает на каком-нибудь
другом языке, где есть автоматическое управление памятью. Даже на
таком тормозе как Python, если это будет удобнее. Например, прототип
Perl6 был написан на Haskell, потому что он лучше всего подходил под
эти задачи. А вантузные программисты почему-то пытаются всё сделать на
1 языке. Может проблема действительно в узком кругозоре?
Кстати, хотелось бы чтобы участники дискуссии различали сам интерфейс
(формочки) и логику его взаимодействия. Это как бы разные вещи.
Reply to: