[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Среды разработки



On 16.10.2012 21:30, "Артём Н." wrote:
16.10.2012 21:14, Alexander Danilov пишет:
Тоже GLADE?
glade хорош для того, чтобы прикинуть, как должен выглядеть результат,
Вообще не имею о нём представления.

В данном случае я хочу
оптимизировать работу там, где вижу возможность оптимизации. Смена
редактора кода реально мне может помочь в плане производительности.
Понятно.
Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
Переключиться между cpp и h я могу через Ctrl+F6.
А в vim?
Я могу и обратную ситуацию промоделировать.

Есть набор полей с подписями и разными типами данных и разными фильтрами, пусть
их положим штук 30, часть их них опциональна и зависит от других полей, берётся
всё это описание из внешнего источника данных, который может меняться. Задание:
покажите через Ctrl+F6 эту формочку.
Вот в нормальной среде (язык+редактор) я это сделаю, а в продуктах от Борланда
можно долго
[ *** любой понравившийся вам матерный эквивалент*** ]
Так а что сделать-то надо?
Графический интерфейс пользователя?
И как вы сделаете это "в нормальной среде"?

Задача не очень ясна, но, раз уж упомянули эту RAD, применительно к данному случаю.
Я бы выделил группы полей, зависящих друг от друга.
И сделал мастера (или появляющиеся вкладки, в зависимости от выбора
пользователя, например TTabControl или как-то так, не помню).
"Внешний источник", например, XML или БД?
Как реализовать построение интерфейса зависит от структуры источника.
Если есть транзитивные зависимости, то мастера там подойдут лучше всего.
Фильтры и тип предоставляются источником.
Возможно использовать что-то типа TMaskEdit (да, я согласен, он не особо, но
возможно написать и своё) и списки для представления наборов значений.
Размещать элементы интерфейса на формах придётся программно.

Цитата: "Размещать элементы интерфейса на формах придётся программно".
Вывод: Использовать эти самые рисующие RAD имеет смысл только для простых формочек, состоящих из фиксированного небольшого количества заранее известных элементов. В противном случае размещать придётся программно, а это проще делать на языках, умеющих более шибко манипулировать данными.



Непонятно одно: в чём, в данном случае, отличие этой RAD от "нормального языка"?



А вы попробуйте передать в процедуру на паскале массив сложных структур данных - за то время, что будете описывать все типы, из которых состоит эта структура и массив и параметры функции и прочее, на нормальном языка (Haskell/Lisp/Tcl/Python/Ruby/Perl,... зал, помогайте!) уже можно будет написать всю программу. Вот на C++ можно будет "исхитрится" и объявить параметр как "void*", а потом, когда наступит очередная полоса "невезения", сидеть в отладчике и удивляться: "как же так, ну что тут сложного, подумаешь, *(++(*p)->[*++i])+***p++, чего он глючит?!"


Reply to: