Вычеркнуть можешь, я никогда пальцы не растопыривал "какой я программист"...
А документацию прочесть мама не велит??? Специально для таких я вставил цитату из документации
Ясно, тогда прошу прощения, не заметил сразу. Удивительно конечно, как они успели втихаря это поменять, и ничего никому не сказали. Тогда не понятно, почему компилятор никак не реагирует на то, что выполняется недопустимая операция. Т.е. баг в любом случае имеет место
Значит если это обсуждалось между Вами и Alexey Viktorov, то даёт вам основания полагать, что это не баг? ) Причём этот человек сам заявляет, что его уровень знания программирования значительно ниже вашего. Т.е. его можно вычеркнуть из списка. Остаётесь только вы ) Обсудили сами с собой, значит это не баг )
Это баг. Такого не может быть в принципе, чтобы инициализация переменной была проигнорирована, и код продолжил выполняться, перескочив через неё. Это нонсенс. И порядок инициализации тут не имеет значения. Переменная либо инициализируется, либо компилятор выдаёт ошибку в этом месте. Третьего не дано. Иначе это не язык программирования, а чёрти что.
Если нахожу логическое (непротиворечивое) объяснение результату, то не вижу бага. Не считаю, что доказательство бага приемлемо, если результат не совпадает с C++. Это в C++ кто-то так подумал и сделал. А мог и не подумать так и, соответственно, не сделать. Поэтому лучше не ссылаться на что-то там, а основываться на какой-то своей внутренней концепции, как должно быть. И желательно, чтобы "свое" было, действительно, своим. А не результатом незаметного навязывания стереотипов "как надо" по мере набирания опыта программирования.
Мне не западло ошибаться. Учусь потихоньку на своих граблях.
Если нахожу логическое (непротиворечивое) объяснение результату, то не вижу бага. Не считаю, что доказательство бага приемлемо, если результат не совпадает с C++. Это в C++ кто-то так подумал и сделал. А мог и не подумать так и, соответственно, не сделать. Поэтому лучше не ссылаться на что-то там, а основываться на какой-то своей внутренней концепции, как должно быть. И желательно, чтобы "свое" было, действительно, своим. А не результатом незаметного навязывания стереотипов "как надо" по мере набирания опыта программирования.
Если своего объяснения нет то значит и ошибки нет. А если через год появится это объяснение и весьма убедительное - то тогда всем все переделывать??? В С++ там уже сто раз подумали почему так, а не иначе. И объяснение требуется если в MQL что то иначе устроено, чем в С++, а не наоборот
Статическая переменная может быть проинициализирована соответствующей ее типу константой или константным выражением, в отличие от простой локальной переменной, которая может быть проинициализирована любым выражением.
Но никак не функцией.
Тогда нужно запретить статические экземпляры классов - потому что они инициализируются функцией-конструктором
Ещё один баг в новых билдах:
Эх, как же тут всё сыро. Думал, обновлюсь таки на новые билды, а то на старых уже Маркет не принимает продукты. А тут баг на баге!
А у меня правильно показывает!
Вычеркнуть можешь, я никогда пальцы не растопыривал "какой я программист"...
А документацию прочесть мама не велит??? Специально для таких я вставил цитату из документации
А у меня правильно показывает!
Хм, а какой у вас билд? У меня 1653
Значит если это обсуждалось между Вами и Alexey Viktorov, то даёт вам основания полагать, что это не баг? ) Причём этот человек сам заявляет, что его уровень знания программирования значительно ниже вашего. Т.е. его можно вычеркнуть из списка. Остаётесь только вы ) Обсудили сами с собой, значит это не баг )
Это баг. Такого не может быть в принципе, чтобы инициализация переменной была проигнорирована, и код продолжил выполняться, перескочив через неё. Это нонсенс. И порядок инициализации тут не имеет значения. Переменная либо инициализируется, либо компилятор выдаёт ошибку в этом месте. Третьего не дано. Иначе это не язык программирования, а чёрти что.
Если нахожу логическое (непротиворечивое) объяснение результату, то не вижу бага. Не считаю, что доказательство бага приемлемо, если результат не совпадает с C++. Это в C++ кто-то так подумал и сделал. А мог и не подумать так и, соответственно, не сделать. Поэтому лучше не ссылаться на что-то там, а основываться на какой-то своей внутренней концепции, как должно быть. И желательно, чтобы "свое" было, действительно, своим. А не результатом незаметного навязывания стереотипов "как надо" по мере набирания опыта программирования.
Мне не западло ошибаться. Учусь потихоньку на своих граблях.
Хм, а какой у вас билд? У меня 1653
1653x64.
1653x64.
Странно, откуда тогда расхождение...
Пусть кто-то ещё проверит у себя.
Правда я там размерность массива не ту поставил, может это повлияло как-то (хотя не должно никак влиять).
Попробуйте вот с размерностью = 3
Обнаружил причину несоответствия. В режиме OPTIMIZE=0 ошибка есть, а с OPTIMIZE=1 нет. Я обычно всегда только OPTIMIZE=0 пользуюсь
Если нахожу логическое (непротиворечивое) объяснение результату, то не вижу бага. Не считаю, что доказательство бага приемлемо, если результат не совпадает с C++. Это в C++ кто-то так подумал и сделал. А мог и не подумать так и, соответственно, не сделать. Поэтому лучше не ссылаться на что-то там, а основываться на какой-то своей внутренней концепции, как должно быть. И желательно, чтобы "свое" было, действительно, своим. А не результатом незаметного навязывания стереотипов "как надо" по мере набирания опыта программирования.
Если своего объяснения нет то значит и ошибки нет. А если через год появится это объяснение и весьма убедительное - то тогда всем все переделывать??? В С++ там уже сто раз подумали почему так, а не иначе. И объяснение требуется если в MQL что то иначе устроено, чем в С++, а не наоборот
Но никак не функцией.
Тогда нужно запретить статические экземпляры классов - потому что они инициализируются функцией-конструктором