Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ME5 при компиляции выдает ошибку, на мой взгляд не обоснованную.
Хотелось бы, чтобы предопределенные enum вида ENUM_XXX фактически эквивалентные RadioButton нумеровались с 1, в то время как сейчас нумеруются по умолчанию, т.е. с 0. Вопрос не о том, чтобы менять умолчания а о том, чтобы вместо
было
Обоснование следующее - пример:
Когда я где то в коде анализирую значение request.type, то если оно равно 0, то нельзя понять то ли оно не было инициализировано, то ли оно было инициализировано
request.type = ORDER_TYPE_BUY;
Такая ситуация с большинством предопределенных enum вида ENUM_ XXX эквивалентных RadioButton и для корректной обработки при текущей ситуации необходимо неоправданное усложнение кода
А что мешает в качестве первого члена предопределённого перечисления прописать некий нейтральный идентификатор? Например:
И "нумерацию с нуля" сохраним, и неинициализированные переменные легко вычислим.
А что мешает в качестве первого члена предопределённого перечисления прописать некий нейтральный идентификатор? Например:
А если задуматься об остальных, кто уже использует исходный набор енумов? Это не говоря уже об недоуменном взгляде со стороны всего серверного комплекса.
Вообще вопрос неправильно поставлен. Разработчик не должен лениться и заставлять остальной мир подстраиваться под себя путем самоуничтожения этого самого мира.
Ну давайте задумаемся повторно, "об остальных". Для чего введены идентификаторы именованных констант? - Правильно, для того, чтобы пользоваться этими самыми идентификаторами. Причём, чтобы пользоваться этими идентификаторами, совершенно не обязательно знать, какие конкретные значения присвоены членам перечисления. Или Вы исходите из того, что грамотные программисты вместо использования идентификаторов выясняют умолчательные значения членов перечисления, и затем осуществляют проверки, исходя именно из этих умолчательных значений?
Т.е. воплотить само предложение не сложно, я так понимаю?
Да вообще-то автор этой темы не собирался рушить чужой мир за счёт своей лени. А всего лишь внёс конкретное предложение по улучшению. И объяснил, что нулевое значение оказывается перегруженным.
Хотелось бы ввести для имен элементов именованых enum область действия как минимум - класс,
Обоснование для Классов: нужно придумывать уникальное имя которое может неожиданно конфликтовать с библиотечным (в т.ч. сторонними) и/или предопределенным. Кроме того одновременно в нескольких классах можно было бы использовать схожие имена элементов перечислений SL, TP, PRICE и т.д. не боясь конфликтов.
Обоснование для функций: не критично, но заодно
Хотелось бы ввести для имен элементов именованых enum область действия
Обоснование для Классов: нужно придумывать уникальное имя которое может неожиданно конфликтовать с библиотечным и/или предопределенным. Кроме того одновременно в нескольких классах можно было бы использовать схожие имена элементов перечислений SL, TP, PRICE и т.д. не боясь конфликтов.
Обоснование для функций: не критично, но заодно
а как с этим в С++ ?
оттуда и ноги - парадокс, но только сейчас (когда есть ограничения) стал понимать зачем там это все было сделано :)
конечно можно и без этого - писать для всех классов - уникальное имя, но для больших программ, а тем более для библиотек, предназначенных для общего использования - не вариант
Попробуйте вот это (для "инициализации"):
WRONG_VALUE
Константа может неявно приводиться к типу любого перечисления.
-1