Амбициозные идеи !!! - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Угомонись.
Почему чушь? Просто посчитайте сколько указателей нужно перебрать чтобы добраться до нужных данных или функции.
Если конешно считать умеете. :)
Вы угомонитесь? что перебирать? куда добираться? при создании нового экземпляра класса - иже переменная типа класс, создается дубликат таблицы связей и всё
доступ к данным, что в классе, что в обычной переменной по скорости одинаков, все описательные меры по разделению прав доступа внутри классов (privat, public) - это все на уровне компилятора, откомпилированный код работает только с физическими ячейками памяти
Ну допустим будет "сложный динамический класс" который порождается хитрым образом налету из других хитро-порождаемых классов. Ну и что? В конце концов всё будет считать конкретная функция. Ну дык а стоило огород городить ради таких цирковых выкрутасов?
болезнь прогрессирует? Вам же несколько раз сказали, ООП освобождает программиста от рутинных действий по подготовке данных, по контролю за содержимым данных, а как Вы реализуете методы внутри класса или будете вызывать сторонние ф-ции дело программиста
ООП - это тоже уже прошлый век. Сейчас тренд это аппаратно-ориентированное программирование, которое в основном на С, например таже CUDA. C выходом процессоров со встроенным GPU это будет еще более усиливаться. В планах процессорных фирм вообще прекратить со временем выпуск только универсальных процессорных ядер
тут я не компетентен, да и в Ваших устах эта информация не выглядит достоверной
ЗЫ: к чему пишу - не пишите всякую чушь на технических форумах - можете поделиться знаниями - делитесь, нет знаний - спросите
Вы угомонитесь? что перебирать? куда добираться? при создании нового экземпляра класса - иже переменная типа класс, создается дубликат таблицы связей и всё
доступ к данным, что в классе, что в обычной переменной по скорости одинаков, все описательные меры по разделению прав доступа внутри классов (privat, public) - это все на уровне компилятора, откомпилированный код работает только с физическими ячейками памяти
Тогда такой вопрос к знатоку. Есть класс который состоит из трёх динамических массивов (размеры на стадии компилирования неизвестны).
А сейчас пожалуйста посчитайте и сравните количество операций для обращения к произвольному статическому массиву и динамическому массиву находящемуся внутри класса.
тут я не компетентен, да и в Ваших устах эта информация не выглядит достоверной
Причем тут логика программы к представлению данных? Это вещи никак не связаны.
Логика программы - это арифметические действия над любыми входными данными, а представление данных - это лишь данные в том или ином формате.
А программный код при ООП сократить нельзя по определению, так как появляются внешние указатели для объектов для обращения к внутренним данным (функциям и переменнным) вместо прямого обращения. Но так как вычисление указателей и обращение к памяти это очень медленная операция, то и производительность замедляется соответственно.
Разработка ООП приложения - это не то же самое, что разработка библиотек классов. Строго говоря, разработчика библиотеки _вообще_ не должно беспокоить то, для чего _конкретно_ его библиотека будет использоваться теми, кто пишет сами прикладные программы. Например: производителю молотков совершенно наплевать, каким образом вы используете его продукцию - для забивания гвоздей или для колки орехов. Его задача - создать инструмент. Также и в ООП классы - это инструмент, предназначенный для решения некоего круга задач, как правило, широкого и далеко не всегда четко очерченного (кто его знает, может вы молотком пойдете тараканов мочить?).
Еще раз повторюсь - для решения простейших задач ООП не нужно. Но с другой стороны, вы же не считаете, что каждый пожелавший забить гвоздь должен сам себе смастерить молоток?
Конечно тут можно возразить, типа есть же библиотеки функций, нахрена понадобились еще классы какие-то? Но в таком случае вы лишаете себя удобств, которые даются механизмами наследования, расширения типов, перегрузки и т.д. Грубо говоря, вы можете прикрутить к молотку своими руками сделанный моторчик и заставить его работать по-вашему, но для этого не придется разбираться в устройстве молотка: все, что вам нужно знать - это то, что им можно забивать гвозди.
Так что, поверьте, ООП действительно реально облегчает жизнь той части программистов, которые пишут прикладные программы. Другое дело, что возможности библиотек под MQL5 пока весьма ограничены, но это вопрос времени, и займутся этим уже разработчики библиотек (хотя, разумеется, это могут быть -но не обязаны - те же самые люди). При хорошо развитой системе библиотек классов пользователю-программисту бывает достаточно написать в программе одну-две строчки типа "1. программа, вот данные" "2. программа, считай", практически не задаваясь вопросом, как это в деталях работает. При структурно-ориентированном программировании такого не достичь.
Мне кажется, Ваше предубеждение по отношению к ООП - это результат того, что вы либо не сталкивались с достаточно сложными задачами, либо просто из-за лени или каких-то других причин не желаете заниматься этим. Я бы сказал, что зря. Однако, хозяин - барин.
Тогда такой вопрос к знатоку. Есть класс который состоит из трёх динамических массивов (размеры на стадии компилирования неизвестны).
А сейчас пожалуйста посчитайте и сравните количество операций для обращения к произвольному статическому массиву и динамическому массиву находящемуся внутри класса.
а причем тут классы? это работа с динамическими или статическими массивами, и не важно где Вы используете динамические массивы -в классе или просто в переменной
то, что работа с динамическими массивами немного дольше - это "и ежу понятно" - идет контроль за выход за пределы массива и часто будет вызывать диспетчер распределения динамической памяти
alsu:
1. Но в таком случае вы лишаете себя удобств, которые даются механизмами наследования, расширения типов, перегрузки и т.д. Грубо говоря, вы можете прикрутить к молотку своими руками сделанный моторчик и заставить его работать по-вашему, но для этого не придется разбираться в устройстве молотка: все, что вам нужно знать - это то, что им можно забивать гвозди.
2. При хорошо развитой системе библиотек классов пользователю-программисту бывает достаточно написать в программе одну-две строчки типа "1. программа, вот данные" "2. программа, считай", практически не задаваясь вопросом, как это в деталях работает. При структурно-ориентированном программировании такого не достичь.
1. При ОПП точно также приходится разбираться с классами - что именно они делают. Точно также как если бы это была какая-то функция. Но с классами сложнее отследить всю цепочку поэтому в общем случае времени на изучение их структуры тратиться больше, при том же уровне функциональности.
2. При структурно-ориентированном программировании вы тоже без всяких проблем можете организовать подобные действия, не вдаваясь в детали в которые кто-то уже вдавался ранее.
а причем тут классы? это работа с динамическими или статическими массивами, и не важно где Вы используете динамические массивы -в классе или просто в переменной
Хорошо, тогда задам вопрос попроще. Сравните количество операций при обращении к переменной одномерного и двумерного массивов.
И сейчас будете утверждать что разницы почти никакой нет?
Хорошо, тогда задам вопрос попроще. Сравните количество операций при обращении к переменной одномерного и двумерного массивов.
И сейчас будете утверждать что разницы почти никакой нет?
это тож вопрос из ООП?
если нет, тогда : если массив статический - то никакой разницы по производительности не будет при обращении, что к одномерному массиву, что к двухмерному, т.к. данные многомерного массива хранятся в памяти по строкам, примерно как если у ВАс массив x[20] и массив y[2][10], то в памяти данные y будут записаны: вначале y[0] а потом y[1], что физически будет располагаться как и x[20]
если и есть некая задержка по производительности, то она настолько незначительна, да и возникать может только из-за контроля выхода за пределы массива
если массив динамический - зависит от конкретно производителя компилятора - насколько код менеджера памяти оптимизирован (на Delphi бОльшая часть модуля System написана на ASM), т.кю распределение памяти для многомерного динамического массива немного сложнее, но тут, обычно проблема не в динамических массивах, а в программисте - насколько он оправданно и часто вызывает перераспределение памяти под динамичсекий массив
ЗЫ: спс за общение - но не могу на Ваше непонимание элементарных вещей тратить столько времени - начинайте читать самостоятельно
это тож вопрос из ООП?
если нет, тогда : если массив статический - то никакой разницы по производительности не будет при обращении, что к одномерному массиву, что к двухмерному, т.к. данные многомерного массива хранятся в памяти по строкам, примерно как если у ВАс массив x[20] и массив y[2][10], то в памяти данные y будут записаны: вначале y[0] а потом y[1], что физически будет располагаться как и x[20]
Вы ошибаетесь так как не знаете простейших вещей.
Данные любых массивов располагаются в памяти линейно. От первого до последнего, при этом чтобы обратиться к элементу x[15], то для вычисления этой переменной нужно вычислить адрес начала массива плюс смещение 15 что и будет адресом переменной. При двумерном массиве например x[2][5], сначала нужно вычислить смещение для второй строки а потом прибавить к ней смещение для 5 элемента, то есть в два раза большее количество операций.