Создать массив своих объектов. Вернуть элемент класса функцией и поместить его в массив. - страница 3

 
Sergey Eremin:
((CInfo*)ListInfo.At(2)).SomeMethod(111);

Пишем ((CInfo*)ListInfo.At(2)), жмем на точку, а список методов и свойств не открывается. Оказываемся лишены прелестей прогресса. Нечто подобное подразумевал, когда писал про сотню методов. Список не открывается, значит надо или помнить, или заглядывать в файл с классом.  Еще сколько скобочек надо поставить и даже знак * из четвертого ряда клавы с нажатым шифтом. 

 
Dmitry Fedoseev:

а список методов и свойств не открывается

Да эта проблема, на мой взгляд, с ООП не связана. В МТ пока нет хорошего браузера классов и функций а-ля Visual Studio. Будем надеяться, в обозримом будущем он появится.

 
Dmitry Fedoseev:

Пишем ((CInfo*)ListInfo.At(2)), жмем на точку, а список методов и свойств не открывается. Оказываемся лишены прелестей прогресса. Нечто подобное подразумевал, когда писал про сотню методов. Список не открывается, значит надо или помнить, или заглядывать в файл с классом.  Еще сколько скобочек надо поставить и даже знак * из четвертого ряда клавы с нажатым шифтом. 

Я просто ответил на вопрос "как обратиться к методу класса".

Что список параметров не отображается, это уже недостаток редактора кода (другие редакторы-то это умеют). И так явно быть не должно, так что это нельзя назвать недостатком подхода. Кстати, то же самое со статичными методами, MetaEditor не вываливает их выпадающим списком (но это уже отдельный разговор). Всё никак не соберусь в СД обратиться по этому поводу (а положительный опыт обращения насчёт поведения редактора имеется) :)

А вот насчёт набора лишних символов - ну чёрт его знает. В приличных проектах я лично больше трачу времени на обдумывание архитектуры и логики, чем на набор кода, и этих нескольких секунд не жалко. Всё должно быть адекватно решаемой задаче, если так надо, то не сломаюсь, наберу :)

А может просто за годы работы с C++ настолько привык к такому приведению типов, что уже не испытываю никакого дискомфорта...


Опять же, повторюсь, в этом споре я ни на чьей стороне: я думаю, всё должно быть в меру и к месту. Любой из способов решения имеет право на жизнь, если он работает корректно и адекватен поставленной задаче.

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

 
Vasiliy Sokolov:


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

Причём тут дядя Кнут и ООП? ООП не предназначен для оптимизации скорости выполнения кода и даже для оптимизации кода, а предназначен для создания универсальных (многоразовых) кодов. Для увеличения скорости, лучше всего кодить в ассемблере или даже в машинном коде.

Помнится давно и неправда, пришлось поработать в одном КБ. Простое устройство, процессор, шины, контроллеры, таймеры, память оперативная и постоянная. Весь код писался в машинных кодах в восьмеричной системе. ОЗУ куцый, ПЗУ (для хранения программ) тоже. Каждый байт на счету. Сложно было создавать универсальный код, поэтому при удалении или добавлении функционала, зачастую вместо кодирования проще было найти воплощение в готовом железе (подобрать соответствующие микрухи по каталогу). А если не получится с железом, то переписывать всё чуть ли не с нуля, поскольку код чрезмерно оптимизирован. Дядя Кнут тогда рулил немерянно.

То ли дело ООП! ОЗУ никто не считает. Вломы сочинять, дык зачастую можно найти готовую библиотеку. Что не подходит из библиотек, то малость допилить, т.е. переопределить методы. Дядя Кнут отдыхает.

Причина обращения: