ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

static void Main(string[] args) {
 …
 // Преобразование System.Int32 в Square.
 Square sq2 = (Square)90;
 Console.WriteLine("sq2 = {0}", sq2);
 // Преобразование Square в System.Int32.
 int side = (int)sq2;
 Console.WriteLine("Длина стороны sq2 = {0}", side);
}

А вот как следует обновить определение типа Square.

public struct Square {
 …
 public static explicit operator Square(int sideLength) {
 Square newSq;
 newSq.Length = sideLength;
 return newSq;
 }
 public static explicit operator int(Square s) { return s.Length; }
}

Выглядит немного странно, не так ли? Честно говоря, преобразование из Square в System.Int32 не является интуитивно очевидной (или полезной) операцией. Однако она демонстрирует одну очень важную особенность пользовательских подпрограмм преобразования; компилятору "все равно" из чего и во что вы преобразуете – важно, чтобы ваш программный код был синтаксически правильным. Так что, как в случае с перегрузкой операций, только из того, что вы можете создать операцию явного преобразования для данного типа, совсем не следует, что вы обязаны это делать. Как правило, этот подход оказывается наиболее полезным тогда, когда создаются типы структуры .NET, поскольку такие типы не могут использовать иерархии классического наследования (для которых соответствующие преобразования реализуются автоматически).

Определение подпрограмм неявного преобразования

До этого момента мы с вами создавали пользовательские операции явного преобразования. Но что можно сказать о следующем неявном преобразовании?

static void Main(string[] args) {
 …
 // Попытка выполнить неявное преобразование?
 Square s3;
 s3.Length = 83;
 Rectangle rect2 = s3;
}

Как вы можете догадаться сами, этот программный код скомпилирован не будет, поскольку в нем не предлагается никакой подпрограммы неявного преобразования для типа Rectangle. Тут нас подстерегает "ловушка": в одном и том же типе нельзя определять явные и неявные функции преобразования, не отличающиеся по типу возвращаемого значения или по набору параметров. Может показаться, что это правило является слишком ограничивающим, но не следует забывать о том, что даже если тип определяет подпрограмму неявного преобразования, вызывающая сторона "имеет право" использовать синтаксис явного преобразования!

Запутались? Чтобы прояснить ситуацию, добавим в структуру Rectangle подпрограмму неявного преобразования, используя ключевое слово C# implicit (в следующем программном коде предполагается, что ширина результирующего Rectangle получается с помощью умножения стороны Square на 2).

public struct Rесtangle {
 …
 public static implicit operator Rectangle(Square s) {
 Rectangle r;
 r.Height = s.Length;
 // Ширина нового прямоугольника равна
 // удвоенной длине стороны квадрата.
 r.Width = s.Length * 2;
 }
}

С такими изменениями вы получаете возможность преобразовывать указанные типы так.

static void Main(string[] args) {
 …
 // Неявное преобразование: все OK!
 Square s3;
 s3.Length = 83;
 Rectangle rect2 = s3;
 Console.WriteLine("rect2 = {0}", rect2);
 DrawSquare(s3);
 // Синтаксис явного преобразования: тоже OK!
 Square s4;
 S4.Length = 3;
 Rectangle rect3 = (Rectangle)s4;
 Console.WriteLine("rect3 = {0}", rect3);
 …
}

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

public struct Square {
 …
 // Можно вызывать как Square sq2 = (Square)90;
 // или как Square sq2 = 90;
 public static implicit operator Square(int sideLength) {
 Square newSq;
 newSq.Length = sideLength;
 return newSq;
 // Должно вызываться как int side = (Square)mySquare;
 public static explicit operator int(Square s) { return s.Length; }
 }
}

Внутреннее представление пользовательских подпрограмм преобразования

Как и в случае перегруженных операций, те методы, которые обозначены ключевыми словами implicit или explicit, получают "специальные имена" в терминах CIL: op_Implicit и op_Explicit соответственно (рис. 9.2).

Рис. 9.2. Представление пользовательских подпрограмм преобразования в терминах CIL.

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

Исходный код. Проект CustomConversions размещен в подкаталоге, соответствующем главе 9.

Ключевые слова C#, предназначенные для более сложных конструкций

В завершение главы мы рассмотрим ряд ключевых слов C#, применение которых требует от разработчика несколько большего опыта в программировании:

• checked/unchecked;

• unsafe/stackalloc/fixed/sizeof.

Сначала мы выясним, как с помощью ключевых слов checked и unchecked в C# обеспечивается автоматическое выявление условий переполнения и потери значимости при выполнении арифметических операций.

Ключевое слово checked