Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У меня было множество ситуаций объявления стат. полей в классах, инициализируемых на глобальном уровне (до OnInit), при условии повторного объявления стат. поля сразу после описания класса, и до объявления глобальной переменной его экземпляра, никогда не возникало проблем с инициализацией статик-поля (поскольку в этом случае она считается глобальной и инициализируется до экземпляра класса как я понимаю). То есть нужно только отказаться от объявления статик-переменных внутри методов и функций и никакой проблемы нет.
Да, верно, в обычных классах инициализируется сразу. А вот в шаблонных - нет:
Можно не полностью отказаться от объявления статик-переменных внутри методов и функций, а хотя-бы не инициализировать другие статик-переменные теми методами или функциями в которых присутствуют статик-переменные.
В этом примере сначала будет инициализирована переменная static int b но пока ещё не инициализирована переменная static int f находящаяся внутри функции int a(int n) и в результате получим белиберду.Кстати да, это же ещё один баг. Т.е. помимо раздельной инициализации статических/глобальных перемеренных, оно ещё и сами статические переменные инициализирует в неправильном порядке. И вот это уже даже посерьёзней проблема. Вот вы говорите "не инициализировать другие статик-переменные теми методами или функциями в которых присутствуют статик-переменные". Как вы это соблюдать в реальности предлагаете? Каждая функция независима, существует сама по себе. У неё своя реализация, которая может меняться. Раньше допустим в ней не было статик-переменной, а потом вы решили добавить. И значит где-то может что-то неправильно начать работать, ибо там закладывалось на то, что в функции не будет статической переменной. И как вы это всё контролировать собираетесь.
Кстати да, это же ещё один баг. Т.е. помимо раздельной инициализации статических/глобальных перемеренных, оно ещё и сами статические переменные инициализирует в неправильном порядке. И вот это уже даже посерьёзней проблема. Вот вы говорите "не инициализировать другие статик-переменные теми методами или функциями в которых присутствуют статик-переменные". Как вы это соблюдать в реальности предлагаете? Каждая функция независима, существует сама по себе. У неё своя реализация, которая может меняться. Раньше допустим в ней не было статик-переменной, а потом вы решили добавить. И значит где-то может что-то неправильно начать работать, ибо там закладывалось на то, что в функции не будет статической переменной. И как вы это всё контролировать собираетесь.
Да никаких проблем-то в этом нет. Достаточно отказаться от инициализации переменных функциями и всё встанет на свои мета.
Так будет работать на-ура. В чём проблема??? В одной строке?Так будет работать на-ура. В чём проблема??? В одной строке?
Так а вы понимаете, что здесь логика другая получилась? Зачем тогда вообще объявлять b статической, если вы на каждом вызове ей присваиваете значение?
Согласен. В спешке чуток начудил. Но ведь переменной b может быть присвоено значение при каком-то условии и вместо 9 в функцию могут передаваться значения в зависимости от условия.
А вот в вашем примере переменная 'а' обязательно должна быть инициализирована на глобальном уровне?
В скрипте нет другого варианта, а в советнике можно объявить переменную на глобальном уровне, а инициализировать её в OnInit()
Достаточно понимать и соблюдать последовательность инициализации. Сначала переменные глобального уровня, затем статические и потом локальные по мере их появления в коде.
Именно этот пример и нарушает рекомендацию документации о недопущении инициализации переменных функциями. Разработчикам было проще написать такое предупреждение, чем объяснять где можно, а где нельзя.
Уберите static из своего примера и получите желаемый результат.
А вот в вашем примере переменная 'а' обязательно должна быть инициализирована на глобальном уровне?
Необязательно, но мне так удобней. Если же это константа (а в глобальной видимости объявляются в основном константы, если код грамотный), то здесь и выбора другого нет.
В скрипте нет другого варианта, а в советнике можно объявить переменную на глобальном уровне, а инициализировать её в OnInit()
Достаточно понимать и соблюдать последовательность инициализации. Сначала переменные глобального уровня, затем статические и потом локальные по мере их появления в коде.
Именно этот пример и нарушает рекомендацию документации о недопущении инициализации переменных функциями. Разработчикам было проще написать такое предупреждение, чем объяснять где можно, а где нельзя.
Уберите static из своего примера и получите желаемый результат.
Необязательно, но мне так удобней. Если же это константа (а в глобальной видимости объявляются в основном константы, если код грамотный), то здесь и выбора другого нет.
На всё, что выделенно жёлтым, у меня один вопрос: ЗАЧЕМ? Я уже нашёл, как решить проблему.Вы нашли способ, как ее создать.
Да, верно, в обычных классах инициализируется сразу. А вот в шаблонных - нет:
У Вас происходит попытка использовать статик-поле класса на этапе инициализации до того, как был создан хотя бы 1 экземпляр этого класса. На мой взгляд, это извращение... Вот так все работает нормально:
Принцип инкапсуляции вообще предполагает, что такие поля должны быть скрытыми, а не общедоступными.