Эврика

[Алексей++]

почему то как-то всё неубедительно

по указателю можно узнать тип

- в рантайме ли? Всё равно же на этапе компиляции

от пустого класса могут быть порождены наследники, а могу и не быть.

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

можно сделать массив

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

Если можно ОБЪЯВИТЬ пустой класс, то можно ОПРЕДЕЛИТЬ и объект-представитель пустого класса. Эти объекты размещаются в памяти. Их размещение предполагает выделение объекту участка памяти с уникальным адресом, а это означает, что объекты пустого класса имеют ненулевой размер.

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

В общем, пока что я не понимаю, зачем так сделано

[Вад]

почему то как-то всё неубедительно

по указателю можно узнать тип

- в рантайме ли? Всё равно же на этапе компиляции

RTTI работает И уже давно используется в особо запущенных случаях диспетчеризации.

[Алексей++]

рассказывай, что за зверь и как применять ?

[Антон (LogRus)]

http://www.cplusplus.com/doc/tutorial/typecasting/

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

например:
http://www.cplusplus.com/reference/std/typeinfo/type_info/

[Алексей++]

dynamic_cast использовать пока не приходилось.  А ссылки не желают открываться...

[Антон (LogRus)]

странно, у меня открываются
а сам сайт www.cplusplus.com?

[Алексей++]

сайт тоже

[Антон (LogRus)]

что-то у тебя с инетом

вот чудесный блог
http://alenacpp.blogspot.com/2005/08/c.html

и вот еще
http://ru.wikipedia.org/wiki/RTTI
https://forum.shelek.ru/index.php/topic,1619.0.html

ну и погугли.

[Алексей++]

дома гляну

[Dimka]

Может это банальное выравнивание памяти под 4 байта? Тогда pragma pack нужен, если это имеет какое-то значение. Ты массив A попробуй посмотреть.

[Алексей++]

нет, выравнивание ни при чём, я и 1 и 0 даже пробовал )

С массивом A a1[N] штука такая : - в дампе идёт выравнивание по 4 байта (заполнено 0xcc) , а sizeof(a1) даёт N ))

[Алексей++]

нашёл ошибку в MFC-шном CRect (давно замечал проявление, но особо внимания не обращал, корректировал через +1 пару раз и забывал):

методы Width() и Height() возвращают значение на 1 меньше, чем нужно

[RXL]

Т.е.
width = (right - left)
так?

[Алексей++]

CDC::FillSolidRect и CDC::Ellipse (и, наверное, другие функции тоже) выводят в прямоугольник на единицу меньше по высоте и ширине тоже...

Собственно, апишные функции тоже. Придётся просто смириться и учитывать ))

Т.е.
width = (right - left)
так?

ага. В исходниках именно так.

Код:

ATLTYPES_INLINE int CRect::Width() const throw()
	{ return right - left; }
ATLTYPES_INLINE int CRect::Height() const throw()
	{ return bottom - top; }

 А должно быть right-left+1

[Алексей++]

пипец, как вспомню, сколько времени и нервов из-за этой хрени было в своё время потрачено ( Вылавливание пикселов как блох

Теперь хоть вооружён ))

[RXL]

А лечить чем будешь? Правкой заголовков?

[Алексей++]

Правкой заголовков?

Боже упаси, так низя делать Даже если это свои заголовки, которые где то уже применялись.
Буду учитывать на месте, не так уж часто используется. Обычно, когда делаю графику, контролирую под линзой в паинте, чтоб все размеры были такими, как задаю - собственно, так и обнаружил. Плюс-минус 1, да запомню парочку ситуаций

Думаю, мелкомягкие уже давно этот косяк заметили, но не подправили всё по той же причине - чтобы ни у кого ничего не упало. Разумно. А вот то, что изначально так сделали - за это руки надо оторвать )))

[Джон]

Ох, Лёха, Лёха, на сердце суматоха... Всё за привидениями охотишься?

Если мир не устроен так как тебе хочется, это ещё не значит что мир полон багов.

CRect::Width

    Calculates the width of CRect by subtracting the left value from the right value.

Remarks

    The width can be negative.

Иногда полезно заглядывать в справочник даже по таким пустяковым ф-ям.

[Джон]

Кстати в С# тоже самое. Вот пример работы кода:

Код:

        protected override void OnPaint(PaintEventArgs e)
        {
            base.OnPaint(e);
            Graphics gr = e.Graphics;
            Rectangle rc = new Rectangle(0, 0, 20, 20);
            int w = rc.Width; // w = 20
            DrawRect(gr, 0, 0, rc.Width, rc.Height);
        }

DrawRect - просто рисует прямоугольник разноцветными линиями. Я сделал скрин с результата и увеличил его в Photoshop:

[Алексей++]

Calculates the width of CRect by subtracting the left value from the right value.
 - само предложение - чушь )

опять скажешь "не будет оспаривать терминологию" ? Я под шириной пиксельного прямоугольника понимаю количество пикселов. Если L==0 и R==1 , то ширина == 2. А с отрицательными ширинами я не работаю, я их просто не отображаю.

Ладно, спорить особо не о чем, просто запомним и учтём

[Джон]

Лёш, ключевая фраза - "Я под шириной пиксельного прямоугольника понимаю ...". Но это неправильный подход.

Смотри, перед тобой некий механизм, например панель управления шаттлом. У тебя есть к нему мануал. Ты видишь кнопку "Сброс". И что? Полагаешься на "своё" понимание функциональности этой кнопки?

Могу сказать только одно, у разработчиков наверняка были свои причины сделать именно так и не иначе. Это они задокументировали в мануале - те сообщили тебе об этом своём решении. Я лично неоднократно сталкивался с подобными ситуациями, когда на первый взгляд логика функции совершенно корявая, но при детальном разборе оказывется, что не всё так просто и самое идеальное решение - пойти по пути наименьшего сопротивления.
Обрати внимание, у CRect ширина может быть отрицательной, что тоже задокументировано. И если уж ты сделал выбор использовать CRect, то надо ознакомиться с его свойствами и причудами, в крайнем случае отказаться от его использования.

[Алексей++]

ну так я и буду пользоваться с учётом )

[Джон]

Ну и правильно, так все делают. Но ругаться-то зачем?

[Алексей++]

а шоб не расслаблялись )))

[Алексей++]

Джон, вот ткни , где в документации описано следующее.

имеется контрол CMonthCalCtrl m_MCC . Когда тыкают курсором в новую дату, достаём эту дату:

Код:

COleDateTime t;
m_MCC.GetCurSel(t);
//t.m_dt==3.1478710920272e-306
//t.m_status==t.invalid

при этом наше сегодняшнее время в этом формате примерно равно 40140.(...)

вот так решил проблему:

Код:

	COleDateTime t;

	SYSTEMTIME sys;
	::memset(&sys,0,sizeof(sys));
	m_MCC.GetCurSel(&sys);

//и косяк тут же виден :
//sys.wHour=19312;
//sys.wMinute=237;
//sys.wSecond=61092;
//sys.wMilliseconds=18; //ну, тут спорно ))
//sys.<всё остальное в порядке>;

	sys.wHour=0;
	sys.wMinute=0;
	sys.wSecond=0;
	sys.wMilliseconds=0;
	t=sys;

[Джон]

Лёш, ну даже и не знаю куда тыкать? 

[Алексей++]

непосредственно в докУмент, где сиё безарбузие описано

[Джон]

Лёш, какое безобразие? О чём ты? Всё работает. Я ж тебе скрин поэтому привёл. С твоим кодом. В тултипе содержимое пременной t с полями m_dt и m_status. Или тебе проект выложить?

[Алексей++]

Джон, а, я не видел скрин из вапа, сорри.

Ещё забыл сказать, что я про VC6 говорил , в последующих могли исправить - я не попробовал

[Алексей++]

допустим, имеем чисто консольное приложение. Но хочется попользоваться АПИшными функциями.

Для этого надо подключить

Код:

// Файлы заголовков Windows:
#include <windows.h>

но после этого происходит страшная ругань, которая лечится так:

Код:

// Исключите редко используемые компоненты из заголовков Windows
#define WIN32_LEAN_AND_MEAN

// Файлы заголовков Windows:
#include <windows.h>

(подсмотрено в другом шаблоне проекта студии - проект для windows)