Ошибки, баги, вопросы - страница 3382

Новый комментарий
 
A100 #:

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

В ООП нужно мыслить по другому
Ах, понимаю о чем Вы.
"обычный процедурный подход с использованием классов" - хорошая формулировка для моего текущего уровня программ.
Но есть жгучее желание реально освоить ООП. Как я понимаю, если максимально быть кратким, то правильный ООП - это когда твой, даже очень сложный и объемный проект, может с лёгкость прочитать и понять логику другой программист.
Интересная история ООП складывается с набирающим обороты новым языком Rust, который ещё называют убийцей C++. Дело в том, что в нем нет классического ООП с классами. Но парадигма ООП в нем реализуется с помощью структур, трейтов и обобщённого программирования. Возможно будущее за этим.
 
Nikolai Semko #:
правильный ООП - это когда твой, даже очень сложный и объемный проект, может с лёгкость прочитать и понять логику другой программист.

Пример такого кода в КБ есть? Или в штатной поставке терминала? Странно это все звучит, мягко говоря, истории про правильное и неправильное. Вроде, большие уже все.

 
Nikolai Semko #:
Ах, понимаю о чем Вы.
"обычный процедурный подход с использованием классов" - хорошая формулировка для моего текущего уровня программ.
Но есть жгучее желание реально освоить ООП. Как я понимаю, если максимально быть кратким, то правильный ООП - это когда твой, даже очень сложный и объемный проект, может с лёгкость прочитать и понять логику другой программист.
Интересная история ООП складывается с набирающим обороты новым языком Rust, который ещё называют убийцей C++. Дело в том, что в нем нет классического ООП с классами. Но парадигма ООП в нем реализуется с помощью структур, трейтов и обобщённого программирования. Возможно будущее за этим.

Будущее за функциональными языками, поскольку они дают принципиально более простую параллелизацию. Ещё там более осмысленное ООП, основанное на абстрактных типах. Rust, кстати, это и есть движение в этом направлении - он наполовину функциональный.

Так что ждём MQL6 похожим на Erlang)

 
fxsaber #:

Пример такого кода в КБ есть? Или в штатной поставке терминала? Странно это все звучит, мягко говоря, истории про правильное и неправильное. Вроде, большие уже все.

я понимаю Ваш антагонизм, сам в нем прибываю

Правильный, неправильный (говнокод, shit code) - это термин не для программистов-одиночек, как Вы или как я. 
Это термин для командной разработки сложных длительных проектов, в которых код каждого участника команды видят и юзают другие, где один программист может уйти, а на смену ему прийти новый, который он будет вынужден окунуться с головой в то, что было написано его предшественником.
Более того, для программистов одиночек этот термин тоже становится актуальным, когда этот программист возвращается к своему коду через несколько лет. 
Говнокод (неправильный) - это вовсе не означает неработающий или неэффективный код. Напротив, самые элегантные (в плане размера и производительности) коды часто оказываются говнокодистыми, так как такой код никто, кроме самого их творца, не может изменить (поддерживать). 
Я сам, когда есть выбор между высокопроизводительным говнокодом и "правильным" кодом, чаще выберу первое.

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

Здесь в КБ не видел 100% правильного кода (возможно потому, что не часто смотрю в чужой код), но в других языках видел (особенно Java очень ревностна к шаблонизации и стилю). Даже все творения Игоря Кима процедурные. 
Впрочем, кстати, у Карпутова видел вполне "правильный" код. 
Хотя, думаю, вполне законно можно назвать "правильным" кодом большинство встроенных библиотек от MQ. 
Например:

Наверное все же должен быть компромис, когда добротно говнокодить можно в своих строго private методах, а в остальном, все должно быть красиво и читаемо для стороннего наблюдателя.
"Правильное" ООП - это исскуство! Когда правильно все - кол-во классов, их имена, иерархия, их методы (защищенные,приватные и публичные), оформление (отступы) и комментарии.

 
Nikolai Semko #:

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

Более того, для программистов одиночек этот термин тоже становится актуальным, когда этот программист возвращается к своему коду через несколько лет.

Для меня в работах этого автора недостижимый мною ООП-стиль программирования, которым могу только восхищаться, но не в состоянии понять его.

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

Там очень хорошо выстроена архитектура, но моя низкая компетенция не позволяет ее увидеть в коде.


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

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


ЗЫ Trade-библиотека, как стиль, видится избыточной ООП-оберткой. Если ее заставить работать, станет "говнокодом", потому что количество торговых нюансов зашкаливает. Сейчас в ней нет ничего из этого (возможности наследования не помогут), к сожалению. И это одна из причин, почему она читается столь легко.

Stanislav Korotky
Stanislav Korotky
  • www.mql5.com
Профиль трейдера
 
Nikolai Semko #:

я понимаю Ваш антагонизм, сам в нем прибываю

Правильный, неправильный (говнокод, shit code) - это термин не для программистов-одиночек, как Вы или как я. 

Вы наверное пока не встречали настоящего говнокода… (без кавычек). 

 
Nikolai Semko #:
Ах, понимаю о чем Вы.

A100 #:

Да, поначалу тяжело преодолеть психологический барьер, но со временем и начинаешь "решать задачу, а не писать код"

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

Читабельность кода не причем, и на бейсике командами проекты делались, комменты и правильная организационная структура работы.

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

Процедурный вариант с классами, это Алгоритм, смотрим что можно разбить на функции, классы, что бы было удобней и реализация в коде.

Типовой, описательный подход ООП, для меня это сперва описание алгоритма как сущности, с логичной разбивкой по повторяемости, и потом его использования где только можно)

Не претендуя на истину, мое восприятие)

 

экспортируемая функция библиотеки Shuffle.ex5:

void ExportFunc (double v) export //аргумент по значению
{
  v = 3.1415926;
}

вызов функции из библиотеки функции с неправильно объявленным аргументом

#import "Shuffle.ex5"
   void ExportFunc (double &v); //аргумент по ссылке
#import

void OnStart()
{
   double result;
   ExportFunc (result);
   Print("Result: ", result);
}

вызовет зависание с последующим падением терминала.

обратная ситуация, когда в библиотеке аргумент по ссылке а вызываем по значению так же вызывает зависание терминала и падение, но в этом случае терминал всё же успевает вывести в лог экспертов следующее:

если успеть увидеть это, то можно понять причину проблемы, причем в логах Експерты не сохраняется записей о проблеме а в логах Журнал сохраняется следующее:

2023.09.09 11:11:08.989    Exception    C0000005 at 00007FF7310D062E read to FFFFFFFFFFFFFFFF


наверное нужна какая то защита в терминале от подобного некорректного вызова функций из библиотеки.

 

Кто-то заметил статистически разницу между тестами/оптимизаций на ssd и hdd?

Прогонял вчера часть советников, сделал тестов 80, разница в пользу hdd в основном по быстроте, иногда ssd NVMe но разницы выигрыша ssd NVMe очень минимальны, а hdd выигрывал с большей разницей.


Подскажите тогда в каких конкретно задачах ssd быстрее hdd чтобы можно было это отследить и мне.


P.S. 1 сферу нашёл теоретически и на практике увидел разницу но хочу и ваши варианты услышать независимые.

 
Во фрилансе, если было подано обращение в арбитраж, но работу таки удалось закрыть по договору (по нормальному, без функционала арбитража), счетчик "арбитражей" не сбрасывается. Можете это подправить?
1...337533763377337833793380338133823383338433853386338733883389...3768
Новый комментарий