Помогите научиться программировать. - страница 3

Новый комментарий
 
Tio Nisla:
Хотел добавить ранее, что если функция somefunc() кроме возврата количества чего-то там, производит еще какие-то манипуляции, вычисляет торговые параметры например, то такое использование порождает трудно уловимые артефакты и может привести автора кода в ступор: "Шта??? Как это 4 раза??? O_o F$#@!!! Там же три раза должно быть? Почему мне советник лжет?". Вот это я и назвал "шиткодом", что эксперта возмутило до корней волос. Не стал заострять внимание, ибо очевидно, но вы сделали это за меня. Но не учли тот момент, что адресовать по индексу, который динамически рассчитывается без переинициализации массива - это нечто. В голых "сях" такое приводит обычно к GPF, в "плюсах" с умными указателями и массивами к исключению и его обработчику. В mql не понятно к чему.

А "трудноуловимые артефакты" это что? Это что-то из области религии? Сам придумал, сам уверовал?

 
Aleksandr Slavskii:

Господа, личности личностями, но давайте всё таки выясним истину. 

Я вот на примере  вижу, что    PositionsTotal() вызывается на каждую итерацию цикла.

Вы же Дмитрий, утверждаете, что компилятор делает по другому.  Мне не понятно. Объясните.

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

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

Что то не складывается у меня.

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

А компилятор - имелось в виду, что он оптимизирует код и происходит непосредственное обращение к переменной, а не через функцию:

int x;

for(;i<x;)

и

for(;i<F();)

int F(){return(x);}

Это хорошо заметно с функцией ArraySize(),  с ней не получается обнаружить разницу между вызовом функции и использованием переменной. Но с PositionsTotsl() этого нет, увы. 

Кстати, еще можно доколупаться, до объявления переменных внутри цикла, это тоже снижает скорость. Что не доколупались? Не в курсе? Хотя и тут можно поспорить, есть разница между 4 и 5.

 

А точно PositionsTotal() каждый раз запрашивает количество открытых позиций? Или может быть она оптимизируется и сохраняет значение в константу с меткой обновления и просто возвращает всегда одно число, если оно не изменяется?)

Наверняка есть какая-то внутренняя оптимизация этой функции. Разрабы же не дураки, что бы такую важную и потенциально затратную функцию делать на "и так сойдет".

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

Не нужно кидаться какашками.


Вот бы посмотреть исходный код PositionsTotal() чисто из академического интереса.


Ну да, так, если подумать, самое простое было бы сделать глобальную переменную терминала, которая бы хранила это значение. И возвращать только это значение. А обновлять его при открытии или закрытии позиций, обезопасив переменную, синхронизируя ее, что бы не дай бог чего не то туда бы записалось. 

Думаю, что примерно так и сделано.

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


А эстетически красив стиль кода или нет, каждый сам для себя решает)

 
Nikolay Mitrofanov:

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

Не нужно кидаться какашками.

Надеюсь это не ко мне было, так как Дмитрий для меня авторитет не сомненный.  Tio Nisla  тоже судя по всему не первый день кодит, но 


Учусь, поэтому спрашиваю. 

 

С PositionsTotal() есть сложность, она всегда должна возвращать правильное число, при этом менять свое значение сразу, как только меняется количество позиций. Поэтому она вряд ли когда будет такой же быстрой, как обращение просто к переменной или к функции ArraySize(). 

 
Aleksandr Slavskii:

...


Учусь, поэтому спрашиваю. 

Если учитесь не заморачивайтесь на эти мелочи вообще. Сконцентрируйтесь на умении переводить свой замысел в код (или некий мало определенный процесс в последовательность действий). А потом код можно причесать как угодно.

 
Dmitry Fedoseev:

Если учитесь не заморачивайтесь на эти мелочи вообще. Сконцентрируйтесь на умении переводить свой замысел в код (или некий мало определенный процесс в последовательность действий). А потом код можно причесать как угодно.

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

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

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

Совет ваш.. ну такое.. ИМХО


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

 
Nikolay Mitrofanov:

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

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

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

Совет ваш.. ну такое.. ИМХО


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

Для начинающих тем более - лучше хоть как-то, но решить задачу, а не застрять на уровне форумных терок типа "как здесь можно писать без const, а здесь без static и т.д. и т.п. или - о чувак, если ты задаешь такой вопрос, то тебе лучше вообще не приближаться к программированию". 

У меня недели не проходит, чтобы кто-то не прислал индикатор на исправление с каким-нибудь таким кодом типа такого: for(int i=0;i<Bars;i++). А вы здесь трёте проблемы, которые могут дать ускорение... ну процентов 30.

Даже эффективные эксперты (в смысле скорости их работы при тестирования) - это проблемы их алгоритма, который каждый раз заново рожается по ситуации, для каждой конкретной стратегии, а не проблема тонкостей синтаксиса. 

 
Dmitry Fedoseev:

Для начинающих тем более - лучше хоть как-то, но решить задачу, а не застрять на уровне форумных терок типа "как здесь можно писать без const, а здесь без static и т.д. и т.п. или - о чувак, если ты задаешь такой вопрос, то тебе лучше вообще не приближаться к программированию". 

У меня недели не проходит, чтобы кто-то не прислал индикатор на исправление с каким-нибудь таким кодом типа такого: for(int i=0;i<Bars;i++). А вы здесь трёте проблемы, которые могут дать ускорение... ну процентов 30.

Если начинающий программист спрашивает на форуме что-то, значит хочет узнать ответ, значит ему это интересно и нужно. Даже создал тему, что бы получить совет. 

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

"Хоть как-то" для любой деятельности - ужасный подход. 

Сначала разобраться, потом сделать со знанием - лучший.

 
Nikolay Mitrofanov:

Если начинающий программист спрашивает на форуме что-то, значит хочет узнать ответ, значит ему это интересно и нужно. Даже создал тему, что бы получить совет. 

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

"Хоть как-то" для любой деятельности - ужасный подход. 

Сначала разобраться, потом сделать со знанием - лучший.

Со знанием чего? Если этого алгоритма в природе не существует, а его надо придумать самостоятельно, и именно он определяет все.

12345678910...13
Новый комментарий