Когда нужно использовать ООП?

[s-andriano]

Сообщение от Utkin

Загнал в динамический массив .

Это как?

Разные точки зрения на задачу - один результат.

А мне как раз нужен не один результат, а несколько разных.
Например, объект служит для составления списка уникальных имен. Мне нужно несколько независимых наборов таких имен. Как реализовать без объектов?

[Utkin]

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

[s-andriano]

Сообщение от Utkin

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

Не понимаю, как то или другой можно использовать в предложенной задаче.

protected
  a,b,c : integer;
  d,e,f : double;
  g,h : array of MyType;

Как это сделать без объектов?

[Utkin]

Через структуру. Бросьте Вы свои объекты. Задрало честное слово. Вы заранее ставите задачу так, чтобы решить ее только с помощью ООП. Какие нафиг объекты. Решайте поставленную задачу и все. Засуньте Ваши данные в структуру. А ее в динамический массив - вот Вам большое количество объектов нужной природы. Поскольку Вы совершенно не представляете как устроено ООП изнутри (а оно написано там не с помощью ООП, внезапно, да?), сразу пресеку этот сериал - методы интерпретируются следующим образом:

процедура(структура_характеризующая_данные_Вашего_объекта[индекс_динамического_массива], прочие_параметры)

вместо

имя_объекта.метод(прочие_параметры)

А если Вас ломает от индексов, вбейте константы с именами объектов. Что-то типа:

const имя_объекта=0;
процедура(структура_характеризующая_данные_Вашего_объекта[имя_объекта], прочие_параметры)

Серьезно, просто почитайте как реализуется ООП.

[DiemonStar]

По поводу 40-130 fps - откуда взялись эти цифры? Давайте уже тесты, доказательства, обзоры в студию! Голословничать не нужно.

Старенькое решение тестили на какой-то выставке ещё в 90-лохматых годах... И заняла она там довольно высокое место. Парень жил в соседней комнате в общежитии и создал её ещё до моего поступления. Так что я лишь видел результаты. Более свежее уже тестил я каким-то 3д-бенчмарком (уж почти 10 лет прошло с того момента) и хранить его желания не возникло... да и времени и винтов уже много сменилось. Так что, увы, прямых доказательств нет...

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

История из моей собственной практики: на третьем курсе решил потягаться с ребятками из борланда - делал курсовик по компьютерной графике... переписал основные функции (точки, круги, заливку и т.п.) на ассемблере и гонял на сравнение в паскале. Получилось, что я на половине функций обходил их на 10-20%, хотя кое-где алгоритм слабовато оптимизировал... При этом я особо не напрягался - точки ставил одним и тем же макросом для всех контурных фигур... поначалу меня это смутило, но потом я понял в чём дело: мой код был оптимизирован под один видеорежим, а у них использовался универсальный. Из-за этого мне требовалось меньше граничных условий, я всегда точно знал правильные смещения по видеопамяти и т.п.
Вроде-бы причём здесь объекты, но примерно о том и речь - объектный подход требует едва-ли не универсальности (я не говорю о тех поднятых с нуля классах, рождаемых программистом, а о стандартных наборах), тогда как адаптировать процедурный код куда как проще. Даже банальный TButton на форме обладает кучей в 95% случаев неиспользуемых свойств и методов, которые держат для оставшихся 5%.

Это все верно, только ООП то здесь при чем?

Ну так в библиотечном принципе те же ляпы, зачастую, что и в ООП)

[Пепел Феникса]

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

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

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

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

[s-andriano]

Сообщение от Utkin

Через структуру. Бросьте Вы свои объекты. Задрало честное слово. Вы заранее ставите задачу так, чтобы решить ее только с помощью ООП.

То есть Вы согласны, что некоторые задачи без ООП решить невозможно?
Лично я придерживаюсь гораздо более мыгеого варианта: "некоторые задачи без ООП решать очень неудобно"

Какие нафиг объекты. Решайте поставленную задачу и все.

Каждый раз с нуля?
Я предпочитаю заранее изготовить некоторый набор инструментов и потом ими пользоваться. А не писать для каждой задачи инструментарий с нуля.

Засуньте Ваши данные в структуру. А ее в динамический массив - вот Вам большое количество объектов нужной природы.

И Вы называете это высокоуровневыми программированием?
Замена простых переменных элементами массива в чем-то сродно прямой адресации памяти.
Вместо цикла:

for i := 0 to MaxI-1 do
  for j := 0 to MaxJ-1 do
    a[i + MaxI*j] := ...

Писать?

for a[MaxI*MaxJ+1] := 0 to MaxI-1 do
  for a[MaxI*MaxJ+2] := 0 to MaxJ-1 do
    a[i + MaxI*j] := ...

Поскольку Вы совершенно не представляете как устроено ООП изнутри (а оно написано там не с помощью ООП, внезапно, да?), сразу пресеку этот сериал - методы интерпретируются следующим образом:

процедура(структура_характеризующая_данные_Вашего_объекта[индекс_динамического_массива], прочие_параметры)

вместо

имя_объекта.метод(прочие_параметры)

А если Вас ломает от индексов, вбейте константы с именами объектов. Что-то типа:

const имя_объекта=0;
процедура(структура_характеризующая_данные_Вашего_объекта[имя_объекта], прочие_параметры)

Серьезно, просто почитайте как реализуется ООП.

У меня складывается впечатление, что именно Вы не представляете как устроено ООП изнутри.
То, что Вы предлагаете впихнуть в код процедуры объекта, в ООП делается либо на стадии компиляции, либо на стадии загрузки программы, либо на стадии создания объекта. Попытка перенести эти действия в код подпрограмм аналогичных методам объекта заведомо приведет к существенному снижению эффективности работы программы: вместо полезной работы они будут тратить время на выяснение, к какой именно из динамически распределенных структур нужно обращаться.
Опять же, нужно таскать с собой код, осуществляющий такое выяснение.
В общем, получается эмуляция ООП с существенным снижением уровня, лишним геморроем для программиста и существенным снижением производительности.

[Utkin]

То есть Вы согласны, что некоторые задачи без ООП решить невозможно?
Лично я придерживаюсь гораздо более мыгеого варианта: "некоторые задачи без ООП решать очень неудобно"

Я согласен с тем, что нельзя передергивать что я сказал. Вы изначально ставите задачу в терминах ООП. Описывайте задачу без них. Вот что я имел ввиду. Касательно того, что Вы подумали - я уже писал ранее.

Каждый раз с нуля?

Что за бред? Откуда такой вывод? На основании чего он был сделан? Сплошная женская логика.

Я предпочитаю заранее изготовить некоторый набор инструментов и потом ими пользоваться. А не писать для каждой задачи инструментарий с нуля.

Ну да процедурное программирование же не позволяет писать отдельные юниты, библиотеки кода, дллки и все прочее. Это же все ООП .

И Вы называете это высокоуровневыми программированием?

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

[DiemonStar]

У меня складывается впечатление, что именно Вы не представляете как устроено ООП изнутри

Включите любой дизассемблер: объект складывается из области данных и области кода (деление условное). Доступ к объекту идёт по смещению в озу. С тем же успехом это можно разнести в разные области памяти и использовать не менее эффективно. Тут больше вопрос не функциональности, а оптимизации...

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

Как-то они до этого не дотягивают))

[Utkin]

Писать?

Опять бред. На основании чего Вы делаете такой вывод? Просто потроллить?

То, что Вы предлагаете впихнуть в код процедуры объекта, в ООП делается либо на стадии компиляции, либо на стадии загрузки программы, либо на стадии создания объекта. Попытка перенести эти действия в код подпрограмм аналогичных методам объекта заведомо приведет к существенному снижению эффективности работы программы: вместо полезной работы они будут тратить время на выяснение, к какой именно из динамически распределенных структур нужно обращаться.

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

объект складывается из области данных и области кода (деление условное).

Это я и пытался до него донести. Плюс еще специальные таблицы для адресации всяких там виртуальных и динамических методов. И деление это не условное, а самое что ни на есть настоящее. Область кода - методы содержатся в классе. Объекты это и есть структуры данных, характеризующие состояние объекта. И при создании нового объекта копируются только поля, но не код. Код методов вызывается из описаний составленных в классе и как правило содержится в памяти только один раз независимо от числа экземпляров данного класса.