Ошибки, баги, вопросы - страница 2637
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
может по сравнению с функциональным?
Смотрим википедию:
И выясняем, что оказывается это не одно и тоже.
Так что все же процедурное...
Возможно удивлю Вас, но современные молодые программисты считают ООП более легким программированием по сравнению с процедурным.
Вы мыслите категориями 25-летней давности. Современная молодежь ООП впитывает уже с молоком матери. Учите ООП, если хотите быть в тренде, а иначе удел один - ворчание.
А это действительно так и есть. Вот пусть старые программисты попробуют решать нынешние олимпиадные задачи для школьников.
То что ранее проходили в ВУЗ-ах, такие темы как динамическое программирование, теория графов, ООП, классы и т.д. нынешние школьники 9-10 классов(не все конечно) такие задачи решают за считанные минуты.
И это закономерно. Закон природы :)
Да я то понимаю ООП, не в том объеме конечно как хотелось бы.
Это не ворчание, а конструктивное предложение.
Чтобы разработчику не писать одну функцию, по выделению двух malloc, заставляют пользователей учить ООП.
Это конечно ещё тот прогресс, развития и популяризации языка. Оно и видно как тут любят и понимают ООП.
Понимаешь Николай, всё что в обёртке, это лишний код на выполнение, думаю не нужно объяснять.
Про современные оптимизирующие компиляторы, тоже не нужно рассказывать, мы не знаем какие инструкции он применит.
Возможно и я вас удивлю, что даже американские программисты предпочитают писать в процедурном стиле, не потому что ООП плох, а потому что проще и быстрее получается код.
И если в проекте не стоит объектных задач, зачем использовать обёртки, которые нужно ещё как то понять, для молодежи ))
По этому не соглашусь с вами, что молодежь охотно впитывает ООП.
Я мыслю языком Си, на котором и построена логика языка mql.
Язык Си рождён в 1972 году, так что получается что 48-летней давности ))
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.
Ну это вовсе не так. Просто до сих пор много используется языков без ООП. Си например. В Канаде, например, большинство правительственных учереждений сидят на Коболе и никак слезть с него не могут.
https://www.tiobe.com/tiobe-index/
Роман, я, честно говоря, не понимаю почему Вы подняли волну по поводу изменения размерности матриц - какие могут быть сложности с этим.
Не нужны ни указатели, ни ООП для этого.
Все равно для компьютера массив любой размерности - это одномерный массив.
Вот и работайте с одномерным динамическим массивом. А матрицы формируйте виртуально и делайте ресайз как угодно через фукции.
Например что-то типа:
Сам на практике в коде использую только одномерные массивы, хотя и имею дело с многомерными на основе этих одномерных.
По этому есть очевидная хотелочка, сделайте пожалуйста функции на подобие ArrayResize только для матриц ArrayResizeMx(A, n, m)
все сделано, не хотите готовые решения с помощью ООП (от Вас не требуется знание ООП, используйте готовое!)
используйте ALGLIB , там есть метод изменения размера матрицы Resize().... но все равно все выполнено с помощью ООП )))
ЗЫ: поиском по форуму, было много раз на эту тему общение, там и примеры были, можно структуру с полем массив, обернуть в массив таких структур - будет без ООП, но по моему громоздко все это выглядит
Я мыслю языком Си, на котором и построена логика языка mql.
Язык Си рождён в 1972 году, так что получается что 48-летней давности ))
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.
я уже не помню чистый С, только в универе давно изучал, но если не ошибаюсь, то в С как раз и не было динамических массивов как таковых, но была возможность работать с указателями на память и поэтому работа по выделению памяти по контролю доступа к памяти лежала полностью на программисте, что по сути будет той же оберткой
ладно, холивар знатный может получиться, смысла нет продолжать
Роман, я, честно говоря, не понимаю почему Вы подняли волну по поводу изменения размерности матриц - какие могут быть сложности с этим.
Не нужны ни указатели, ни ООП для этого.
Все равно для компьютера массив любой размерности - это одномерный массив.
Вот и работайте с одномерным динамическим массивом. А матрицы формируйте виртуально и делайте ресайз как угодно через функции.
Да это понятно, что для компьютера любая размерность это одномерный массив.
Всё дело в удобстве использования языка, если в коде мы видим размерность [][], то мы визуально понимает что это матрица, а не одномерный массив.
Читаемость кода в разы повышается, чем гадать что же там содержит в себе []
Не думал что на просьбу добавить одну функцию по выделению памяти для матриц, встречу такое не понимание.
Вы же все пользуетесь ArrayResize, удобно ведь, и не паритесь с этим. Какая проблема для разработчика написать функцию выделения памяти для многомерного массива?
Правильно не каких проблем и препятствий нет, а для пользователей это удобство организации кода. Вот решил я портировать огромную хорошую Си библиотеку численных методов на mql,
а нормальных mql инструментов для этого нет. Снова какие то костыли, что пропадает всё желание городить не эффективный код.
Да я то понимаю ООП, не в том объеме конечно как хотелось бы.
Это не ворчание, а конструктивное предложение.
Чтобы разработчику не писать одну функцию, по выделению двух malloc, заставляют пользователей учить ООП.
Это конечно ещё тот прогресс, развития и популяризации языка. Оно и видно как тут любят и понимают ООП.
Понимаешь Николай, всё что в обёртке, это лишний код на выполнение, думаю не нужно объяснять.
Про современные оптимизирующие компиляторы, тоже не нужно рассказывать, мы не знаем какие инструкции он применит.
Возможно и я вас удивлю, что даже американские программисты предпочитают писать в процедурном стиле, не потому что ООП плох, а потому что проще и быстрее получается код.
И если в проекте не стоит объектных задач, зачем использовать обёртки, которые нужно ещё как то понять, для молодежи ))
По этому не соглашусь с вами, что молодежь охотно впитывает ООП.
Я мыслю языком Си, на котором и построена логика языка mql.
Язык Си рождён в 1972 году, так что получается что 48-летней давности ))
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.
MQL построена на С++.
Роман, чтобы ввести эти возможности которые вы говорите, придётся в MQL внести и много дополнительных вещей по работе с памятью. А это уже усложнение для начинающих.
Вы же сами говорили что надо проще чтобы было тем кто непрофессионал.
Это ситуация типа "Я хорошо научился крутить педали на велосипеде, это так просто и понятно. Давайте в БМВ введём педали, будет проще." :)
з.ы. Я вообще придерживаюсь мнения, что и процедурный и ООП стиль убоги и непрактичны))
все сделано, не хотите готовые решения с помощью ООП (от Вас не требуется знание ООП, используйте готовое!)
используйте ALGLIB , там есть метод изменения размера матрицы Resize().... но все равно все выполнено с помощью ООП )))
ЗЫ: поиском по форуму, было много раз на эту тему общение, там и примеры были, можно структуру с полем массив, обернуть в массив таких структур - будет без ООП, но по моему громоздко все это выглядит
я уже не помню чистый С, только в универе давно изучал, но если не ошибаюсь, то в С как раз и не было динамических массивов как таковых, но была возможность работать с указателями на память и поэтому работа по выделению памяти по контролю доступа к памяти лежала полностью на программисте, что по сути будет той же оберткой
ладно, холивар знатный может получиться, смысла нет продолжать
Пробовал ALGLIB возникает проблема с печатью из объекта, функция ArrayPrint не выводит на печать объекты.
А из [][] выводит красивенькую матрицу, даже с заголовками, опять же удобство восприятие информации, когда необходимо визуально отслеживать результат расчёта.
Да, темки поглядел на форуме, но не впечатлило. Вот именно что это всё выглядит громоздко и не эффективно. Си очень элегантный язык, а mql его коверкает.
Да, в Си память для динамических матриц через указатели выделяется, но в mql нет указателей на переменную, снова поход в объекты, нафига спрашивается.
Когда всего то пользователям нужна одна функция ArrayResizeMx(A, n, m, k) а она уже будет в нативном исполнении, понимаете разницу.
Да смысла нет продолжать, если услышали и сделают, тогда большое спасибо. Но функция реально полезная и необходима.
Рассуждения вслух, но скорее это обращение к разработчику.
По этому Zloy не принимайте на свой счёт.
Получается работа с динамическими матрицами возможна только через объекты или структуры. В общем очередной костыль получается.
Указателей на переменную в mql нет, остаётся использовать объектный подход, там указатели есть.
Получается чтобы использовать динамические матрицы, пользователю необходимо знать ООП и работу с указателями, да и ещё в исполнении MQL.
Многие такими знаниями владеют? Сами знаете ответ. Мне то разобраться с объектным подходом не составит труда, но для тех кто не владеет ООП
создаётся искусственный порог использования языка, в частности по работе с динамическим матрицами.
Как мне кажется, разработчик наоборот должен быть заинтересован в упрощении использования языка, а не его усложнение.
То есть разрабатывать такие функции, которые необходимы пользователю для удобной работы с языком.
А тем более с матрицами, чуть ли не основой численных методов.
По этому есть очевидная хотелочка, сделайте пожалуйста функции на подобие ArrayResize только для матриц ArrayResizeMx(A, n, m),
ну и для многомерных возможно. То есть дайте возможность работать с матрицами не как с объектами, а как с привычными массивами в стиле С.
Тем более для визуального отображения матриц, функция ArrayPrint(A, 0) печатает матрицу из массивов, а не из объекта.
Разработчики высказывались об этом вполне конкретно. Здесь
Разработчики высказывались об этом вполне конкретно. Здесь
Далеко ходить не надо, следующий пост, с конкретными вопросами от Привала,
Знаю его давно примерно с того же времени, грамотный военный разработчик, и что, почему он от сюда ушёл, ответ очевиден.
Прошло десять лет, что то изменилось?
Как была кодобаза заполнена простыми алгоритмами, так на этом уровне и осталась. Где профессиональные решения?
За то к питону интеграцию пилим, чем дать инструменты для написания этих профессиональных решений, и развития своей кодобазы.
Вот где ошибка, нет инструментов, нет соответствующего уровня программистов.
Ладно, пойду посплю, не спал ещё. Удачи всем.
Так что все же процедурное...
Процедурное это си, там все элементарно, просто больше возможностей выстрелить себе в ногу.
Думаю вы таки попутали и имелось в виду функциональное. Впрочем, неважно.