почти


это POD структура, все нормально.


это не POD структура и не агрегат, поскольку агрегатом является класс/структура/юнион, не имеющий нестатических private или protected членов (и еще куча всяких "если"), а POD структура является агрегатом, которая к тому же имеет еще несколько условий.
Инициализацию типа

можно применять к агрегатам (ну и соответственно к POD структурам), а default initialization работает только на POD структурах, т.е. к примеру если мы напишем деструктор

этот код уже инициализировать нулями не будет

зато этот - будет, так как структура все еще является агрегатом.


Добавлено через 1 минуту и 51 секунду

а тут поскольку MyClass не POD структура - default инициализация работать не будет, это значит что не будет работать совсем и оба члена останутся не инициализированными.

Добавлено через 8 минут и 20 секунд

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

Так это Вы знаете, что у Вас имеется, а нам даете кучу  Ваших размышлений и почти никакой сути задачи.



уже хоть что то..  


Вы имеете ввиду различие в наличие/отсутсвии конструктора ?

ну если проблема в читабельности, то ловите такой вариант :



Это сообщение отредактировал(а) mes - 30.4.2010, 17:32

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



Но без такого  

По крайней мере теперь понятно, что такое:



Можно использовать безопасно, но как сказал mes, он где-то видел, что этого делать не рекомендуется. А вот в случае с классами лучше такого вообще не делать, так как  редко когда будут соблюдены все условия, чтобы инициализация нулем работала.


Постоянно висящая переменная плюс новая функция - обертка. Переменная NullCallbackList будет так и так каждый раз копироваться на стек. Мой вариант мне уже не кажется таким уж плохим:



Наличие конструктора, как я понимаю, превращает MyClass в не POD тип.

пока не взяли адрес, ее можно считать (при включенной оптимизации) не существующей..  



Где функция обертка ? Unregister ? так она лишь для демонстрации, и применена на основании Ваших же примеров.


А когда передается параметром по умолчанию в стек разве не копируется ?     

Добавлено через 5 минут и 15 секунд

"Это " для читабельности.. для Вашей структуры вполне достаточно инициализации обычным способом

 если SetHandler ваша, то

хотя, имхо, с Null... именно для читабельности, а также для самоконтроля, лучше ..

Preambulus:
Прошу менять простить, если в ближайшие часы, я буду беспредельничать и говорить глупости. Пятница и я немного нетрезв.   

Ambulus:

Типу NULL я никогда не доверял. Но я не ошибся, ты имеешь ввиду такую конструкцию?


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


С этим я согласен. Только еще с тех времен, когда я писал на ассемблере, premature optimisation засело в голову.


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


Таким?



А в своем коде, если бы эта пара строк встречалась хотябы 3 раза, ты бы так и оставил или все-таки сделал класс?

SABROG

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

ну если плыть по этому руслу, то "оболочка" SetHandler  лишняя, MyClass может успешно справиться самостоятельно..

не совсем понял что вы имеете ввиду.

В моем случае те константы, которые я использую не менялись в течении 15 лет (так как часть кода я тырю из утилиты, которой именно столько и новых констант я не увидел в современной ОС с последними апдейтами). К тому же я использую некоторые "хаки", которые буквально через месяц возможно не будут работать (а у меня выбора нет, публичного API предоставляющего такие возможности у библиотеки нет). Но в целом твоя идея правильная. Просто разницы особой не будет:





P.S.: проплюсовал трёх человек по разным причинам. azesmcar - я тебе написал в комменте "за идеи", а сейчас подумал и решил, что скорее за "конкретику", очень уж мне понравились цитаты из стандарта.

Это сообщение отредактировал(а) SABROG - 30.4.2010, 20:36

mes

Понятно, ну тогда еще что-то такое

то у Вас 4 указателя, теперь 30.. я так понимаю эти 30 по очереди будут использовать как вышеупомянутые callback`и ?
тогда напрашивается решение сделать разрегистрацию тоже State`ом

Я смотрю вы там между собой чего-то уже проектировать начали   Я стараюсь не использовать синглтоны так как их много где критикуют, у меня просто выбора нет, я наследуюсь от синглтона библиотеки. Метод clear() мне точно не нужен, у меня прочный устойчивый каркас, так как ОС не меняет список состояний динамически, он статичен и зависит только от версии библиотеки.


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

Это сообщение отредактировал(а) SABROG - 30.4.2010, 20:46

ага.. главное что не будет лишнего "мазолевания" глаз. 

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


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