Про WinAPI плюсану. По нужде много лет пришлось программировать голый WinAPI и MFC. Теперь появилась возможность испоьзвоать что-то ещё и ОЧЕНЬ некомфотно переходить на QT. Иная идеология, всё по другому, всё непривычно. Лучше сразу изучать QT, чтобы не привыкать к плохому, а сразу учиться делать как белый человек.
*опускаться до WinAPI не стоит до тех пор, пока есть альтернативы
Евгений Шатунов, Нет. В стандарте указано А и Б. Если А и Б выполняется, то тривиальный. Если не выполняется, то не тривиальный. Оговорка в том, что выполнение А и Б не гарантирует, что тип тривиальный, хотя в приведённой ВАМИ ссылке указано, что у тривиального типа выполняется А и Б. Т.е. А и Б это необходимое, но не достаточное условие. Достаточность в стандарте не указана, потому что определяется логикой программы. Фактически, по стандарту, вообще не может существовать тривиального типа, содержащего указатель, потому что невозможно доказать его тривиальность, не имея всего кода приложения. Один и тот же класс может быть тривиальным и не тривиальным в зависимости от использующего класс кода.
Евгений Шатунов, Ещё раз повторю, чтобы вы точно поняли. Тривиальный конструктор копирования создаётся компилятором. Если вы сами его пишите, то это нетривиальный конструктор и объект перестаёт быть тривиальным. И ваш пример ассертит тогда.
Евгений Шатунов, Повторяю. А - содержит только тривиальные типы, Б - имеет тривиальный конструктор копирования. В вашем примере тривиальный конструктор копирования, поэтому А и Б выполняется. Напиши конструктор копирования и сработает ассерт.
Оговорка - не из стандарта. Сама оговорка: если объект не владеет адресуемым объектом, то он может быть тривиальным. т.е. допускает побайтовое копирование указателя без нарушения инварианта. Это настолько очевидные вещи, что я не понимаю, о чём мы говорим. Иначе класс прсто неправильно реализован. Правильную и неправильную реализацию формализовать нельзя (без явной аттрибуции), потмоу что и тот и тот код может быть верным в зависимости от "оговорок".
А и Б сложите вообще через & из той ссылки, которую вы дали. Сами пишите неправильныи пример, проверяющий не то, о чём мы говорим и используете это в качестве доказательной базы...
Вообще, я очень надеюсь, что в стандарте это помечено как UB.
Евгений Шатунов, По вашей ссылке написано, тип тривиальный, если А(скаляр) и Б(тривиальный коснтруктор копирования). Б не выполняется, значит - не тривиальный. Мне не с чем соглашаться.
В первом же сообщении я написал "и с кучей оговорок об использовании". Понимание происходящег и, что воообще там программируешь попадает под "оговорки".
Евгений Шатунов, Адресуемый указателем объект находится по указателю вне памяти "хозяина", а не по значению и имеет время жизни до удаления в деструкторе или до падения программы (если не реализован сборщик мусора). Всё, мне надоел этот офтоп. Если вам интересно, читайте стандарт. Мне не интересно пререкаться по всяким придиркам.
Евгений Шатунов, "и транслятор эту ошибку не обозначит. "
Именно поэтому я даже предположить не мог, что объект с указателем формально может считаться тривиальным. По вашей ссылке написано: "тривиальный конструктор копирования (и прочее тривиальное)", если конструктор не тривиальный, то весь объект более не тривиальный. Без привязки к указателям. Если объект владеет адресуемым объектом, то, в корректно реализованном объекте, будет нетривиальный конструктор копирования(присваивание) и деструктор. Исключением будет только "= delete" конструктор копирования и тривиальный деструктор с утечкой памяти. Так что я не понимаю, где вы видите формальное "разрешение" указателей в тривиальных объектах. Требование тривиального конструктора копирования делает объект с указателями (с владением) нетривиальным. По моему, это написано понятно и достаточно формализовано.
Евгений Шатунов, первая же строчка по вашей ссылке "T is TrivialType (that is, a scalar type, a trivially copyable class with a trivial default constructor". Если !"trivially copyable class", то это не TrivialType. Именно это я имел в виду под "по определению".
В любом случае, тривиальный или нет, но наличие указателя запрещает "сериализацию" бинарного дампа памяти всего объекта разом. Всё, я потерял интерес к этой теме.
Евгений Шатунов, Я не вижу противоречий. Если объект не владеет адресуемым объектом, то он может быть тривиальным, несмотря на наличие ссылки или указателя. Если он владеет объектом, то, по определению (из данной вами ссылки), не может быть тривиальным, потому что у него будет нетривиальный конструктор копирования и деструктор (не рассматриваем вариант с утечкой памяти).
Евгений Шатунов, Вы сами мне документ скинули про "тривиальные". Там английским по белому написано, что такое тривиальный тип. Сам по себе указатель - тривиальный тип, но класс, содержащий указатель (и владещющий адресуемым объектом) не является тривиальным типом.
Евгений Шатунов, тривиальные типы по определению не могут содержать ссылки или указатели. POD тоже. Нет конструктора копирования по умолчанию - не тривиальный. Пожалуй, только одно исключение могу придумать, если в POD структуре есть указатель, но объект им не владеет и не управляет временем жизни, тогда конструктор копирования по умолчанию можно использовать. Но я никогда не считал за POD объекты с указателями, поэтому даже как-то не подумал про это.
RADION NAZMIEV, Потому что тогда этот using переносится во все h/cpp файлы, куда был подключен этот хедер и куда были подключены хэдеры, вкулючающие этот хэдер и т.д. фактически, это равносильно отсутствию пространства имён.
using namespace можно спокойно использовать внутри функций (даже если они внутри хэдера) и внутри cpp файлов, но уже с опаской. Внутри хэдеров в 99,999% случаев using namespace испоьзовать нельзя.
Ярослав Иванов,
логовед - кто разбирается в логах
логовод - кто ведёт логи
логоводовед - кто разбирается в тех, кто ведёт логи
И не надо путать терминологию.
В том то и дело, что это не в приложении дело, а в "особенностях" Windows10. Приложения же безрамочные внешне. Однопиксельная рамка(иногда) и тень вокруг окна. Причём тень гораздо больше 4-8 пикселов. В предыдущих Виндоусах вокруг клиентской области была рамка окна для изменения размера. Как я понял, теперь её визуально нет, но пустое пространство есть, наведя на которое можно менять размер. Ширина как раз где-то 8 пикселов визуально (когда мышку подводишь и курсор меняется). Но SM_CXSIZEFRAME возвращает 4 пиксела. Приложение MFC, но это не имеет значения, т.к. такое же поведение и у Firefox и у Thounderbird. Остальные приложения или в полноэкране запускаю или не выравнены по краю экрана, так что не видел таких же проблем, но они 100% есть.
Слева и снизу к экрану нельзя прилипнуть, а сверху прилипает без зазора. Я бы добавил этот "минус" в код, но непонятно, какое конкретно брать значение и от чего оно зависит, раз SM_CXSIZEFRAME не совпадает.
*опускаться до WinAPI не стоит до тех пор, пока есть альтернативы