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

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

Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.

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

Что скажут знатоки ?

SJA>Коллега утверждает, что в бинарнике нет никаких сведений о классе, и такое понятие как класс существует только на этапе компиляции.
SJA>Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.
SJA>Коллега в ответ на мои доказательства начинает бредить, и предоставляет какие-то мутные контрдоказательства, например, что RTTI-шная информация вставляеться "насильно"... и поэтому не являеться описанием класса Что значит насильно я не смог выяснить...

А о чем спор то? Сведения о классе есть, вы сами это написали — например RTTI.
А вот в чем смысл "понятия класса в бинарнике" ?

Здравствуйте, Sergey J. A.!

Уважаемые коллеги!
Каждый из Вас прав и не прав по-своему.
Сразу оговорюсь что всё нижеследующее относиться к С++.
Конечно же в готовом модуле нет того описания класса, какое имеет возможность лицезреть компилятор.
Дело в том, что в программе "физически" нет такой сущности как класс, если это специально не делается при помощи дополнительных объектов, несущих в себе необходимую информацию. Но эта информация опять же специфическая.
Однако, в некоторых случаях в бинарном модуле "следы" класса присутствуют. Например, в DLL для экспортированных классов, в именах методов присутствует имя соответствующего класса. То есть мы можем видеть открытый интерфейс класса.

По поводу RTTI. Во-первых, это вообще вещь не стандартная и отключаемая. А во-вторых описания класса она не содержит, только имя класса и относительный порядок в списке типов (который может быть различным для разных запусков приложений).

Здравствуйте, maq, Вы писали:

SJA>>Коллега утверждает, что в бинарнике нет никаких сведений о классе, и такое понятие как класс существует только на этапе компиляции.
SJA>>Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.
SJA>>Коллега в ответ на мои доказательства начинает бредить, и предоставляет какие-то мутные контрдоказательства, например, что RTTI-шная информация вставляеться "насильно"... и поэтому не являеться описанием класса Что значит насильно я не смог выяснить...

maq>А о чем спор то? Сведения о классе есть, вы сами это написали — например RTTI.

Дык не могу доказать. Объяснял, рисовал схемы, писал тестовыую программу, показывал ассемблер.... Не, говорит. Не верю. Прям Станиславский.

maq>А вот в чем смысл "понятия класса в бинарнике" ?

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

Здравствуйте, addword, Вы писали:

A>Здравствуйте, Sergey J. A.!

A>Уважаемые коллеги!
A>Каждый из Вас прав и не прав по-своему.
A>Сразу оговорюсь что всё нижеследующее относиться к С++.
A>Конечно же в готовом модуле нет того описания класса, какое имеет возможность лицезреть компилятор.
A>Дело в том, что в программе "физически" нет такой сущности как класс, если это специально не делается при помощи дополнительных объектов, несущих в себе необходимую информацию. Но эта информация опять же специфическая.

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

A>Однако, в некоторых случаях в бинарном модуле "следы" класса присутствуют. Например, в DLL для экспортированных классов, в именах методов присутствует имя соответствующего класса. То есть мы можем видеть открытый интерфейс класса.

A>По поводу RTTI. Во-первых, это вообще вещь не стандартная и отключаемая.

Что значит не стандартная ? Я что-то упустил ? Неужели dynamic_cast не упоминаеться в стандарте ? И typeid() ???

A> А во-вторых описания класса она не
содержит, только имя класса и относительный порядок в списке типов (который может быть различным для разных запусков приложений).

Ага. Значит имя класса не относиться к описанию класса ? Я считаю что описание класса в бинарнике это структура, которая описывает некоторые свойства. Не обязательно всё, хватит и имени, что бы уже считать это описанием класса.

maq>>А о чем спор то? Сведения о классе есть, вы сами это написали — например RTTI.

SJA>Дык не могу доказать. Объяснял, рисовал схемы, писал тестовыую программу, показывал ассемблер.... Не, говорит. Не верю. Прям Станиславский.

maq>>А вот в чем смысл "понятия класса в бинарнике" ?

SJA>Изначально коллега выразился, что в экзешнике нет никакого понятия (упоминания) об классе.
Понятия наверно все таки нет, а упоминание есть

SJA>И соответственно на уровне бинарных кодов никогда невозможно понять, к какому классу относиться ф-ия (а точнее какой тип имеет this во время вызова ф-ии).

А вот тут он не прав, понять очень даже можно, но: нет взаимооднозначного соответствия между
исходным кодом и конечным, это одностороняя функция. Т.е. конкретному исходному коду соответствует,
конкретный машинный (для конкретного компилятора и конфигурации), но один и тот же машинный можно получить
разным исходным кодом.

Например, такой пример: хитрый компилятор может объеденить код некоторых методов для разных
классов, потому что физически он одинаковый и оперирует одинаковыми физическими сущностями.

Здравствуйте, maq, Вы писали:

maq>>>А о чем спор то? Сведения о классе есть, вы сами это написали — например RTTI.

SJA>>Дык не могу доказать. Объяснял, рисовал схемы, писал тестовыую программу, показывал ассемблер.... Не, говорит. Не верю. Прям Станиславский.

maq>>>А вот в чем смысл "понятия класса в бинарнике" ?

SJA>>Изначально коллега выразился, что в экзешнике нет никакого понятия (упоминания) об классе.
maq>Понятия наверно все таки нет, а упоминание есть

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

Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, addword, Вы писали:

A>>Здравствуйте, Sergey J. A.!

A>>Уважаемые коллеги!
A>>Каждый из Вас прав и не прав по-своему.
A>>Сразу оговорюсь что всё нижеследующее относиться к С++.
A>>Конечно же в готовом модуле нет того описания класса, какое имеет возможность лицезреть компилятор.
A>>Дело в том, что в программе "физически" нет такой сущности как класс, если это специально не делается при помощи дополнительных объектов, несущих в себе необходимую информацию. Но эта информация опять же специфическая.

SJA>Я не имею в виду, что есть сущность "класс", я имею в виду, что классы тоже могут оставлять следы в экзешнике, то есть ещё лучше сказать, что есть такая сущность, которая как-то описывает класс, и эти сущности могут появляться, а могут и не появляться (за ненадобностью) в бинарнике.

Эти сущности создаются специально. Как выразился Ваш коллега — "насильно". RTTI этому пример.

A>>Однако, в некоторых случаях в бинарном модуле "следы" класса присутствуют. Например, в DLL для экспортированных классов, в именах методов присутствует имя соответствующего класса. То есть мы можем видеть открытый интерфейс класса.

A>>По поводу RTTI. Во-первых, это вообще вещь не стандартная и отключаемая.

SJA>Что значит не стандартная ? Я что-то упустил ? Неужели dynamic_cast не упоминаеться в стандарте ? И typeid() ???

Извините, не уточнил. Я имел ввиду что бинарное представление RTTI не стандартизировано, по-моему. Так же как и декорирование имён функций. Это я к вопросу об экспортированных классах в DLL.

A>> А во-вторых описания класса она не
SJA>содержит, только имя класса и относительный порядок в списке типов (который может быть различным для разных запусков приложений).

SJA>Ага. Значит имя класса не относиться к описанию класса ? Я считаю что описание класса в бинарнике это структура, которая описывает некоторые свойства. Не обязательно всё, хватит и имени, что бы уже считать это описанием класса.

Опять же всё зависит от того что значит описание класса. Вам с коллегой необходимо договориться о понятии описание класса. Может для него это описание методов и количествово и типы данных-членов.

Здравствуйте, addword, Вы писали:

A>Эти сущности создаются специально. Как выразился Ваш коллега — "насильно". RTTI этому пример.

Как это "насильно" ??? А что вообще создаёться в экзешнике не насильно ? (не будем вспоминать имена секций...)
Описали функцию — она попала в екзешник. Это было насильно ? Или она сама ? Обхявили глобальную переменную — она занимает в экзешнике память. Она туда как попала ? Тоже насильно.... Так что можно вместо "насильно" употреблять термин "обычным способом".

A>>>Однако, в некоторых случаях в бинарном модуле "следы" класса присутствуют. Например, в DLL для экспортированных классов, в именах методов присутствует имя соответствующего класса. То есть мы можем видеть открытый интерфейс класса.

A>>>По поводу RTTI. Во-первых, это вообще вещь не стандартная и отключаемая.

SJA>>Что значит не стандартная ? Я что-то упустил ? Неужели dynamic_cast не упоминаеться в стандарте ? И typeid() ???

A>Извините, не уточнил. Я имел ввиду что бинарное представление RTTI не стандартизировано, по-моему. Так же как и декорирование имён функций. Это я к вопросу об экспортированных классах в DLL.

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

A>Опять же всё зависит от того что значит описание класса. Вам с коллегой необходимо договориться о понятии описание класса. Может для него это описание методов и количествово и типы данных-членов.

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

Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, addword, Вы писали:

A>>Эти сущности создаются специально. Как выразился Ваш коллега — "насильно". RTTI этому пример.

SJA>Как это "насильно" ??? А что вообще создаёться в экзешнике не насильно ? (не будем вспоминать имена секций...)
SJA>Описали функцию — она попала в екзешник. Это было насильно ? Или она сама ? Обхявили глобальную переменную — она занимает в экзешнике память. Она туда как попала ? Тоже насильно.... Так что можно вместо "насильно" употреблять термин "обычным способом".

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

A>>>>Однако, в некоторых случаях в бинарном модуле "следы" класса присутствуют. Например, в DLL для экспортированных классов, в именах методов присутствует имя соответствующего класса. То есть мы можем видеть открытый интерфейс класса.

A>>>>По поводу RTTI. Во-первых, это вообще вещь не стандартная и отключаемая.

SJA>>>Что значит не стандартная ? Я что-то упустил ? Неужели dynamic_cast не упоминаеться в стандарте ? И typeid() ???

A>>Извините, не уточнил. Я имел ввиду что бинарное представление RTTI не стандартизировано, по-моему. Так же как и декорирование имён функций. Это я к вопросу об экспортированных классах в DLL.

SJA>Не важно. Стандарт говорит, как оно должно вести себя. Если можно использовать RTTI без добавления в экзешник дополнительных сущностей, я признаю, что был неправ. (И то частично). Но если нельзя — значит использование стандартных средств (RTTI) заставляет ложить в экзешник что-то, что определяет (упоминает) класс.

Я же и говорю, что бинарное представление не стандартизировано. То есть не оговаривается где, что и как хранить. Оговаривается только поведение. RTTI можно реализовать с хранением информации отдельно от модуля.

A>>Опять же всё зависит от того что значит описание класса. Вам с коллегой необходимо договориться о понятии описание класса. Может для него это описание методов и количествово и типы данных-членов.

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

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

SJA>Проще говоря коллега утверждает, что размер экзешника не зависит от количества классов.

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

Таким образом. Если принять что сведениями о классе в бинарном модуле является хотябы имя класса. То для сегодняшней реализации компиляторов С++ под win32 (о других платфомах и языках не знаю), Ваше утверждение правомочно.

Здравствуйте, Sergey J. A., Вы писали:

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

SJA>Коллега утверждает, что в бинарнике нет никаких сведений о классе, и такое понятие как класс существует только на этапе компиляции.

SJA>Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.

SJA>Коллега в ответ на мои доказательства начинает бредить, и предоставляет какие-то мутные контрдоказательства, например, что RTTI-шная информация вставляеться "насильно"... и поэтому не являеться описанием класса Что значит насильно я не смог выяснить...

SJA>Что скажут знатоки ?

Кстати этот вопрос хорошо освещен в книге Касперского, название точно не помню, ну что то там про хаккеров из серии кодокопатель.

Здравствуйте, addword, Вы писали:

SJA>>Как это "насильно" ??? А что вообще создаёться в экзешнике не насильно ? (не будем вспоминать имена секций...)
SJA>>Описали функцию — она попала в екзешник. Это было насильно ? Или она сама ? Обхявили глобальную переменную — она занимает в экзешнике память. Она туда как попала ? Тоже насильно.... Так что можно вместо "насильно" употреблять термин "обычным способом".

A>В данном случае я просто пытался использовать терминологию Вашего коллеги.
A>Смысл в том что эта информация может присутсвовать, а может и нет. Она вводиться специально по запросу.

Ну и о чём это говорит ? Да ни о чём. Допустим:
Если я не буду использовать функцию, компилятор выбросит её она не появиться в бинарнике. А если где нибудь использую — появиться. Значит функции тоже помещаються специально по запросу...???
Аналогично, если мы используем структуры RTTI (которые некоторым образом информируют нас о классе), то они появяться в экзешнике. А если не используем, не появяться.
То есть никакого особого смысла в словах "насильно" и "специально по запросу" нету. И можно считать, что RTTI информация попадает в бинарник самым обычным путём. Так же как и функции.

SJA>>Не важно. Стандарт говорит, как оно должно вести себя. Если можно использовать RTTI без добавления в экзешник дополнительных сущностей, я признаю, что был неправ. (И то частично). Но если нельзя — значит использование стандартных средств (RTTI) заставляет ложить в экзешник что-то, что определяет (упоминает) класс.

A>Я же и говорю, что бинарное представление не стандартизировано. То есть не оговаривается где, что и как хранить. Оговаривается только поведение. RTTI можно реализовать с хранением информации отдельно от модуля.

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

A>>>Опять же всё зависит от того что значит описание класса. Вам с коллегой необходимо договориться о понятии описание класса. Может для него это описание методов и количествово и типы данных-членов.

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

A>А может у него спросить что он имеет ввиду? А то получается что спор этот, вернее его результат, нужен только Вам.
Он незнает. По крайней мере я не смог добиться внятного ответа — толи полная инфа о классе толи вообще исходный код...

SJA>>Проще говоря коллега утверждает, что размер экзешника не зависит от количества классов.

A>Так бы сразу и сказали.
A>В любом случае размер зависит от количества классов, с информацией о типах или же без неё.

А почему в любом случае ? Мне кажеться нет. Если описать класс class A {}; и нигде его не исользовать, то он и не просочиться в экзешник....

A>Таким образом. Если принять что сведениями о классе в бинарном модуле является хотябы имя класса. То для сегодняшней реализации компиляторов С++ под win32 (о других платфомах и языках не знаю), Ваше утверждение правомочно.

Нужно показать Ваше авторитетное мнение коллеге....

Здравствуйте, Denwer, Вы писали:

D>Кстати этот вопрос хорошо освещен в книге Касперского, название точно не помню, ну что то там про хаккеров из серии кодокопатель.

Ех... Увижу куплю... Особенно если там действительно кодокопательство....

Здравствуйте, Sergey J. A., Вы писали:

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

SJA>Коллега утверждает, что в бинарнике нет никаких сведений о классе, и такое понятие как класс существует только на этапе компиляции.

В общем случае да. Например такой класс

class Point
{
   int x;
   int y;
}

В Exe ни окажется ни при каких параметрах компиляции и компиляторах(если не считать отладочные символы).

SJA>Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.

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

SJA>Коллега в ответ на мои доказательства начинает бредить, и предоставляет какие-то мутные контрдоказательства, например, что RTTI-шная информация вставляеться "насильно"... и поэтому не являеться описанием класса Что значит насильно я не смог выяснить...

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

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, Sergey J. A., Вы писали:

SJA>>Коллега утверждает, что в бинарнике нет никаких сведений о классе, и такое понятие как класс существует только на этапе компиляции.

A>В общем случае да. Например такой класс
A>

A>class Point
A>{
A>   int x;
A>   int y;
A>}
A>

A>В Exe ни окажется ни при каких параметрах компиляции и компиляторах(если не считать отладочные символы).

Угу. А вы попробуйте написать

throw Point();

И поискать в экзешнике имя Point. Только сядьте предварительно на стул.
При ловле/бросании исключений необходима информация о типе в рантайме. Так что в коде, который использует исключения, появляеться информация о типах.

SJA>>Я утверждаю, что в бинарнике всё же извесно такое понятие как класс, а именно привёл пример RTTI информации, которая лежит в бинарнике и описывает неоторый класс (его имя, и что-то ещё). Естественно, ненужные описания компилятор выбрасывает, поэтому данные там появляються не всегда.

A>Ваш спор бесмысленнен потому что вы не определили что такое "класс в бинарнике". Если имя то да оно может там оказаться. Если виртуальная таблица то тоже есть. Если информация которая позволяет восстановить список членов класса то нет.

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

SJA>>Коллега в ответ на мои доказательства начинает бредить, и предоставляет какие-то мутные контрдоказательства, например, что RTTI-шная информация вставляеться "насильно"... и поэтому не являеться описанием класса Что значит насильно я не смог выяснить...

A>Оно не является описанием класс в общем смысле. RTTI это обычно в реализации тесно связанна с виртуальной таблицей которая принадлежит именно классу, а не конкретному экземпляру, но то же можно сказать и про любой статический член класса

А помоему вполне описание. В общем смысле, что такое описание ? IMHO описание — информация, как-то характеризующая объект. Имя как раз и характерирзует класс.

А то, что RTTI связана именно с классом только доказывает мою правоту Ведь, если она связана с классом, значит она описывает именно класс ! Если бы она была связана с конкретным экземпляром, она бы описывала именно его !

Здравствуйте, Sergey J. A., Вы писали:

SJA>И поискать в экзешнике имя Point. Только сядьте предварительно на стул.
SJA>При ловле/бросании исключений необходима информация о типе в рантайме. Так что в коде, который использует исключения, появляеться информация о типах.

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

SJA>Под информацией о классе я имею в виду что-то, что описыает класс, на основании чего можно сделать вывод, что была такая сущность в исходных кодах. Причём это должна быть некая информация в определённой для данного компилятора форме, то есть лучше сказять, что информация, которую пихает сам компилятор без дополнительной просьбы. Допустим, если описать структуру ClassRuntime в которой указать имя класса и потом запихнуть её для кажного класса самостоятельно, это не будет считаться (пример в MFC с макросами вокруг RUNTIME_CLASS).

Ты знаешь у меня есть опыт reverse engineering несколько лет, я тебе и структуру plain C с большой вероятностью обратно восстановлю, если надо будет. Безо всякой доополнительной информации, просто поняв как компилятор адресацию генерит. Находишь длину структуры по конструктору или по максимальному смещению, потом смотришь все смещения в ней, а потом по использованию догадываешься, что это было.

Я в сумме к тому, что в структура и класс в C++ это одно и то же различающиеся только доступом к членам по умолчанию. Ты же не будешь утверждать что plain-C в структурах тоже всю эту информацию генерит.

SJA>А помоему вполне описание. В общем смысле, что такое описание ? IMHO описание — информация, как-то характеризующая объект. Имя как раз и характерирзует класс.

SJA>А то, что RTTI связана именно с классом только доказывает мою правоту Ведь, если она связана с классом, значит она описывает именно класс ! Если бы она была связана с конкретным экземпляром, она бы описывала именно его !

Любой статический член связан с классом.

P.S. а вообще лучше не занимайся философией, а возьми дизассемблер и посмотри как код генерится.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, Sergey J. A., Вы писали:

SJA>>И поискать в экзешнике имя Point. Только сядьте предварительно на стул.
SJA>>При ловле/бросании исключений необходима информация о типе в рантайме. Так что в коде, который использует исключения, появляеться информация о типах.

A>А ты попробуй при этом включить exception и выключить rtti.

Ясное дело — пробовал. Имя класса присутствует в бинарнике. А что, у тебя имя класса не появилось ? Какой в таком случае компилятор использовался ? Я пользуюсь VC++6.0

A>Кроме того опять же не все классы используются как исключения, даже скажем меньшенство.

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

SJA>>Под информацией о классе я имею в виду что-то, что описыает класс, на основании чего можно сделать вывод, что была такая сущность в исходных кодах. Причём это должна быть некая информация в определённой для данного компилятора форме, то есть лучше сказять, что информация, которую пихает сам компилятор без дополнительной просьбы. Допустим, если описать структуру ClassRuntime в которой указать имя класса и потом запихнуть её для кажного класса самостоятельно, это не будет считаться (пример в MFC с макросами вокруг RUNTIME_CLASS).

A>Ты знаешь у меня есть опыт reverse engineering несколько лет, я тебе и структуру plain C с большой вероятностью обратно восстановлю, если надо будет. Безо всякой доополнительной информации, просто поняв как компилятор адресацию генерит. Находишь длину структуры по конструктору или по максимальному смещению, потом смотришь все смещения в ней, а потом по использованию догадываешься, что это было.

A>Я в сумме к тому, что в структура и класс в C++ это одно и то же различающиеся только доступом к членам по умолчанию. Ты же не будешь утверждать что plain-C в структурах тоже всю эту информацию генерит.

Нет. В С эта информация не нужна, поэтому при компиляции С файлов информация о типах не попадает в бинарник. В С++ это иногда нужно и информация о типах там иногда появляеться. А вот например в .Net как извесно нужно ещё больше информации о типах и они там появляються ещё чаще.

SJA>>А то, что RTTI связана именно с классом только доказывает мою правоту Ведь, если она связана с классом, значит она описывает именно класс ! Если бы она была связана с конкретным экземпляром, она бы описывала именно его !

A>Любой статический член связан с классом.
Да, но он не описывает класс. А RTTI информация делает это чёрное дело. И собственно я не понимаю, почему она "Оно не является описанием класс в общем смысле" ?

A>P.S. а вообще лучше не занимайся философией, а возьми дизассемблер и посмотри как код генерится.

Хм. Если форум "философия программирования", то это не значит, что я не лазил в ассемблер. И дизасемблер тут кстати совершенно не нужен — VC++6.0 (и gcc) позволяет генерить промежуточный asm исходник. Собственно, как я по твоему узнал, что исключения тянут информацию о типах ? Скомпилял с throw CPoint(); и без. И заметил, что некая структура то появляется, то исчезает. Причём данная структура содержит имя декорированное класса и по кол-ву членов совпадает со структурой type_info. Вот собственно эту структуру я и имел в виду, когда говорил, что в бинарнике может имееться некоторая инфа о типах (о классах в часности).

З.Ы. Собственно в чём конкретно ты не согласен с моим изначальным утверждением ?

Здравствуйте, Sergey J. A., Вы писали:

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

Есть ли там информация, нет ли ее, а какая,в сущности, разница ?

Здравствуйте, Sergey J. A., Вы писали:

SJA> Собственно, как я по твоему узнал, что исключения тянут информацию о типах ? Скомпилял с throw CPoint(); и без. И заметил, что некая структура то появляется, то исчезает. Причём данная структура содержит имя декорированное класса и по кол-ву членов совпадает со структурой type_info. Вот собственно эту структуру я и имел в виду, когда говорил, что в бинарнике может имееться некоторая инфа о типах (о классах в часности).

По поводу структурки, которая "то появляется, то исчезает" почитай здесь

Чуть-чуть процитирую:

...
The catch block catches the exception if H and E are the exact same type. The exception handler has to compare the types at runtime. Normally, languages like C provide no facility to determine object's type at runtime. C++ provides run time type identification mechanism (RTTI) and has a standard way of comparing types at runtime. It defines a class type_info, defined in standard header <typeinfo> that represents a type at runtime. The second field of the catchblock structure (see figure 5) is a pointer to the type_info structure that represents the type of the catch block's parameter at runtime. type_info has operator == that tells whether the two types are of exact same class or not. So, all the exception handler has to do is to compare (call operator ==) the type_info of the catch block's parameter (available through catchblock structure) with the type_info of the exception to determine if the catch block is interested in catching the current exception.

The exception handler knows about the type of the catch block's parameter from funcinfo structure, but how does it know about the type_info of the exception? When compiler encounters a statement like

throw E();
It generates excpt_info strcuture for the exception thrown. See figure 6.
...

Здравствуйте, UGN, Вы писали:

UGN>Здравствуйте, Sergey J. A., Вы писали:

SJA>> Собственно, как я по твоему узнал, что исключения тянут информацию о типах ? Скомпилял с throw CPoint(); и без. И заметил, что некая структура то появляется, то исчезает. Причём данная структура содержит имя декорированное класса и по кол-ву членов совпадает со структурой type_info. Вот собственно эту структуру я и имел в виду, когда говорил, что в бинарнике может имееться некоторая инфа о типах (о классах в часности).

UGN>По поводу структурки, которая "то появляется, то исчезает" почитай здесь

Ну да. Всё это я видел в промежуточных соурсах. Но под "структуркой" я подразумевал именно type_info, которая появляется только если это нужно.