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

Текст из файла (страница 13)

В C# еще есть using блоки. Для всех переменных заданных в нем, в конце блока будет вызван Finalise();

Using(Image im= Image.FromFile(name)

{

//делаем что-то с im

}

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

P.S В Java есть термин «слабая ссылка» (WeakReference), имеющая непосредственное отношение к сборщику мусора. (слабая ссылка это фактически, с точки зрения программиста, память, которая уже освобождена, но финализатор еще не вызван). Теоретически ресурсы еще можно восстановить методом GetReference(), превращая слабую ссылку в живую.

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

П.4 Дополнительные проблемы, связанные с типами.

1. Копирование, сравнение.

2. Неявные преобразования.

Проблема копирования и сравнения. Их проблема состоит в том, что они могут отличаться от стандартных. Как сравнить и можно ли ограничиться простым почленным копированием. Отсюда 2 понятия – глубокое и поверхностное копирование.

На вопрос о том, как именно копировать может ответить только программист. В С++ семантику всех операций можно изменить. Delphi игнорирует проблему копирования.

В C# и Java есть метод Clone() и интерфейс ICloneable. В классе Object есть метод MemberWiseClone() – делает поверхностную копию. (поверхностное копирования копирует просто ссылку, а глубокое копирует еще и содержимое ссылки).

Лекция 25.

Самая главная проблема — это проблема копирования.

A=B.Clone()

Есть 2 способа — умолчательная семантика — мелкое копирование (поверхностное копирование) и глубокое копирование. Если мы делаем после клонирования, произвольную модификацию А, то не произойдёт ли такое же и с B? Если А и В — константные элементы, то нам не нужно глубокое копирование, достаточно скопировать ссылку. Программист должен сам решать, что делать ему с операцией копирования — эта проблема встаёт на большинстве языков. Современные языки хороши тем, что концентрируют внимание на этой проблеме и предлагают её решение.

C++:

Умолчание => поверхностное копирование.

Переопределение конструктора копирования => глубокое копирование.

Заметим, что проблемы решаются только на уровне класса. Унаследовав класс, надо проблему решать заново. Представим, что есть класс, где программист переопределил и оператор присваивания, и конструктор копирования.

class X{

public:

X& operator=(const X&);

X(const X&);

};

class Y: public X{

int i;

};

Для каждого объекта вызывается его конструктор копирования. Если не переопределен, то будет произведено побитовое копирование.

C#/Java:

a=b — присваивание ссылки

C#:

По умолчанию — побитовое копирование, во всех случаях — protected object.

Если мы хотим подчеркнуть, что класс хочет разрешить копирование, есть специальный интерфейс ICloneable с функцией Clone(); Если класс хочет сказать, что он обеспечивает копию себя, то он должен унаследовать этот интерфейс и определить public object clone(){..}.

Тем не менее, сделать глубокую копию объекта — не так просто, недостаточно просто наследовать интерфейс. С этой точки зрения, подход Java самый предпочтительный из всех.

Java:

Точно также существует защищенная операция — protected object clone();

Тут операция более хитрая, в C# просто отводится память, но размер конкретного типа.

Есть понятие интерфейс-маркер. Это интерфейс вообще без методов, просто пустой интерфейс. В C#/Java есть понятие рефлексии, где мы можем узнать поддержку интерфейса по свойствам программы. В частности, таким маркером является и ICloneable — контракт «я обязуюсь обеспечить нормальное глубокое клонирование». В итоге возникает 4 стратегии клонирования: 1я — когда класс явным образом утверждает, что реализует интерфейс ICloneable и должен реализовать public object clone() - класс гарантирует, что он будет клонировать. Такая вещь лучше документации говорит, что программист обязан поддерживать глубокое копирование. Если класс не поддерживает этот интерфейс, то вызывается специальное исключение cloneNotSupported. 2я — когда класс явным образом не реализует вообще этот интерфейс и реализует публичный метод public object clone() throws cloneNotSupported и в методе выбрасывает первым делом такое исключение, 3я — условная поддержка, в 1м случае клонирование ничего не пропускает, а тут сам объект поддерживает своё глубокое копирование, а подобъекты могут не поддерживать и возбуждается исключение, 4я — класс не реализует интерфейс, однако реализует protected object clone(), который честно возвращает побитовую копию. Если не переопределить эту операцию, при условии не поддержки будет выдаваться исключение.

Связанная с копированием проблема это проблема сравнения (в частности на равно-не равно).

И вообще — равенство это тождество или сравнение содержимого? Если сравниваем содержимое, то нужно переопределять соответствующие операции, иначе нужно сравнивать адреса.

C# bool Equals(object o)

Java bool equals(object o)

возвращает по умолчанию this == o, то есть сравнение ссылок

b=null

a.Equals(b); вернёт 0

b.Equals(a); - ошибка

Поэтому статический метод с 2мя параметрами корректно обрабатывает операции с 2 ссылками.

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

Лекция 26.

Перегрузка операции и частный случай перегрузки операций это неявные преобразования.

Если мы посмотрим на ЯП встает основной вопрос: «допускать ли неявные преобразования определяемые пользователем?».

Неявные преобразования вставляет сам компилятор.

Int I, double d;

I=d – сужающее преобразование.

D=i – расширяющее преобразование.

В языке Ада неявные преобразования вообще запрещены, в Обероне допускается только расширяющие преобразования.

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

С++ и С# допускают пользовательские неявные преобразования.

Дельфи, Джава – нет.

Рассмотрим аргументы «за» и «против», и как это реализовано в разных языках.

Первоначально, чтобы проверить удались ли классы , Страуструп написал класс Complex, а также класс файлов ввода/вывода (то что потом перешло в библиотеку iostream).

Для вычисления функций с комплексными числами, вроде A=B*EXP(-k*i)/D пришлось бы писать много функций для комплексных переменных (complex PLUS(Complex c1, Complex c2), и так далее). А в С++ мы можем просто описать оператор «+» для класса комплекс, но без неявных преобразований это бы не прошло, так как пришлось бы описывать оператор плюс для всевозможных математических классов (а это ужос как много (256) ). (в первом варианте языка С++ не было неявных преобразований)

И как только появились неявные преобразования, Страуструп придумал конструктор преобразований, то есть например Complex(double). Другой пример конструктора преобразований String( const char* ), и после этого стало можно писать S=”string” и компилятор автоматически подставляет S=string(“string”).

Оператор преобразований.

Operator T() – он определяет преобразование класса X (класс где описан этот оператор) в класс Т.

Operator const char*() const;

Но существует некоторые проблемы:

Class Vector{

Int *body;

Int size;

Public:

Vector(int n) {….} //где n это размер создаваемого вектора.

~Vector(){….}

};

И в данном случае мы создали конструктор от int, который компилятором будет рассматриваться как оператор преобразования, тоесть приведения типа int к vector.

И если мы нечаянно напишем v=3; то получим вектор длины три, а не то что могли бы ожидать.

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

В С# были введены два ключевых слова explicit и implicit, explicit – означает тоже самое что и в С++, а implicit означает, что эта функция будет вызываться неявно.

Если в классе задан оператор Operator T(); и X x; T t; , тогда t=x тоже самое, что t=x.operator T().

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

И язык Делфи и язык Джава не позволяют перекрывать стандартные операции ( +, - и т.д.).

Джава:

String S;

S+I ~ S+i.toString();

Вообще компиляторы не знают о существовании стандартных библиотек, но последние версии С++ уже начинают немного знать о стандартных библиотеках.

Синтаксис перекрываний операций в языке C# такой же как и в С++, но количество возможный операций, которые можно перекрыть, намного беднее чем в С++. (например арифметические операции)

В C#:

Class X{

Int this[string S]{….}

}

Int <- x[“string”] - таким вот образом в C# можно перекрывать оператор индексирования.

П.5 Свойства (property).

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

Понятие свойства существует в языках C# и Делфи.

Заметим, что хоть языками функции свойства не поддерживаются, но их всегда можно описать с помощью accessors (создание функций getter, setter).

Delphi:

Type X=class // либо имя переменной члена класса либо имя процедуры (функции).

….. / \

Property p:integer read accessor write accessor

Type X=class

Private

FLength: integer;

Property length: integer read FLength write FLength;

a:X;

a.Length:=1;

i:=a.Length; (что это дает не очень понятно)

type Figure = class

private a,b: integer;

Farea: integer;

Property Area: integer read Farea;

Property Width:integer read b write SetWidth

Private procedure SetWidth(X:integer);

Такая запись означает, что мы ограничиваем запись в переменную Area, а переменная Width при считывании выдает значение переменной b, а при записи вызывается функция SetWidth.

C#:

Class Rect{

Характеристики

Список файлов лекций