С++ статик поля

[m_ax]

И содержательная часть (ф-ционал) как-то заслонена "синтаксическим сахаром". По одному ищем с ключом, по другому перебором - неоднообразно. Заряжали бы уж сразу boost::bitmap.

Ну здесь да, если логика этого класса подразумевает полную симметрию (хотя я не вижу зачем она здесь нужна и метод convertToStatus в частности), то bimap более уместен.
Однако он не имеет конструктора    c initializer_list и поэтому так написать не получится

Код

C++ (Qt)
typedef boost::bimap<Status, std::string> hash_type;
 
    static const hash_type & get_hash()
    {
#define X(a, b) {a, b},
        static hash_type hash = { STATUS }; // так не прокатит..
#undef X
 

Хотя, с другой стороны, есть boost::assign и тогда можно так:

Код

C++ (Qt)
typedef boost::bimap<Status, std::string> hash_type;
 
    static const hash_type & get_hash()
    {
#define X(a, b) (a, b)
        static hash_type hash = boost::assign::list_of<hash_type::relation> STATUS;
#undef X
        return hash;
    }
 

[AzazelloAV]

Ну здесь да, если логика этого класса подразумевает полную симметрию (хотя я не вижу зачем она здесь нужна и метод convertToStatus в частности), то bimap более уместен.

Все наоборот. Основная работа класса - это статус. Статус получаем от строки. А статус в строку - это для вспомогательных вещей, ну к примеру запихнуть в модель, чтобы видеть значения и не придумывать в модели свои значния. На практике класс может быть односторонним, а не зеркальным.

[m_ax]

Все наоборот. Основная работа класса - это статус.

А, ну тогда понятно..

[Igors]

Все наоборот. Основная работа класса - это статус. Статус получаем от строки. А статус в строку - это для вспомогательных вещей, ну к примеру запихнуть в модель, чтобы видеть значения и не придумывать в модели свои значния. На практике класс может быть односторонним, а не зеркальным.

Непонятное деление на "основной" и нет. С точки зрения кода затраты те же. Помню мне потребовалось: если строка невалидна (для нее нет статуса), то выдать месягу "'LaLa' is not a valid name\nThe valid names are <list>". Конечно написать это минута. Но вот где разместить этот код - не так уж просто решить Как бы Вы поступили?

[Old]

Как бы Вы поступили?

Не позволил пользователю вводить невалидные строки. Для этого есть куча способов от форматов и валидаторов и до QComboBoxов и комплитеров...

[AzazelloAV]

Непонятное деление на "основной" и нет. С точки зрения кода затраты те же. Помню мне потребовалось: если строка невалидна (для нее нет статуса), то выдать месягу "'LaLa' is not a valid name\nThe valid names are <list>". Конечно написать это минута. Но вот где разместить этот код - не так уж просто решить Как бы Вы поступили?

Я люблю исключения, поэтому мне проще.

А про основной всё прозрачно. Можно вообще отказаться от перечисления и хранить только строку. Тогда мы теряем гибкость в компиле тайм, нам прийдётся использовать строки для изменения, а так как мы не хотим использовать строки (можем же ошибиться), то строка должна быть определена в одном месте. А раз в одном месте, значит определяем её константами, т.е. прийдём к  дефайнам. По сравнению с дефайнами, константы енум мне лучше выглядят. Ещё есть вариант использовать хеш строкИ, как константу, тоже можно придумать элегатное решение.

А насчет как бы я поступил, точнее как я делаю.
Начнем с того, что объекты имеют атрибуты, которые обязательны и не обязательны + некоторые имеют дефолтные значение.
Итог - другого выхода нет, как решить, что объект не атомарен. Т.е. должен иметь метод(ы) (save/load, check, post/cancel, open/close или какой другой), который его переводит в стабильное состояние либо говорит, что он не валидный (невалидность тоже можно рассматривать как стабильное состояние). Не данный класс, который мы обсуждаем, а класс, который содержит его.

Не позволил пользователю вводить невалидные строки. Для этого есть куча способов от форматов и валидаторов и до QComboBoxов и комплитеров...

На самом деле таких способов не много. Если брать гуи, то валидация с комбобоксом может прокатить, но мы же пишем модульный код, правильно. С чего это мой модуль обработки данных должен быть на 100% уверен что ему правильные данные передадут?
А если данные с файла читаем? Даже это наш записанный файл, где увереность что не поменялся битик. Тут офис иногда падает из за битых файлов, я уже не говорю про взлом.

Валидация отдельно - ну это как то даже странно. Кто как не лучше знает про данные, как класс, который работает с этими данными, не ему ли валидацию делать. Или у нас будет два разных модуля, один проверяет валидность, второй уже разбирает данные. Возможно, вы имели ввиду валидацию на стороне клиента(не про клиент-серверные технологии говорится). Да, такая валидация существует, но лишь для удобства пользователя, а на стороне обработких данных все равно проверяется.

Яркий пример разрозненной валидации - IDE. Он делает парсинг файла отдельно от компилятора (подсветка синтаксиса и ошибок). Смогли бы договориться по айпи, сколько себе бы сэкономили и на новый уровень иде вышла бы.

[Old]

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

А как модульный код может помешать валидировать вводимые пользователем данные?

[AzazelloAV]

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

А как модульный код может помешать валидировать вводимые пользователем данные?

Я же выше отписался.
Повторюсь. . Да, такая валидация существует, но лишь для удобства пользователя, а на стороне обработких данных все равно проверяется.

P.S.
Если бы вы писали оболочку для компакта (ауторан который, давайте установим), тогда любой бы не парился и валидация гуи хватило бы

[Old]

Повторюсь. . Да, такая валидация существует, но лишь для удобства пользователя, а на стороне обработких данных все равно проверяется.

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

А проверка входных данных - это несколько другое. Если есть вариант, что могут прийти не валидные данные, то их придется проверять всегда.

[AzazelloAV]

Повторюсь. . Да, такая валидация существует, но лишь для удобства пользователя, а на стороне обработких данных все равно проверяется.

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

А проверка входных данных - это несколько другое. Если есть вариант, что могут прийти не валидные данные, то их придется проверять всегда.

Так, видно ник так влияет, какая то вода уже пошла.
Вдумайтесь в фразу: Скорее это не валидация, а способ не дать пользователю ввести не валидные данные.

Да мы воду в ступе с вами толчём, как на первом курсе. Все же знают, что дикое количесво кода это тупая проверка данные. Надоедливая, с тестированием, которая может забирать 70% производительности. Зачем нам говорить о свершившихся фактах, которые уже устоялись и поднимать их на поверхность, это же должно быть "из под коробки" для программиста.

[Old]

Так, видно ник так влияет, какая то вода уже пошла.
Вдумайтесь в фразу: Скорее это не валидация, а способ не дать пользователю ввести не валидные данные.

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

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

Ну не знаю, я с вами никакую воду не толку. Я написал свое мнение на пост Igors.

[AzazelloAV]

Так, видно ник так влияет, какая то вода уже пошла.
Вдумайтесь в фразу: Скорее это не валидация, а способ не дать пользователю ввести не валидные данные.

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

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

Или работая с БД, что это поле обязательно никак не пересекается с проверкой БД на присутствие значений. Это только для удобства, только. Никак больше. Удобства пользователя. Ну ещё для экономии траффика.

Тут я привёл клиент-серверные технологии лишь потому, что они понятны. Мы говорим про разные уровни. Есть валидация на стороне клиента ил нету, обработке данных это наплевать. Он должен сделать валидацию. Поэтому, рассматривать ваш вариант в данном контексте просто не уместно.

[Old]

Это вам так кажется, что он никак не пересекается.

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

[AzazelloAV]

Это вам так кажется, что он никак не пересекается.

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

Совершенно верно. Но можем мы сделать так? Неа. Отбросим клиент-сервернные технологии, что результат может быть подделан по пути, мы их лишь для примера привели. Но у нас два разных класса, один на клиенте, второй на сервере. А как мы можем делегировать валидацию на другой класс? Никак, все равно проверка должна быть только в текущем, который работает с данными. Как обезопасить этот путь от клиента к серверу. Только создать жёсткие правила, в которых легко ошибиться.

Есть приверы валидации на внешнем классе? конечно. Возьмём к приверу Qt приват классы. Верхний класс может гарантировать, что данные прийдут валидные, он их проверит на своем уровне. Но это настолько специфичный частный пример, с такими ограничениями, что его даже рассматривать не стоит.

[Old]

Понимаете, я в своем сообщении комментировал конкретный пост про GUI.
И все выше сказанное мной относиться к GUI.

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