Здравствуйте, wander, Вы писали:
W>Здравствуйте, Максим Рогожин, Вы писали:
МР>>Функции? Но функции имеют бинарное представление.
W>Да, но функции не объекты.
W>Еще пример: имеет тип, но не имеет бинарного представления — тип void.
Верно подмечено. У типа void еще и объектов этого типа нету. Получается что в C++ для типа не являются обязательными:
— наличие объектов данного типа
— наличие бинарного представления у объектов (переменных) данного типа
Здравствуйте, Максим Рогожин, Вы писали:
W>>Еще пример: имеет тип, но не имеет бинарного представления — тип void. МР>Верно подмечено. У типа void еще и объектов этого типа нету. Получается что в C++ для типа не являются обязательными: МР>- наличие объектов данного типа МР>- наличие бинарного представления у объектов (переменных) данного типа
Ну да. C++ статически типизированный язык, это значит, что его система типов существует в основном на этапе компиляции.
А на этапе компиляции совсем не нужны объекты для игры с типами. Поэтому мы можем позволить себе такие типы как void, любые неполные типы,
всяческие массивы неизвестного размера, ссылки-не-объекты без конкретного двоичного представления и т.п.
Здравствуйте, σ, Вы писали:
MA>> Мне видится глупым, что в языке вообще существует такой тип данных вообще — он может быть передан в функцию, но не может быть полем. σ>Что такое поле и какой тип им быть не может?
Извиняюсь за запоздалый ответ. Ссылка.
Здравствуйте, reversecode, Вы писали:
МР>>Можно ли считать ссылки (lvalue reference, rvalue reference) типом данных? Если нет, то тогда чем их считать? R>для чего это может понадобится ?
Например, чтобы ясно определится со стилем, где следует писать аперсанд — слитно с типом или слитно с переменной:
Если ссылка — это тип, то:
int& ref = ...
Если ссылка — это не тип, то:
int &ref = ...
Хотя, конечно, тут могут быть и другие соображения; взятие адреса, например...
Здравствуйте, Mystic Artifact, Вы писали:
MA>>> Мне видится глупым, что в языке вообще существует такой тип данных вообще — он может быть передан в функцию, но не может быть полем. σ>>Что такое поле и какой тип им быть не может? MA> Извиняюсь за запоздалый ответ. Ссылка.
#include <iostream>
using namespace std;
struct A
{
int& m_field;
A() : m_field{*new int{1}} {}
~A(){ delete &m_field; }
};
int main()
{
A a;
a.m_field += 2;
std::cout << "a.m_field = " << a.m_field << std::endl;
// your code goes herereturn 0;
}
Хотя, откровенно говоря, зная какие они ограничения там накладывают и как они устроены — они там не особо к месту зачастую. Замувили объект, а занулить не можем? Это как раз в тему того, что я писал выше. Но... реально был уверен, что нельзя их делать полем. Вот же ж, век учись.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Хотя, откровенно говоря, зная какие они ограничения там накладывают и как они устроены — они там не особо к месту зачастую. Замувили объект, а занулить не можем? Это как раз в тему того, что я писал выше. Но... реально был уверен, что нельзя их делать полем. Вот же ж, век учись.
Ссылки, как члены класса, использовались до C++11 для освобождения ресурсов стороннего объекта в деструкторе. Например:
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет!
МР>Можно ли считать ссылки (lvalue reference, rvalue reference) типом данных? Если нет, то тогда чем их считать?
Само понятие "тип данных" есть абстракция, как часть системы абстракций, выраженной некоторым ЯП. В бинарном представлениии есть только сами данные. "Тип данных"-это составляющая системы организации данных, а не сами данные. Поэтому "тип данных" не обязательно должен имет представление в результирующей программе. Но он имеет представление в компиляторе или интерпретаторе (части системы организации данных), то есть, промежуточной системе, которая подготавливает систему данных на основе её модели, описанной на некотором ЯП. И этой системе абсолютно всё равно, это int, это string, это class Foo или это Foo& или это string*. Эта подготавливающая система обязательно учитывает все сущности, выделяя для них память для представления их при создании результирующей системы, даже если в результирующей системе данная сущность не будет иметь какого-либо воплощения. Это общие суждения, примерно так рассуждают создатели стандартов ЯП.