Russian Qt Forum

Нашел прелестную вещь, о которой не знал  :D
Как думаете, что вылетит в дебаг?  ;D

C
class Foo
{
public:
    Foo() { qDebug() << "Foo()"; }
    void test() { qDebug() << "AHAHAHA";}
    ~Foo() { qDebug() << "~Foo";}
};
 
int main(int argc, char *argv[])
{
    Foo *foo = (Foo*)28;
    foo->test();
    return 0;
}

Даже так работает. Ломает мое представление о мире.

C++ (Qt)
Foo *foo;
    foo->test();

Я пару раз так тестировал. Ничего особенного, просто не создавайте переменных и ничего не вылетит :)

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

Да это из серии "вопросы на собеседовании по С++"  ;D
Как вызвать не статическую функцию без создания экземпляра класса?

P.S. Сам не знаю, Верес  ;D

Можешь ещё жутче поизгаляться. Можно написать полностью консольное приложение на пустом указателе. Главное я уже написал - не создавать переменных :)

PS лично у меня пустота на месте знаний - как собственно работает вызов функции класса. Нигде этот момент не акцентируется :)

Нужно вспомнить, что из себя представляет метод класса и как ему передаётся this. Ничего удивительного нет. Попробуйте в методе test распечатывать значение this и все станет понятно. :)

так что запишешь в Foo *foo, то и распечатает) Ставишь 0 - дает 0  ??? Понятнее не стало  ;D

Метод класса это обычная функция, которой первым параметром передаётся адрес размещения объекта (this). Ваша функция ничего ужасного с объектом не делает, вот если вы по адресу писать начнете, тогда начнутся чудеса.

Теперь пустота заполнилась :) Благодарю.

Правильно я говорил что программирование - на 90% обман :)

to OKTA: собственно не создавая переменные в классе, мы его не трогаем получается. Так что обращения по невалидному нет. :)

Это не совсем так.

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

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

Вообще, на плюсах есть четкое разделение на так называемые "сишные структуры", они же - POD-типы.
И на "полноценные классы".

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

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

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

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

Можно сократить до одного предложения.

Использовать сейчас можно, но никто не даёт гарантий. Собственно как и любую возможность с++ :)

Не представляю где это можно использовать. :)

Ну лично я использовал когда строил архитектуру. Можно наплодить десятки и сотни классов без инициализации и проверить собственно архитектурку. И нет нужды описывать всё.

::)
Не обижайтесь, но вы написали просто набор слов. :)
Что такое "десятки и сотни классов без инициализации" и как с помощью этого можно проверить "архитектурку"?

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

Никто не дает никаких гарантий на возможности, которые либо вообще не были описаны в стандарте, либо явно там обозначены, как UB.

Ситуация приведенная в сабже описана в стандарте, как UB.

C++ (Qt)
class MyClass
{
public:
    QString toString() const
    {
        if (this)
            return field_;
        else
            return QString();
    }
private:
    QString field_;
};
 

Мдамс. Берётся в уме класс с множеством сложных полей. С него лепим заглушку из методов, возвращающих одно и то же. И вуаля у нас N-ное количество классов, на которых можно испытывать что угодно.

А если делать стандартно, то нужно написать такой же класс заглушку, инициализировать все его поля и создавать с помощью new.

Ну вообще это боян. Ну да ладно...

1. проверка гарантированно сломается, если использовать множественное наследование.

2. this не может быть нулевым, иначе это - UB.
Компилятор закладывается на то, что программист не дибил, а значит он не сделает UB, а значит this никогда нулем не будет, а значит на нуль проверять не обязательно - и выпиливает эту проверку.

Поэтому, код сломается сразу же, как только вы попытаетесь собрать в режиме оптимизации.

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

Которые не нужны. Сама по себе идея налепить множество классов сильно смахивает на "архитектуру ради архитектуры", ну или ооп головного мозга.


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

И только после того, как был выработан дизайн, пишется реализация.

На этом кстати, базируется техника программирования TDD.

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

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

Это конечно моё ИМХО.

Вот именно что имхо :)

И немного лирики напоследок - в любых словах есть смысл. И если человек хочет - он его увидит :)

Если бы он был, то вы уже давно набросали бы примерчик на c++ с демонстрацией того, как это удобно использовать, но пока только поток слов. :)

И когда такой класс мне сможет пригодиться? :)

И как отработает этот класс в подобном случае:

C++ (Qt)
    Foo *foo = (Foo*)28;
    foo->test();

Падением программы? :) если, вообще, такое скомпилируется :)

Скомпилируется даже с нулевым указателем, но да, вылетит)

Ну что ж поделать, компилятор, по умолчанию, уверен, что программист имеет прямые руки и они из правильного места она растут, поэтому и не ругается на такое приведение :)

И тихо смеется, видя, как программист отстреливает себе ногу  ;D

В свете выше сказанного растолкуйте корявость сего хака

C++ (Qt)
bool QUApplication::notify( QObject* o, QEvent* e )
{
	...
	case QEvent::KeyPress:
		if( w->keyboardGrabber() == w )
		{
			class _QWidgetP_ : public QWidget
			{
			public:
				_QWidgetP_( QWidget* p = 0, Qt::WindowFlags f = 0 ) : QWidget( p, f ) {}
				bool event( QEvent* e )
				{
					return QWidget::event( e );
				}
			};
			return ( (_QWidgetP_*) w )->event( e );
		}
	...
}
 

PS. Сей хак понадобился, чтобы обойти Qt-ишный баг, который позволяет отрабатывать QShortcut-ам при клавиатурном грабе.
PPS. QWidget::event() - protected.

Так проще:

C++ (Qt)
bool QUApplication::notify( QObject* o, QEvent* e )
{
	...
	case QEvent::KeyPress:
		if( QWidget::keyboardGrabber() == w )   // keyboardGrabber статический же. :)
		{
			return w->QWidget::event( e );
		}
	...
}
 

А пояснить зачем?

Архитектурку же проверить. :)

Конечно было проще, если бы не

C++ (Qt)
virtual bool QWidget::event(QEvent*)» is protected

А в QObject он паблик, я туда заглянул.

Old - знать и не говорить, это подло по отношению к другим :D То, что мои слова до вашего разума не добились - не повод ехидничать, хотяя... Ваше право.

У нас прямо форум подлецов... 90% знают и не говорят... :)
Там три строчки кода, может вам стоит с этим разобраться?

Вырванных из контекста :) Мб и стоит, я не знаю. Я вас собственно и спрашиваю, желая узнать :)

© Вика

А там не сказано что делать, если у процессора нет регистра ecx? :)

Я думаю, регистры есть примерно во всех архитектурах. Поинт в том, что врядли this передаётся через стэк - это медленно.

ЗЫ: вам, кстати, должно быть известно, что архитектур, кроме х86, не существует http://msdn.microsoft.com/en-us/library/ek8tkfbw(v=vs.71).aspx :)

Да не принципиально как он передаётся (это все отдается на откуп abi конкретной платформы), главное что он передаётся в функцию в качестве параметра.
Я простым языком хотел объяснить, что метод это обычная функция с дополнительным параметром. :)

P.S. Я очень часто пишу на форум с телефона, поэтому подробно расписывать у меня терпения не хватает. :)

Как в python, только не так открыто для программиста :)

Ну так что, кто-нибудь что-либо скажет насчёт этого (http://www.prog.org.ru/index.php?topic=27677.msg201421#msg201421)?

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

Вы пишите так, словно можно закладываться на работоспособность следующего кода:
http://rextester.com/RSDW27510




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

Однако, несмотря на то, что представленный код работает в большинстве случаев - он является UB.
И компилятор, который мне пришлось обмануть, что бы выполнить каст, не зря запрещает такой каст.

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

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

Но при этом компилятор закладывается на то, что программист не делает UB.
А значит он не делает преобразований типов, которые запрещено делать.

А значит можно изменить вызов так, что бы параметры прошли через регистры, или ещё каким то особым образом.


А это означает, что "хакнутый" указатель на свободную функцию теоретически может отказать в любой момент.


Компилятор запрещает данные касты, специально, что бы пользователи не могли закладываться на конкретную стратегию вызова.
Это поведение описывается в стандарте как unspecified behaviour.

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

Это UB

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

(примечание: вроде бы не гарантируется что это всегда будет именно так)

Код, который наглядно иллюстрирует возможные проблемы:
http://ideone.com/KPiDmR
http://ideone.com/z0bAgC

Вовсе нет. :)
Посмотрите на начало обсуждения, я постарался просто объяснить, почему код ТС не падает.
Я не собирался вдаваться в подробные объяснения всех механизмов для всех возможных ABI. Это я оставил для самостоятельного изучения ТС.

Что-то я читал, читал твой пример, _Bers и так и не понял, что ты хотел им показать. Я так понял, что как раз фишку, что передается адрес объекта?  ???

up или че там говорят обычно?  ;D

Единственное что могу сказать - сам делал практически так же  :)

Др пример

Это не работает если тело CalcColor в С (не cpp) файле. Когда ф-ция вызывается из cpp, она рассчитывает на

C++ (Qt)
void CalcColor( ARGB & c );

и подает "с" как аргумент. Правда варнинг есть, что-то типа "inconsistent linkage" (точно не помню)

Непонятно удивление на 4 страницах :) Самые начальные познания в ассемблере снимают все вопросы

Тупо не преподавали этот материал, а на практике он не пригождается.

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

Упрощенный пример

C++ (Qt)
int DoSomething( float p0, float p1, int num ); 

Полагать что действительно на стек будет подаваться num, затем p1 и p2 - ну так думают тыкающие мальчики :) Реально может быть что угодно, напр

num в регистре ecx
p0 и p1 в регистрах FP2 и FP3

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

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

Замер производительности команд/функций вполне заменяет знание ассемблера, увы.