Объявление переменных за циклом или внутри цикла? - страница 9

 
Vict:

Не въехал, это?

Сомневаюсь, что не знали.

Это понятно.

Я бы хотел что-то типа:

.......
int tipa_var;
// бла-бла-бла
..................
// кирдык, дальше она не нужна
удаляю tipa_var
 
Сергей Таболин:

Это понятно.

Я бы хотел что-то типа:

ну и расставляйте блоки, я всегда так делаю

int long_lining_var;
/*block*/ {
        int tipa_var;
        ...
} // кирдык, дальше она не нужна

Или две скобки сильно много )?

 
Vict:

ну и расставляйте блоки, я всегда так делаю

Или две скобки сильно много )?

Это не просто много... Это как Эверест на голову... )))))))))

Во что значит старость - я всегда думал, что "две скобки" должны открываться чем-то...

А что ими просто можно "локализовать" некоторый код - я в осадке....

Век живи и век учись! Слава ... мне ))) - я всегда рад  узнать то, чего не знал. 

А Вам спасибо! )))))))))

 
Igor Makanu:

1953-2008 отец

1953-2019 тесть

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

 
Alexey Viktorov:

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

ОК

тут дело не в словарном запасе, а в понимании, что вот Вы познакомились с вычислительной техникой, лет 30 + назад, и были простые языки программирования, Паскаль, Бейсик, Фортран, Ассемблер и ...

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

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

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

вот такой вот сказ ;)

 
Igor Makanu:

ОК

тут дело не в словарном запасе, а в понимании, что вот Вы познакомились с вычислительной техникой, лет 30 + назад, и были простые языки программирования, Паскаль, Бейсик, Фортран, Ассемблер и ...

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

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

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

вот такой вот сказ ;)

Со всем согласен, кроме одного. MQL язык сугубо ориентированный исключительно под своё ПО. Так зачем-же пытаться выжать из него то, чего ему не надо? Какой резон добиваться обработки каких-то вычислений как можно быстрей, если от тика до тика проходит очень много миллисекунд, а иногда и секунды.
 
Alexey Viktorov:
Так зачем-же пытаться выжать из него то, чего ему не надо? Какой резон добиваться обработки каких-то вычислений как можно быстрей, если от тика до тика проходит очень много миллисекунд, а иногда и секунды.

тут как бы человеческий фактор влияет, кто то делает работу как на конвейере - получил ТЗ (или свою идею), сделал дальше - получил ТЗ...

а кто то постоянно ищет способ сделать эту работу в 2 раза быстрее в следующий раз в свободное время

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

тут вроде только --у каждого свой путь?                )))

 
Igor Makanu:

тут как бы человеческий фактор влияет, кто то делает работу как на конвейере - получил ТЗ, сделал дальше - получил ТЗ...

а кто то постоянно ищет способ сделать эту работу в 2 раза быстрее в следующий раз в свободное время

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

тут вроде только --у каждого свой путь?                )))

В общем бесполезная дискуссия. Пока пытаешься выяснить чего-же заказчик имел ввиду, уходит столько времени, что можно несколько раз переписать весь код. Так и какая-же скорость в написании нужна? Сделать как понял, а потом выяснять что имел ввиду заказчик обращаясь в арбитраж?

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

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

 
Igor Makanu:

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

'tst.mq5' tst.mq5 1 1

possible use of uninitialized variable 'c' tst.mq5 16 10

possible use of uninitialized variable 'e' tst.mq5 20 17

code generated 1 1

0 error(s), 2 warning(s), 526 msec elapsed 1 3

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

 
Igor Makanu:

ОК

тут дело не в словарном запасе, а в понимании, что вот Вы познакомились с вычислительной техникой, лет 30 + назад, и были простые языки программирования, Паскаль, Бейсик, Фортран, Ассемблер и ...

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

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

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

вот такой вот сказ ;)

Когда я работал в найм, я в основном работал в области embedded, dsp и т.д., хотя могу бацать под десктоп и умел под БД, сейчас подзабыл. Так вот, на уровне embedded переход на ООП часто понижает быстродействие раза в полтора-два. Там ведь много работали с ассемблером, читаешь сгенеренный код на асме и видно, столько лишних телодвижений происходит. Но в наших реалиях это все мелочи. Вот куплю нормальную видяху, буду под OpenCL писать. Стану крутым ))