Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Общие вопросы по .NET и C# > .NET глазами дельфийца. C#

Автор: Medved 21.12.2004, 09:13

.NET глазами дельфийца. C# опубликовано: 27.03.2002 14:46 Учитывая то, что C#, как и Delphi, выступает одновременно в двух качествах, т.е. с одной стороны, является семантически строго определенным языком программирования и, с другой стороны, использует поставляемые в составе .Net библиотеки классов и компонентов, на первом этапе имеет смысл сконцентрироваться на самом языке программирования, т.к. изучение и сравнительный анализ библиотек классов - гораздо более объемная работа. .Net глазами дельфийца - первые впечатления. Введение При знакомстве с новым языком программирования любого программиста в первую очередь интересует семантическая основа языка, т.е. насколько его выразительные возможности позволяют реализовать привычные логические конструкции. Учитывая то, что C#, как и Delphi, выступает одновременно в двух качествах, т.е. с одной стороны, является семантически строго определенным языком программирования и, с другой стороны, использует поставляемые в составе .Net библиотеки классов и компонентов, на первом этапе имеет смысл сконцентрироваться на самом языке программирования, т.к. изучение и сравнительный анализ библиотек классов - гораздо более объемная работа. Чего нет в C# Отсутствие в C# некоторых вещей обусловлено тем, что C# является <чисто> объектным языком программирования, а Delphi - гибридным. Тем не менее, в C# или имеются, или могут быть легко реализованы самостоятельно практически все семантически эквивалентные конструкции. Итак, C# не предоставляет следующие возможности (их рассмотрение не вошло в настоящий документ в силу или второстепенного значения, или наличия семантически эквивалентных реализаций в библиотеке CLR): значения параметров по умолчанию множества (set) - реализуется в виде специальных классов в библиотеке CLR диапазоны (subrange) - реализуется в виде специальных классов в библиотеке CLR синонимы простых типов ресурсные строки (resourcestring) - рассматривается как частный случай констант Более существенные конструкции, которых нет в C#: процедуры, функции глобальные константы глобальные переменные предварительное объявление типов типизованные константы const-параметры указатели Процедуры, функции Если считать, что процедуры - это просто функции, которые не возвращают никакого значения, то семантическая нагрузка процедур и функций в Delphi одинакова. Это - выполнение некоторого фрагмента кода, который, возможно, зависит от входных параметров: Код procedure A(aParam: integer); begin   // ... end; function B(aParam: integer): integer; begin   // ...   Result := 0; end; A(1); X := B(1); В C# семантическим эквивалентом процедур и функций выступают статические методы классов. Код // класс-обертка class Func {   // статический метод без возвращаемого значения - эквивалент процедуры   static public void A(int aParam);   // статический метод - эквивалент функции   static public int B(int aParam); } // вызов процедуры Func.A(1); // вызов функции int X := Func.B(1); Глобальные константы Семантическая нагрузка в Delphi - определение значений примитивных типов данных, доступных из любого места кода и неизменяемых в процессе выполнения программы. Код const A = 100; const B = 'строка'; D := A; ShowMessage(B); Семантический эквивалент в C# - статические константы. Код // класс-обертка class Const {   // описание констант   public const int A = 100;   public const string B = "строка"; } // использование констант int a = Const.A; MessageBox.Show(Const.B); Кроме статических констант C# предоставляет механизм статических полей <только для чтения>, который позволяет программисту использовать в качестве констант не только примитивные значения, но и объекты. Пример кода: Код // класс-обертка class Const {   // число-константа   public static readonly int A = 1;   // объект-константа   public static readonly MyObject Obj = new MyObject(); } Глобальные переменные Семантическая нагрузка в Delphi - формирование объектов программы (как примитивных типов, так и сложных), доступных из любого места кода и, возможно, изменяемых в процессе выполнения программы. Код var A: integer; B := A; A := 1; Семантический эквивалент в C# - статические поля классов. Код // класс-обертка class Globals {   // определение статических переменных   // инициализация по умолчанию = 0   public static int A;   // одновременные описание и инициализация   public static int B = 1; } // использование статических переменных int a = Globals.A; Globals.A = 1; int b = Globals.B; Globals.B = 1; Предварительное объявление типов Предварительное объявление типов на самом деле не предусмотрено общей теорией объектно-ориентированного программирования и является частным решением Delphi, направленным на ослабление правила, которое было введено еще в классическом Pascal, - <все типы данных, используемые для построения сложных типов, должны быть или примитивного типа, или описаны до их использования>. Пример кода на Delphi: Код type   TMyObject1 = class;   TMyObject2 = class;     TMyObject1 = class     function GetChild(Index: int): TMyObject2;   end;   TMyObject2 = class     property Owner: TMyObject1 read fOwner;   end; В C# предописание типов не требуется, т.к. в пределах области видимости классов (обрамляющий класс, пространство имен) порядок объявления несущественен. Такое решение упрощает написание кода: Код namespace MyObjects {   public class TMyObject1 {     public TMyObject2 GetChild(int Index) { ... }   }   public class TMyObject2 {     public TMyObject1 Owner {       get { return owner; }     }   } } Типизированные константы Типизированные константы в Delphi позволяют хранить не только значения примитивных типов, но и массивы, записи, а также указатели, включая указатели на процедуры и функции: Код const A: integer = 1; const B: array [1..3] of integer = (1, 2, 3); В C# константы всегда типизированы - как при использовании модификатора const, так и readonly. В Delphi при использовании директивы компилятора {$J+} (установлено по умолчанию) типизованные константы ведут себя как обычные переменные, которые инициализируются одновременно с описанием, т.е. их значение может быть изменено в ходе выполнения программы: Код const A: integer = 1; X := A; A := 2; В C# действуют более строгие правила - если константа, то поменять ее значение невозможно. Если же используется поле <только для чтения>, то его содержимое может быть изменено в контексте объекта: Код // класс-обертка public class Const {   // число-константа   public readonly int A = 1;   // метод изменяет значение поля A   public void ChangeA(int NewValue) { A = NewValue; } } При использовании типизованных констант в качестве инициализируемых переменных в области видимости подпрограммы (метода, процедуры, функции) в Delphi наблюдается недокументированный побочный эффект - данные, записанные в локальные типизованные константы, сохраняются между вызовами подпрограмм: Код procedure A; const B: integer = 0; begin   Inc(B);   ShowMessage(IntToStr(B)); end; procedure Do; begin   A;   A;   A; end; Результаты вывода: 1, 2, 3 В C# подобный побочный эффект отсутствует. Вообще, стандартизация C# в качестве международного стандарта (ECMA, 2001 год) гарантирует отсутствие побочных эффектов. Поэтому если в программе C# необходимо сохранять некоторое состояние между вызовами подпрограмм (методов), используются стандартные средства, в частности, статические или обыкновенные поля классов. Const-параметры В Delphi семантический смысл const-параметров заключается в указании компилятору на возможность оптимизации передачи в функцию (процедуру, метод) неизменяемой ссылки на некоторый объект программы. Так, например, конструкция типа: Код procedure A(const S: string); означает, что в качестве параметра процедуры будет передаваться ссылка на строку (при этом копирования содержимого строки в стек вызова процедуры не происходит). Кроме того, содержимое строки S внутри процедуры изменить нельзя. В C# не предусмотрено прямого эквивалента const-параметров. Тем не менее, в случае необходимости может быть построена семантически эквивалентная конструкция (аналогия вышеприведенному примеру): Код class ReadOnlyString {   ReadOnlyString(string S) { this.S = S; }   public readonly string S;   static void Test(ReadOnlyString s) { Console.Write(s.S); }   static void Main() {     string s = "проверка const-параметров";     ReadOnlyString.Test(new ReadOnlyString(s));   } } Приведенный код иллюстрирует использование классов-<оберток> (т.н. wrappers) и полей <только для чтения>. Указатели В Delphi указатели чаще всего используются для <тонкого> управления такими конструкциями, как записи. В частности, при передаче записи в качестве параметра в подпрограмму (процедуру, функцию или метод) происходит побайтное копирование в стек вызова, что может приводить к серьезным накладным расходам. Альтернативное решение - передать в качестве параметра указатель на запись и уже через него внутри подпрограммы получить доступ к элементам записи. В C# приведенный пример использования указателей на записи более изящно и безопасно реализуется с использованием такой конструкции, как struct. Структуры, как и записи Delphi, могут использоваться для хранения данных и, что более важно с точки зрения семантики, являются объектами, передаваемыми не по ссылке, а по значению. На самом деле, в C# имеется всего лишь одна возможность использовать указатели - т.н. <небезопасный> код (unsafe code). Особенности его использования определены в стандарте C# достаточно подробно (спецификация C#, приложение A). Однако, необходимо отметить, что в практическом программировании редко приходится использовать указатели для иных целей, кроме оптимизации производительности. Поэтому, учитывая классическое правило <80/20> (<80% пива выпиваются двадцатью процентами населения>, или <80% используемых ресурсов программы приходится на 20% кода>, или <80% объема работы позволяет улучшить производительность только на 20%>), можно акцентироваться на оптимизации кода (в терминах C# - использование небезопасного кода) только при необходимости и только тогда, когда выявлены те самые 20% кода, которые используют 80% ресурсов. Чего нет в Delphi Теперь можно рассмотреть те преимущества, которые имеет C# по сравнению с Delphi (порядок перечисления произволен и ни в коей мере не отражает объективные приоритеты или субъективные предпочтения): описание переменных в коде программы возможность передачи в метод переменного количества параметров автоматическое удаление объектов поля классов <только для чтения> индексаторы делегаты возможность реализации модели обработки событий <один-много> цикл foreach статические конструкторы операторы классов структуры атрибуты возможность использовать русский язык для имен объектов программы Описание переменных в коде программы Возможность описания переменных в коде программы пришла в C# из C++. Пример кода: Код class VarTest {   static void Main() {     int a;     int b, c = 1, d;     for (int i = 0; i < 10; i++) {       int x = i * 2;     }   } } В этом примере продемонстрированы сразу несколько возможностей, отсутствующих в Delphi: описание переменных <по месту> одновременное описание и инициализация переменных локальная область видимости и время жизни переменных Возможность передачи в метод переменного количества параметров Пример кода, иллюстрирующий возможность передачи в метод переменного количества параметров: Код class Test {   static void F(params int[] args) {     // обработка параметров   }   static void Main() {     F();     F(1);     F(1, 2);     F(1, 2, 3);     F(new int[] {1, 2, 3, 4});   } } В Delphi отсутствие переменного количества параметров можно частично скомпенсировать либо использованием значений параметров по умолчанию, либо передачей в качестве параметра открытого массива. Однако в первом случае все равно количество параметров ограничено и должно быть определено при написании соответствующей подпрограммы. Во втором же случае, хотя и наблюдается сходство с C#, есть существенные ограничения: нельзя передать пустой массив (т.е. массив с нулевым количеством элементов) передаваемый массив должен быть создан и заполнен или до вызова подпрограммы, или в момент вызова с помощью конструктора открытого массива неоднородные типы данных поддерживаются только при передаче вариантного открытого массива (впрочем, код разбора такого массива внутри подпрограммы обычно бывает довольно громоздким). Автоматическое удаление объектов При программировании в терминах объектов Delphi приходится постоянно учитывать, когда создаются объекты определенного класса и, что еще важнее, кто и когда их удаляет. Ситуация несколько упрощается при построении визуальных приложений и использовании компонентов - установив компонент на форму (или модуль данных), тем самым мы определяем механизм создания и удаления объектов соответствующего класса, когда форма-владелец создает объект в процессе своей инициализации и удаляет его в момент своего удаления. При построении невизуальных приложений (например, реализация бизнес-правил на промежуточном слое многоуровневого приложения) можно использовать механизм автоматического удаления COM-объектов или <интерфейсных> объектов (объектов, являющихся наследниками от TInterfacedObject). Впрочем, необходимо признать, что автоматическое удаление объектов в Delphi реализовано не лучшим образом, т.к.: приходится использовать две или даже три разные модели программирования для визуальных и невизуальных приложений (управление компонентами посредством формы-владельца, интерфейсные объекты, COM-объекты); при использовании COM-объектов отладка не является прозрачной с точки зрения объектной модели Delphi, т.к. в целях совместимости со стандартами OLE приходится соблюдать ряд ограничений, в т.ч. в вопросах генерации ошибок, совместимых с COM. Более того, <стандартные> объекты Delphi, которые часто используются при построении прикладных объектов, например, списки, стеки, битовые массивы и пр., не поддерживают механизм автоматического удаления, поэтому на практике приходится или использовать смешанную модель, в которой лишь некоторые объекты удаляются автоматически, или в целях стандартизации кода вообще отказываться от автоматического удаления. Рассмотрим простую семантическую конструкцию - загрузку списка объектов. В Delphi типичная реализация выглядят примерно так: Код procedure LoadList(aList: TObjectList); begin   aList.Clear;   // заполнение списка end; . . . try   MyObjectList = TObjectList.Create;   LoadList(MyObjectList);   // далее - использование объектов из списка finally   MyObjectList.Free; end; На самом деле из-за ограничений Delphi (TObjectList не может удаляться автоматически) семантика приведенного кода разбивается на две отдельные фазы: создать пустой список объектов заполнить список В C# аналогичное действие (загрузка списка объектов) реализуется проще и семантически точнее: Код class ListLoadTest {   Collection LoadList() {     Collection c = new Collection();     // непосредственная загрузка объектов и добавление их в коллекцию     return c;   }   static void Main() {     Collection c = LoadList();     foreach (MyObject in c) {       // что-то сделать с очередным объектом из списка     }   } } Строго говоря, в приведенном коде C# даже два преимущества: во-первых, не нужно думать об удалении списка объектов и его элементов (если бы в Delphi для хранения объектов вместо TObjectList использовался бы TList или просто массив, объекты пришлось бы удалять вручную) во-вторых, список объектов создается и заполняется в одном месте. Таким образом, довольно простая вещь - автоматическое удаление объектов, - позволяет писать более точный (семантически) и понятный код. Поля классов <только для чтения> В Delphi для того, чтобы реализовать концепцию <поле только для чтения>, можно использовать свойства (properties), при этом приходится писать нечто подобное: Код type   TMyObject = class   private     fData: integer   public     // эквивалент поля для чтения     property Data: integer read fData;   end; Поля <только для чтения> в C# введены на уровне языка: Код class A {   public readonly int Data; } Разница между (статическими) константами и полями <только для чтения> заключается в том, что если константы могут быть вычислены на стадии компиляции, что справедливо, например, для простых типов, то значения полей <только для чтения> определяются только на стадии выполнения программы. Это приводит к интересным последствиям. В стандарте C# рассматривается ситуация, когда имеется библиотека и использующая ее программа, компилируемые раздельно. Если в библиотеке использовать константу, то при изменении ее значения (и перекомпиляции библиотеки) нужно перекомпилировать и программу. Если же использовать поле <только для чтения>, то программу перекомпилировать не обязательно, т.к. значение поля определяется на стадии исполнения. Индексаторы В Delphi можно реализовать свойство класса типа массив и, установив для него атрибут default, получить некоторое подобие индексатора: Код type   TMyObject = class   public     property Items[Index: integer]: string read GetItem; default;   end; Тогда в коде можно использовать две эквивалентные конструкции: Код S := MyObject.Items[I]; S := MyObject[I]; Вторая строка как раз и демонстрирует основную идею индексаторов C# - возможность обращаться к объекту как к массиву. Однако в Delphi есть существенное ограничение - можно использовать только одно свойство (типа массива) по умолчанию. В C# можно реализовать произвольное количество индексаторов для класса: Код class A {   int this[int Index] { . . . }   string this[char Col, int Row] { . . . }   static void Main() {     A a = new A();     for (int i = 0; i < a.Count; i++)       Console.Writeln(a[i].ToString());     for (char c = 'a'; c < 'z'; c++)       for (int r = 1; r < 100; r++)         Console.Writeln(a[c, r]);   } } Делегаты В Delphi обработчики событий играют роль делегатов - <делегируют> реальную работу внешнему объекту. Однако из-за того, что Delphi является гибридным языком программирования, встречаются ситуации, когда семантически эквивалентные задачи реализуются разными способами. Так, например, в класса TList при сортировке используется указатель на функцию сравнения элементов: Код type TListSortCompare = function (Item1, Item2: Pointer): Integer; procedure Sort(Compare: TListSortCompare); Т.е. на самом деле задача сравнения элементов списка также <делегируется> функции, внешней по отношению к объекту TList. Такая семантическая неоднозначность отнюдь не упрощает программирование. В C# реализован более общий и однозначный подход - делегаты: Код delegate void SimpleDelegate(); class Test {   static void F() {     System.Console.WriteLine("Test.F");   }   static void Main() {     SimpleDelegate d = new SimpleDelegate(F);     d();   } } Причем в качестве реализации делегата может выступать как статический, так и обычный метод. Возможность реализации модели обработки событий <один-много> Хотя по умолчанию в C# компоненты реализуют схему подключения обработчиков событий <один-к-одному>, при необходимости может быть реализована модель <один-много>. Основа такой возможности заключается в том, что в качестве обработчиков событий используются делегаты, а их подключение к компоненту реализуется с помощью перегружаемого метода: Код class Control: Component {   // Unique keys for events   static readonly object mouseDownEventKey = new object();   static readonly object mouseUpEventKey = new object();   // Return event handler associated with key   protected delegate GetEventHandler(object key) {...}   // Add event handler associated with key   protected void AddEventHandler(object key, Delegate handler) {...}   // Remove event handler associated with key   protected void RemoveEventHandler(object key, Delegate handler) {...}   // MouseDown event   public event MouseEventHandler MouseDown {     add { AddEventHandler(mouseDownEventKey, value); }     remove { RemoveEventHandler(mouseDownEventKey, value); }   }   // MouseUp event   public event MouseEventHandler MouseUp {     add { AddEventHandler(mouseUpEventKey, value); }     remove { RemoveEventHandler(mouseUpEventKey, value); }   } } Приведенный код взят из спецификации C# и, хотя выглядит относительно объемным, прозрачно иллюстрирует возможность использования произвольного внутреннего механизма для хранения ссылок на обработчики и подключения произвольного количества внешних обработчиков. Цикл foreach Цикл foreach перенят в C# из Visual Basic. Получилась довольно удобная вещь: Код class Test {   static void Main() {     double[] values = {1.2, 2.3, 3.4, 4.5};     foreach (double elementValue in values)       Console.Write("{0} ", elementValue);   } } Семантически аналогичный код в Delphi выглядит более громоздким из-за необходимости использовать итератор (переменная I), а также (в общем случае) вычислять границы массива: Код procedure A; const Values: array [1..4] of double = (1.2, 2.3, 3.4, 4.5); var I: integer; begin   for I := Low(Values) to High(Values) do     ShowMessage(FloatToStr(Values[I])); end; Статические конструкторы Некоторый семантический аналог статическим конструкторам в Delphi - секция initialize. К сожалению, в Delphi порядок вызова секций initialize соответствует порядку подключения модулей. Такая практика может приводить к неожиданным ошибкам - первоначально рассчитывая на конкретный порядок подключения модулей, можно случайно в процессе разработки изменить этот порядок и в результате, например, получить обращение к несуществующему или некорректно инициализированному глобальному объекту программы. C# предоставляет более строгое объектное решение, которое, в частности, позволяет управлять правами доступа: Код class A {   static protected A GlobalA;   static A() { GlobalA = new A; } } В C# порядок работы статического конструктора определен только на уровне класса, при наличии же нескольких классов со статическими конструкторами порядок их активизации не фиксирован. Такой подход заставляет более тщательно проектировать программу с самого начала и исключает появление в последующем ошибок, аналогичных описанной выше. Операторы классов Операторы классов в C# почти эквивалентны операторам классов в C++: Код public class Digit {   byte value;   public Digit(byte value) {     if (value < 0 || value > 9) throw new ArgumentException();     this.value = value;   }   public static Digit operator+(Digit a, Digit b) {     return new Digit(a.value + b.value);   }   static public Main() {     Digit a = new Digit(5);     Digit b = new Digit(3);     Digit plus = a + b;   } } По сравнению с C++ в C# строго и однозначно определен порядок реализации пользовательских правил преобразования объектов (преобразования рассматриваются как частный случай операторов). Примечание: Delphi не имеет механизмов, эквивалентных операторам классов. Структуры Структуры в C# аналогичны записям в Delphi в том смысле, что являются данными, передаваемыми по значению, а не по ссылке. На самом деле семантика структур в C# ближе к классам, за исключением двух основных ограничений: структуры не могут быть абстрактными или содержать абстрактные методы; наследование от структур не поддерживается, в связи с чем методы структур не могут быть виртуальными. Пример структуры: Код struct Point {  public int x, y;  public Point(int x, int y) {     this.x = x;     this.y = y;  } } Использование структур может как повысить производительность программы (например, при размещении большого количества мелких объектов лучше использовать структуры), так и ухудшить ее (если используется структура, содержащая большие объемы данных, то при передаче ее в качестве параметра будет выполняться лишнее копирование). Существует эмпирическое правило: если объем данных меньше 16 байт, то для их хранения лучше использовать структуру, если больше - класс. Атрибуты Интереснейшая возможность C#, отсутствующая как в Delphi, так и в других наиболее популярных языках программирования (VB, C++, Java), - атрибуты: Код [Help("http://www.microsoft.com/.../Class1.htm")] public class Class1 {   [Help("http://www.microsoft.com/.../Class1.htm", Topic = "F")]   public void F() {} } Атрибуты похожи на свойства классов Delphi, за исключением того, что их значения устанавливаются на стадии компиляции и в процессе выполнения программы могут быть только считаны. Однако сфера применения атрибутов в поставляемой библиотеке классов CLR весьма широка - от хранения вспомогательной информации декларативного характера до обеспечения совместимости объектов .Net с COM (атрибуты совместимости с COM описаны в приложении B спецификации C#). Привычки, сформированные под влиянием Delphi, не позволяют даже сразу придумать, для чего можно использовать атрибуты, однако поле деятельности здесь просматривается широкое - от отслеживания версий алгоритмов до контроля за совместимостью программ. Возможность использовать русский язык для имен объектов программы В соответствии со спецификацией C# для именования объектов программы (классы, методы, переменные и пр.) используются символы Unicode. Отсюда следует (и реально проверено), что в качестве имен можно использовать русские названия, например: Код class ЭлементУчета {   public int readonly ИнвентарныйНомер;   public string readonly Наименование;   public double РассчитатьАмортизацию(int ЛетВЭксплуатации) { ... } } Конечно, использование русского языка в коде программы - вопрос спорный. Тем не менее, такая возможность есть. Использовать же ее или нет - вопрос стандартов написания кода в пределах рабочей группы (отдела, предприятия, корпорации). Заключение Безусловно, изложенные выше моменты не могут претендовать на абсолютную полноту и глубокую детализацию. Тем не менее, даже на их основе напрашивается естественный вывод - C# является весьма интересным языком программирования, по сравнению с Delphi во многих аспектах даже более мощным и в то же время строгим. Можно ли на нем писать реальные промышленные задачи? Если ориентироваться на монолитные приложения в стиле АРМ, то скорее всего нужно более детально проанализировать возможности исполнения программ .Net на конкретной аппаратной платформе (навряд ли Framework.Net сможет работать на 486 с 8М ОЗУ). Если же сделать акцент на многоуровневых приложениях, то C# для реализации промежуточного слоя по сравнению с Delphi является более перспективным кандидатом. Общий ответ на поставленный вопрос - писать реальные задачи на C# вполне можно, и, скорее всего, даже с меньшими затратами, чем на Delphi. Трудно ли дельфийцу освоить C#? Можно утверждать, что нет, т.к. в основе и Delphi, и C# лежит парадигма объектно-ориентированного программирования. Программист, который может в Delphi писать код в терминах объектов, а не только на уровне обработчиков стандартных компонентов, сможет писать и на C#. Впрочем, C# - не единственный язык, который можно использовать в .Net. Даже в штатной поставке Visual Studio .Net вместе с C# идет C++ и VB.Net, а вообще список языков программирования, реализованных для платформы .Net, уже на сегодня перевалил за десяток. Может быть, и Borland когда-нибудь выпустит Delphi.Net - не зря ведь <отцом> C# является как раз автор Delphi. Ждать ли дельфийцам выхода Delphi.Net? На этот вопрос может ответить только фирма Borland. На самом деле, если глубже поразбираться в вопросе декларируемой совместимости программ, написанных на Delphi 6 и Kylix, то оказывается, что о полной совместимости речь не идет - даже у одноименных классов VCL и CLX встречаются разные интерфейсы. Поэтому можно предположить, что Delphi.Net будет совместима с <обычной> Delphi тоже не на все 100%. В чем же тогда будет преимущество Delphi.Net перед тем же C#? Для <закостенелого> дельфийца - только в знакомом синтаксисе. Ну а пока Delphi.Net выйдет в свет, можно и C# освоить (тем более, что его корни лежат в C++, а C++ всегда считался более мощным языком, чем Pascal), или можно на VB.Net писать. Но делать это нужно уже СЕГОДНЯ. Источник http://www.gotdotnet.ru/LearnDotNet/CSharp/732.aspx

Автор: Medved 21.12.2004, 11:48

To же самое, но в другом стиле: Цитата Углубление в C#: опубликовано: 12.12.2001 19:27 интервью с ведущим разработчиком Microsoft - Андерсом Хейлсбергом (Anders Hejlsberg) В июле, редактор O`Reilly Джон Осборн посетил конференцию профессиональных разработчиков Microsoft, где взял интервью у Андерса Хейлсберга, выдающегося специалиста и ведущего разработчика C#, о платформе Microsoft .NET и языке программирования C#. Андерс Хейлсберг известен как человек, который разрабатывал Turbo Pascal, один из первых языков доступных на PC. Андерс лицензировал Turbo Pascal корпорации Borland и впоследствии возглавил команду, создавшую Delphi, действительно удачное визуальное средство разработки клиент-серверных приложений. Также в интервью принимали участие Тони Гудхью (Tony Goodhew) - Microsoft менеджер C#, и редактор раздела Windows в O`Reilly - Рон Петруша (Ron Petrusha). Осборн: Я уже читал статьи в прессе о C# [произносится C sharp] и отметил, что многие из них поддерживают предположение (или гипотезу), о том, что C# является клоном или замещением Java от Microsoft. Если вы бы писали заголовки, что бы вы сказали людям об этом языке? Хейлсберг: Во-первых, C# это не клон Java. Во время разработки C# мы смотрели на множество языков. Мы смотрели на C++, смотрели на Java, на Modula 2, C и SmallTalk. Существует много языков, имеющие основные идеи, такие же, как и те, которые использовали мы - например, полная объектная ориентированность, объектная простота и прочее. Одно из ключевых отличий С# от других языков, в частности Java, в том, что мы пытались как можно больше приблизиться к C++. C# наследует большинство операторов, ключевых слов и выражений напрямую из С++. Мы также включили несколько особенностей этого языка, которые были забыты в Java. К примеру, почему в Java нет перечислений (enums)? Я имею ввиду, в чем смысл их исключения? Перечисление - здоровая и имеющая смысл концепция в С++. Мы оставили перечисления и сделали их также защищенным типом. В C# перечисления не просто целые. Теперь это в действительности мощный тип, который наследуется от System.Enum в библиотеке базовых классов платформы .NET. Перечисление типа "foo" не может быть неявно преобразовано в перечисление типа "bar". Мне кажется это важное отличие. Мы также оставили оператор перегрузки и преобразования типов. Вся наша структура пространств имен очень близка к C++. Но в отличие от большинства традиционных языков, одним из наших ключевых достижений в разработке C# является его компонентная ориентированность, добавление в структуру языка всех концепций, которые могут понадобиться для написания компонентов. Такие концепции как опции (properties), методы, события, атрибуты, и документация являются конструкциями первого уровня в языке C#. Работа, которую мы проделали над атрибутами, особенностью используемой для добавления типизированных метаданных к любому объекту, является абсолютно новаторской. Я не видел подобного ни в каком другом языке. Также C# - первый язык работающий с XML тэгами комментариев, что может использоваться компилятором для создания документации прямо из исходного кода. Еще одна важная концепция, то что я называю "все покупки на одной остановке". Когда вы пишете программу на C#, вы пишете все в одном месте. Не требуется файлов заголовков, IDL (Interface Definition Language) файлов, GUID и запутанных интерфейсов. И как только вы напишете приложение, которое будет само себя описывать, вы сразу можете начать его внедрять, так как оно является самодостаточным блоком. Вы можете связать его с ASP и расположить в любом из окружений, даже там, где ранее это было невозможно. Вернемся к теме концепции компонентов. Было много споров о том, должны ли языки поддерживаться опции (properties) или события. Конечно, мы можем заменить эти концепции методами. Мы можем именовать паттерны как "get" и "set" блоки, которые заменяют использование опций. Мы можем использовать интерфейсы и адаптеры, которые реализуют интерфейс и обращаются к объекту. Мы можем это делать, также как мы можем писать объектно ориентированный код на C. Просто это сложнее и тут больше пыльной работы, а от этого в результате можно растерять все свои изначальные идеи. Просто мы думаем, что пришло время для языка, который позволяет легко создавать компоненты. Сегодня разработчики разрабатывают компонентное программное обеспечение. Они не пишут программы-монолиты или монолитные библиотеки классов. Каждый строит компонент, который наследован от другого базового компонента, поставляющегося некоторым окружением. Эти компоненты перекрывают некоторые методы и опции, реагируют на определенные события. Просто необходимо чтобы эти концепции входили уже в первые классы. Осборн: Вы не давно написали вступление к C#, и в первом же заголовке говорили: "Первый компонентно ориентированный язык в семействе C/С++." Хейлсберг: Да, это одно из моих главных достижений. Мы думали о том, как все что угодно превратить в объекты, и это имеет очень большое значение. В языках вроде SmallTalk и Lisp это было сделано и ранее, но тому была слишком большая цена. На мой взгляд в C# содержится ряд очень интересных новаций для облегчения разработки компонентов, например, понятие boxing и unboxing. Boxing позволяет значение простого типа преобразовывать в объект, в то время, как unboxing позволяет значению объекта быть представленным в виде значения простого типа. Не то чтобы это нигде раньше не встречалось, просто способ реализации этого в языке действительно новый и красивый. Проектируя C# и .NET framework, мы пытались не ставить себе недостижимых целей. Мы не можем позволить себе переписать все наши программы. Индустрия не может этого позволить, особенно сейчас, когда мы входим в эпоху Internet. Уже достигнуто многое, и очень важно обеспечить взаимодействие программ между собой. Мы обратили сильное внимание на предоставление программистам всех действительно хороших возможностей взаимодействия с Internet стандартами, такими как HTTP, HTML, XML, и с существующими Microsoft технологиями, так что сильно не удивляйтесь когда обнаружите нечто, не реализованное в новой платформе .NET, или когда поймете, что хотите опереться на какой-либо существующий API или компонент. Вы увидите, что все возможные взаимодействия с COM были встроены в язык и платформу. Вы увидите как просто вы можете импортировать существующие DLL, используя атрибут DllImport. В увидите, даже если никогда не будете это использовать, что мы определили понятие небезопасного (unsafe) кода. Небезопасный код позволяет вам писать встроенные C программы, использовать указатели, небезопасные приведения типов и распределение памяти, которое не приведет сбою при сборке мусора. Было много обсуждений по поводу небезопасного кода, многие считали нас наркоманами или что-то в этом духе. Я думаю, что это просто непонимание. То, что код помечен как небезопасный вовсе не означает, что его ничто не контролирует. Естественно мы не просто добавили небезопасные указатели и тем самым подставили людей, которые скачивают небезопасный код из Internet. Небезопасный код сильно связан с системой защиты. Мы даем вам возможность писать проверяемые блоки кода, а не сходить с ума в поисках другого языка программирования или системы программирования для native кода. А ограничивая небезопасный код блоками, мы можем добиться большей защищенности программ, так как система будет понимать, что именно происходит. Тот факт, что вы пишите небезопасный код вовсе не значит, что вы выходите из пространства проверок. Просто ваш небезопасный код становится более эффективным. Осборн: Расскажите поподробнее о том, как взаимодействует управляющая среда и небезопасный код. Хейлсберг: Одним из свойств, характеризующих окружения, управляющие выполнением, как в SmallTalk, Java, и .NET CLR (общая среда выполнения), является то что они обеспечивают сбор мусора. А чтобы обеспечить сбор мусора, а особенно с современными сборщиками мусора, вам необходимо знать о выполняемом коде больше, чем вы знали о традиционном неконтролируемом коде. Для того чтобы находить мертвые объекты методом исключения, вам необходимо прогуливаться по стэку, опускаться до самых корней, и выяснять какие объекты живут и какие больше не используются. Несмотря на то, делать это возможно, требуется более близкая связь между кодом, который вы выполняете. Код должен описывать многое. Нужно чтобы он говорил, как он расположен в стеке, где его локальные переменные и так далее. Когда вы пишете программу на C#, вы имеете возможность делать не типозащищенные операции, например, работа с указателями. Код, естественно, маркируется как небезопасный, но это не значит, что он будет запускаться в недоверяющей среде. Чтобы запустить код, вы должны заслужить доверия, если вы этого не сделаете - код запущен не будет. В этом отношении он не отличается от других примеров native кода. Настоящее различие заключается в том, что он все же выполняется в контролируемом пространстве. Методы, которые вы пишете, будут иметь таблицы описаний, они скажут вам какие объекты живы, и не придется пересекать границу порядка при переходе к этому коду. В отличие от этого, когда вы переходите к неописанному, неуправляемому коду (как например, в Java Native Interface), вам необходимо использовать специальные метки или воздвигать барьер в стэке. Вам нужно пересортировывать все аргументы, которые располагаются вне блока. Используя объект вам нужно быть предельно осторожным, так как СМ [Сборщик мусора], все еще работает в другом потоке (thread). Он может удалить объект, если вы не закрепили его надежно, использованием некоторого скрытого метода, делающего объект закрытым. Если же вы забудите сделать это - полагайтесь только на свою удачу. Мы применяем другой подход. Мы говорим: "Давайте обеспечим взаимодействие с языком. Давайте предложим фиксированные операторы, которые позволят вам закреплять объект, совместно с СМ". Путь по которому мы идем, позволяет оставить работать весь существующий код, вместо того чтобы просто его выкидывать. Это совершенно иной подход. Осборн: Так память, с которой мы работаем в небезопасных блоках, на самом деле просматривается сборщиком мусора? Хейлсберг: Да это так, но все это небезопасно. Вы можете получить указатель и сделать что-либо плохое. Но вы также можете сделать это в native коде. Осборн: Еще одна тема, требующая разъяснений: где кончается C# и начинается CLR (общая среда выполнения). Где проходит граница между нововведения C# и тем, что просто взято из CLR (общей среды выполнения) библиотеки. Хейлсберг: Я думаю этот вопрос имеет корни в том, что когда люди говорят о Java, никто себе полностью не представляет где там язык, а где среда выполнения. Что хотят сказать люди, говоря Java? Они имеют ввиду язык Java, синтаксис Java, или платформу Java. Люди сливают эти разные вещи в одно целое. Мы выбрали подход, который говорит о том, что мы желаем иметь многоязыковую платформу. Мы действительно разрабатываем платформу, которая позволит вам использовать множество языков, которые будут иметь одинаковый набор API. Давайте возьмем пример. Некоторым людям нравится программировать на COBOL, некоторым нравится на Basic, кто-то любит C++, и кто-то полюбит C#, я надеюсь. Мы не просим вас забыть о том, что вы делали раньше. Мы не говорим, что будет развиваться один язык, а с остальными ничего нового не произойдет. Мы говорим, что наша индустрия хороша своей гибкостью. Что произошло с Java? Это произошло потому, что были языки программирования до Java, будут и после нее. Мы хотим создать платформу, где вы будете выбирать, каким языком пользоваться, на основе своих собственных предпочтений. Мы хотим создать платформу, в которой это действительно будет новацией. Кто помогает COBOL программистам сегодня? Кто приглашает их в Web? Только на платформе .NET вы можете использовать Fujitsu COBOL для создания ASP страницы. На мой взгляд это действительно революционно. Осборн: Предоставляя возможность использовать множество языков на своей новой .NET платформе, почему вы выбрали именно C#, а не Visual Basic, С++ или даже COBOL? Что делает С# таким привлекательным? Хейлсберг: Во-первых с С# у нас была возможность начать все с чистого листа. У нас не было обязательств обратной совместимости, и это действительно сильно упрощало ситуацию. Даже не с точки зрения реализации, а с точки зрения использования. Например, мы имеем один вид классов в C#, и он может подвергаться сборке мусора. С++, напротив, имеет два, так как он придерживается стиля отсутствия сборки мусора. Так C# имеет несколько простых концепций которые вы понимаете. Языки - забавная штука. Это дело вкуса. Язык это почти религиозная вещь, и выбор стиля жизни для программистов. Я хочу сказать, что мы не в праве выйти и сказать: "Вот платформа, на которой вы имеете один базовый язык". Даже если вы можете сделать все что угодно на этой платформе, пользуясь этим одним языком, некоторым людям может не нравиться его синтаксис, им могут нравиться фигурные скобки или что-то другое в качестве разделителей блоков. Это то, к чему они привыкли. Это то, что позволяет им чувствовать себя как дома, и их продуктивность увеличивается. Наш подход к C# - быть альтернативой для программистов на C++, которые находят этот язык слишком сложным, и для программистов на Java, которые не довольны потерей некоторых особенностей C/C++ при переходе. Мы искали пути упрощения С++ и представили результат на многоязыковой платформе, которая предоставляет возможность более тесного межвзаимодействия и имеет все компонентные концепции. Гудхью: Проанализировав ситуацию, мы отметили один очень интересный факт - 60% разработчиков на профессиональном рынке используют два или более языков программирования для создания своих приложений. Мы поняли, особенно узнавая, какие именно средства разработки используются, что невозможно создать один объектно-ориентированный язык, который во всем устроит каждого. Как ранее заметил Андерс, люди используют разный синтаксис в соответствии с их собственными чувствами. Это личный выбор. И это то, для чего вся платформа .NET, дающая разработчикам право выбора - на каком языке писать. Мне кажется что бы сделали просто замечательную работу. Вы можете просто делать одни и те же вещи на Visual Basic, .NET, или C#. Visual Basic до сих пор видится, как наиболее доступный для программистов. C# дает больше свободы и мощности, чем VB. Осборн: Вы имеете ввиду, что в C# можно сделать больше с помощью меньшего количества операторов? Хейлсберг: Я имею ввиду, что вы имеете больше мощности благодаря предоставлению возможности писать небезопасный код. Осборн: А в VB нельзя писать небезопасный код? Хейлсберг: Нет, нельзя. Гудхью: Но на самом деле оба языка делают практически одно и то же. Есть значительные отличия от того, что было раньше, в Visual Studio 6. Используя Visual Studio 6.0, вы не могли написать многопоточный MTS объект на VB. Вам нужно было использовать С++. Теперь, на платформе .NET, вы можете использовать тот язык, который хотите. Хейлсберг: Это то, о чем я рассказывал в основное время этой конференции - унификация программных моделей, которую предлагает .NET. Развитие языков и платформ, мы всегда мечтали прекратить тесную связь между языком и конкретным API или конкретной формой программирования. VB был для быстрой разработки приложений, MFC были чем-то вроде подклассов, а ASP служили для выкладывания чего-либо на Web. К каждом случае, выбираемая вами модель программирования диктовала вам язык программирования и доступные API. Это добавляло в процесс ваших разработок головную боль от изучения новых языков и API, каждый раз когда вы перевыбирали платформу. Мы действительно попытались навести порядок. Мы предлагаем один API, одно средство визуальной разработки и право выбирать с каким языком работать. Осборн: Очень интересно что будет с скриптовыми языками, такими как JScript и VBScript? Хейлсберг: Одной из замечательных вещей, произошедшей со скриптами в .NET, является то, что они стали компилируемыми. Взгляните на ASP+. Теперь, вы в действительности запускаете откомпилированный код на своих страницах. Разработчики ASP+ могут использовать всю мощь VB.NET, вместо VBScript. Первое время, они имеют возможность использовать Perl и Python, или другие популярные языки, если захотят. Петруша: Server-side JavaScript будет компилироваться? Хейлсберг: Да, это так. Гудхью: Платформа .NET позволяет использовать скриптовые языки также, как и полноценные языки, так как они имеют доступ к действительной среде программирования и таким же API базовых классов. Вы должны увидеть что сделали парни, которые занимались реализацией JScript. За небольшими маловажными исключениями (для обратной совместимости), JScript - полная реализация ECMA стандарта. Таким образом, платформа .NET предоставляет межъязыковую среду, которая является большим прорывом для разработчиков скриптов. Осборн: Мы уже говорили о Java, C++ и скриптах. Здесь я слышал от многих людей, что в действительности нет разницы между .NET IL (IL это промежуточный язык Microsoft, который должны производить все компиляторы, для запуска на платформе .NET) и Java байт-кодом, который воспринимается виртуальной машиной Java (JVM). Из ваших слов понятно, что вы с этим не согласны. Не могли бы вы указать основные различия? Хейлсберг: Конечно. Во-первых, идея IL - очень старая идея. Вы можете найти ее в концепции UCSD Pascal p-машины (ранняя реализация Pascal для персональных компьютеров) или в SmallTalk p-коде, и использование в Basic и VB. Части Word, внутренне используют механизм p-кода, так как он более компактен. Так что p-код вовсе не нов. Я думаю, что подход, который мы применили в IL, интересен тем, что вы получаете дополнительные возможности контроля при преобразовании IL в native код. В С++ вы в действительности могли получать native код прямо из исходников. С++ может так же создавать IL, как и C# или VB. И когда вы устанавливаете код, мы даем вам возможность компилировать его на этом компьютере. Вы можете откомпилировать IL в native код определенного компьютера, и при запуске вы уже не будете иметь надстройки в виде JIT компиляции. Мы также предоставляем вам возможность запускать и компилировать код динамически - JIT компиляция. И конечно, присутствие IL добавляет возможностей, например, допустимость переноса на разные архитектуры процессора и предоставление проверки во время типовой защищенности, а далее построение системы безопасности поверх всего этого. Я думаю, что одно из главных отличий между нашей реализацией IL и Java байткодом в том, что мы приняли решение не делать интерпретаторов. Код, который мы запускаем, всегда native. Даже когда вы создаете IL, он никогда не будет интерпретироваться. Мы имеем даже разные стили JIT компиляции. Для небольшой платформы у нас есть EconoJIT, мы назвали его так, потому что это очень простой JIT [Прим. ред.: .NET Compact - это подмножество среды .NET, созданная для переноса на другие устройства и платформы.]. Для desctop версии мы создали более полный JIT, и у нас есть даже JIT, который дает такие же результаты как наш C++ компилятор. Так как он требует больше времени, вы могли бы использовать его во время установки ПО. Решение предпочесть запуск native кода интерпретации, оказало большое влияние на форму IL. Это поменяло набор включенных инструкций, и порядок их расположения. Если вы посмотрите на два IL, то сможете отметить, что они очень разные. Чувствуется, что наш IL нейтрален к типам. Нет информации в инструкциях, которая говорила бы о типах аргументов. Только подразумевается, что было положено в стэк. Этот подход делает IL более компактным. JIT компилятору в любом случае нужна эта информация, так что нет смысла хранить ее в инструкциях. Теперь вы знаете о некоторых разных решениях, которые позволяют проще переводить IL в native код. Осборн: Какие различия между интерпретацией и вашим подходом вы можете отметить? Хейлсберг: В основе интерпретации лежит цикл, берущий несколько байт из потока p-кода, и затем они отправляются к большому оператору переключения, который говорит: "это была операция сложения, теперь мы проходим через нее. Но этого не произошло" - и так далее. Интерпретатор эмулирует процессор. Мы переворачиваем это сверху вниз и выполняем один проход - мы всегда выполняем один проход, когда переводим инструкции в машинный код. Это машинный код в случае EconoJIT, в действительности очень прост - это просто набор вызовов и push инструкций, и вызовов помощников из среды выполнения. Естественно даже такой код запускается во много раз быстрее. Осборн: Так, давайте пройдем еще разок. Вы полностью компилируете код. Потом, когда вы закончите, будете иметь последовательность готовых к запуску битов. Однако в точке перевода IL в машинный код могут быть изменения. Хейлсберг: Да. Но потом, если это среда построенная в памяти на небольшом устройстве, мы можем выкинуть код после использования. Осборн: Возвращаясь назад к обсуждению синтаксиса языка: Меня интересует, включает ли C# встроенную поддержку регулярных выражений. Я не увидел ничего об этой поддержке в руководству по языку, но может быть она существует где-либо в другом месте. Хейлсберг: Во-первых, существует класс регулярных выражений в библиотеке базовых классов. У нас нет прямой поддержки регулярных выражений, но у нас есть некоторые возможности, которые в действительности очень похожи на это. Не стоит уделять этому много внимания, но например, мы даем возможность писать дословные строковые литералы, где вам не нужно ставить два обратных слэша, каждый раз когда вы хотите поставить один. Это очень полезно когда вы используете регулярные выражения или когда вы пишите кавычки в кавычках. Это небольшая особенность очень помогает, и конечно ее основа находится в распределенной, на различные языки программирования, платформе .NET. Осборн: Кажется, существуют различия между тем, как нам следует смотреть на пространства имен в C# и Java. Концептуально это одно и тоже? Или они реализованы по разному? Хейлсберг: Концептуально да, но их реализации вовсе не похожи. В Java имена пакетов имеют также и физический смысл, который указывает на структуру директорий ваших исходных файлов. В C# мы имеем полное разделение между физическим расположением и логическим именованием, так, если вы вызовете ваше пространство имен, то ничего не произойдет в реальном физическом хранилище вашего кода. Это дает вам свободу располагать модули вместе в физических пакетах, не принуждая вас иметь соответствие в директориях. В самом языке, конечно, тоже существуют отличия. Так как в Java пакеты имеют также и физическую структуру, исходный файл должен располагаться в верной директории и иметь только один public класс или public тип. В виду того, что в C# нет такой связи физического и логического расположения, вы можете именовать свои исходные файлы как захотите. В каждом файле может содержаться несколько пространств имен и несколько public классов. Таким образом вы можете записать весь ваш исходный код в один файл или расположить его в нескольких маленьких. Концептуально во время компиляции происходит следующее - вы передаете все исходные файлы вашего проекта компилятору, а он уже решает что с ними делать. Осборн: У меня есть вопрос о настраиваемом программировании: Вы считаете, что это важная концепция и она должна быть частью объектно ориентированного языка. Если это так, то каковы ваши планы реализацию настраимового программирования, как части C#. Гудхью: Кое-что из того, что мы собирались включить в первый релиз, было создано - вопреки тому, что все думают о Microsoft - у нас нет неограниченных ресурсов. Мы приняли несколько трудных решений о том, что действительно будет в первом релизе. Осборн: Как много людей было вовлечено в разработку C#? Хейлсберг: Группа разработки языка состояла из четырех человек, компилятора - из пяти. Петруша: А всей платформы .NET? Хейлсберг: Очень много. Вся компания этим занималась. Гудхью: Во время разработки Visual Studio и платформы .NET, этим занимался легион примерно из тысячи человек. Туда входили программные менеджеры, разработчики и тестеры всех разделов продукта - окружений, сред разработки и выполнения, моделей программирования ASP и т.д.. Затем, такие люди как я, управляли всем этим. Хейлсберг: В отношении настроек, о которых вы спрашивали - Я определенно думаю, что это очень полезная концепция. Нужно отметить что все исследования настроек происходили в академии и индустрии. Шаблоны - решение для этой проблемы. Во время наших внутренних обсуждений мы решили, что хотели бы включить это в нашу новую платформу. Чего мы действительно хотим - чтобы среда выполнения понимала настройки. Это отличается от того, как некоторые прототипы настроек были построены. Возьмите понятие стирания (erasure) в Java, в действительности у системы нет никаких представлений о настройках. Имея понимание концепции настроек, как в CLR, множество языков могут добиться большей функциональности. Вы можете писать на C# настраиваемый класс, а другой человек в другом месте будет работать с ним, используя другой язык. Добавление настроек в среду выполнения, позволит вам делать некоторые вещи намного эффективнее. Установку настроек лучше всего производить во время выполнения. В C++, установка шаблонов происходила во время компиляции, а далее у вас было два варианта: или оставить свой код раздутым, или попытаться избавиться от раздутости во время компоновки. Но если у вас есть несколько приложений, вы можете забыть об этом. У вас просто будет раздутый код. Добавив понятие настроек в общую среду выполнения, она стала понимать, что когда приложение или компонент запрашивают у нее список всех "Foo", оно задает себе вопрос "Имею ли я на данный момент реализацию (код, создающийся при вызове настраиваемой функции, в зависимости от параметров) списка Foo?". Если это так, использует его. Так, если Foo тип, передаваемый по ссылке, то реализация может быть одна для всех ссылочных типов. Если же тип, передаваемый по значению (вроде int или float) - то для каждого типа будет своя реализация. Но только тогда, когда приложение запрашивает ее. Мы проделали всю основную работу, необходимую для добавления распознавания настроек в среду выполнения. Интересна связь между IL и распознаванием настроек. Если инструкции в IL содержат информацию о типах, например, если сложение это не сложение, а сложение int, сложение float или сложение double - у вас нет возможности настроек в таком случае. Наш формат IL вправду нейтрален к типам. И по причине нейтральности к типам, мы можем добавить возможность настроек позже, без каких-либо для нас проблем. Это одна из причин, почему наш IL выглядит иначе, нежели Java байткод. Он у нас нейтрален к типам. И инструкция сложение - это сложение двух элементов, находящихся вверху стэка. Это может быть преобразовано в иной код, когда настройки будут реализовываться. Осборн: Это доступно во всех языках платформы .NET? Хейлсберг: Да. Исследовательский центр Microsoft Research в Кэмбридже создала версии общей среды выполнения и компилятора C#, допускающие настройки. Мы ищем путь внедрения этого. Похоже что этого не произойдет в первом релизе. Но мы сейчас работаем над тем, чтоб убедиться, что не делаем каких-либо вещей в первом релизе, которые не восприняли бы картины настроек. Осборн: Когда вы планируете выпустить C#, платформу .NET и следующую версию Visual Studio? Гудхью: Мы уже раздали здесь обзорную версию технологии 6500 посетителям конференции. Мы собираемся некоторое время (2000 год) использовать beta версию, а далее, когда все будет готово, сделаем релиз. Одна из вещей, которую мы действительно проделали - это подробный анализ, того, как прошел релиз Windows 2000, и путей вовлечения некоторых клиентов в процесс разработки и распространения. В случае платформы .NET и Visual Studio, мы будем вновь работать с клиентами, чтобы понять, когда все это действительно будет готово к релизу. Пусть они скажут нам, когда продукт готов. И по причине того, что в процесс вовлечены реальные клиенты, продукт обещает быть качественным. Другой стороной этого процесса является приобретение некой неопределенности. Мы ориентируемся на качество продукта, а не просто выбираем дату выпуска. Осборн: Таким образом дату, когда будет написан весь код, вы заменяете датой, когда продукт будет готов работать? Гудхью: Да это так. Я думаю, что разработчики узнают релиз Visual Studio .NET, как один из наиболее качественных релизов за всю историю Microsoft. Осборн: Вы послали C# в ECMA. Является ли стандартизация действительно настолько важной? Хотите ли вы, чтобы C# был доступен на других платформах. Хейлсберг: Очень важно. Мы действительно хотим представить C# в индустрии настолько стандартизированным, насколько это возможно, поэтому мы и послали запрос в ECMA. Мы также надеемся найти в ECMA поддержку, для процесса создания общей языковой инфраструктуры, для языков, имеющих схожую сущность. Под общей инфраструктурой я имею ввиду общую специфицированную библиотеку классов, которую разные компании использующие разные платформы будут реализовывать, для ипользования в своих программах на своих платформах. Гудхью: Я хотел бы отметить, что мы используем подход действительно открытых стандартов, вместе с ECMA. Если ECMA стандартизует C# и CLI (Common Language Infrastructure - общая инфраструктура языков), результатом будет доступность в соответствии с лицензиями и копирайтами ECMA, которые действительно открыты. Любой человек мог бы лицензировать ECMA C# стандарт, его подмножество или надмножество, и не должен был бы платить за это деньги. Они могли бы взять это и реализовать на любой платформе или устройстве. Мы рассчитываем, что люди будут делать это. Это отличает нас от наших конкурентов, которые изучают стандарты, выглядывая тех, кто скопировал их собственные языки. Джон: О каком переносе на платформу, в инфраструктуре которой нет поддержки COM объектов, может идти речь? Хейлсберг: Это действительно возможно. COM вообще не нужен для стандартизации C# или CLI. C# имеет модель классов, которая богата сама по себе, а COM это всего лишь один из взглядов на то, как приложения могут взаимодействовать. Но ничего в основах C# или CLI не говорится о том, что это должен быть COM, GUID, HRESULT, Addref или Release. Ничего подобного. Общая среда выполнения .NET полностью исключает это. Но дает прекрасную возможность взаимодействия посредством COM, о котором я буду всегда думать как об очень важной особенности, по причинам ранее указанным. Но вовсе не необходимой. Гудхью: Я думаю, что некоторые из предыдущих вопросов имеют своей причиной то, что мы выпустили начальную версию руководства по языку, которая свободно доступна. Microsoft создала ее на встречах, где мы думали в первую очередь в терминах платформы Microsoft .NET. В результате мы ссылались на такие вещи, как COM и DLL, когда, например DLL одно из решений более глобальной проблемы - использование native кода на заданной платформе. Одна из выгод работы с организацией по стандартизации и работы с такими людьми, как IBM, с которыми мы создавали SOAP спецификацию, это то, что мы не делаем таких ссылок, которые затем будут нас ограничивать как, например, платформа COM в будущих версиях спецификаций. Как сказал Андерс, взаимодействие с COM и его поддержка очень важна для нас и для нынешних клиентов Microsoft. Я думаю, мы сделали полезную работу, включив поддержку COM в платформу .NET. Но люди из индустрии слышали много раз, как мы используем слова COM и DLL. Они заключили, что платформа .NET только для Windows, в чем они ошибаются. Хейлсберг: И мне кажется, что раз COM взаимодействие очень важно для Microsoft и для людей, которые занимаются разработками на платформе Microsoft, стандартизация C# и CLI должна позволить в других реализациях придать большее значение взаимодействию с платформой, на которой реализуется язык. Осборн: Вы не будете настаивать на понятиях "чистой C#" и "чистой .NET" реализации? Хейлсберг: Что такое "чистый"? Как много "чистых" Java приложений существует? Я думаю очень и очень мало. Но это числа. Давайте возьмем пример. Люди хотят использовать существующий код. Нельзя требовать от компаний, отказываться от имеющихся вещей. Гудхью: Был ли у вас шанс говорить с Роджером Сешионс (Roger Sessions) [прим.ред. Роджер Сешионс - президент ObjectWatch и автор COM+ and the Battle for the Middle Tier.] ? Осборн: Нет не было. Гудхью: Роджер занимался интересной частью спецификации EJB (Enterprise JavaBeans), которая говорила о допустимых для производителей расширениях. Расширения производителей содержат такие вещи, как управление транзакциями, которые очень важны в создании корпоративных систем, с точки зрения защиты, передачи сообщений и так далее. В статье Сешионс грубо перечисляет одиннадцать областей функциональности, которые допускаются в реализациях, зависимых от производителя. Если вы возьмете IBM Websphere, как свою EJB реализацию, код, EJB который вы будете писать, будет несомненно приковывать вас к Websphere. Так что разговоры о том, что Java "стопроцентно чиста" - не правда. Существует очень хорошее интервью с Джеймсом Гослингом (James Gosling) на сайте разработчиков IBM. Он говорит, что реальные "написал однажды - запускается везде", 100% "чистые" приложения - в действительности бестолковая идея, и вообще предмет маркетинга. Он сказал сгоряча: "Мы даже не думали, что у нас будет возможность переносить все это, и изначально ее не было". И это изобретатель языка говорит, что никакой "чистоты" при переносимости не существует. Осборн: Не оставили ли мы без внимания какие-либо важные особенности и новации C#, о которых вы хотели бы сказать? Хейлсберг: Есть одна вещь, касающаяся всей платформы .NET, и в частности C#. Это вопрос о создании распределенных приложений. Не так давно мы создавали связанные клинт-сервер приложения и объектные протоколы, такие как CORBA, IIOP, RMI, и пришедший позже DCOM. Такой тип программирования действительно подкрепляется EJB, реализующим основу для CORBA и RMI. Мы научились создавать эти хорошо связанные распределенные системы, но они не распространяемы. Они не распространяются по Web, так как они занимают свое место на сервере, и вы не можете просто переписать их на другой компьютер, положить их там и тем самым получить работающие копии. Когда мы впервые засели за разработку платформы .NET, мы сделали шаг назад и посмотрели, что в действительности происходит с Web. Он становится распределенным миром с хорошим сообщением, мы попытались понять, что это может дать нашей модели программирования. И мы начали разработку с самого начала опираясь на то, что в распределенное приложение соответствует модным свойствам - имеет повсеместные связки и независимость от конкретного места, что дает вам возможность распространения. И как только мы приняли такое решение, все изменилось. Это изменяет способы создания простых сервисов, структуры сообщений для взаимодействия, и даже меняет оформление пользовательского интерфейса. Это новая модель программирования. Мы решили использовать XML и SOAP, чтобы сделать эту модель рабочей. Они сильно интегрированы с .NET, и эта интеграция в основе каждого нашего решения, которые мы делали, создавая платформу .NET. И это не то, мимо чего вы могли бы пройти, или вернуться позже.

Автор: Dayana 22.12.2004, 23:16

Интересные статьи! Я на них не натыкалась в инете. Как раз сейчас изучаю C#. Полезно было почитать. А можно перенести эту тему в раздел .Net и закрепить ее наверху?

Автор: Medved 23.12.2004, 14:10

ОК.

Автор: Cheba 24.12.2004, 00:59

Pegas, а ведь Delphi на месте тоже не стоит. Я только начал ковырять Borland Developer Studio 2005 (v3 который). Там тоже есть интересные фишки. Вот, буквально за три минуты нашел. Нужна форма с двумя кнопками. и Копи-пейст. Ну, сами, думаю, разберетесь... Код unit Unit1; interface uses  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,  Dialogs, StdCtrls; type  TForm1 = class(TForm)    Button1: TButton;    Button2: TButton;    procedure Button2Click(Sender: TObject);    procedure Button1Click(Sender: TObject);    procedure FormCreate(Sender: TObject);  private    { Private declarations }    (*** возможность использовать русский язык для имен объектов программы ***)    заголовок: string;  public    { Public declarations }  end; var  Form1: TForm1; implementation {$R *.dfm} (*** foreach ***) procedure A; const  Values: array [1..4] of double = (1.2, 2.3, 3.4, 4.5); var  I: integer;  t: double; begin  for t in Values do     ShowMessage(FloatToStr(t)); end; procedure TForm1.FormCreate(Sender: TObject); begin end; procedure TForm1.Button1Click(Sender: TObject); begin  A; end; procedure TForm1.Button2Click(Sender: TObject); begin  (*** возможность использовать русский язык для имен объектов программы ***)  заголовок := 'Hello';  Caption := заголовок; end; end. И это все прекрасно компилится. И Даже работает.

Автор: Medved 28.12.2004, 00:15

Это хорошо. Но программировать на C# гораздо эффективней и бысрее чем в Delphi.

Автор: Quadri 11.1.2005, 15:26

Цитата Это хорошо. Но программировать на C# гораздо эффективней и бысрее чем в Delphi. Гораздо эффективней - что это значит - программа будет работать быстрее? быстрее чем в Delphi - имеется ввиду скорость разработки? Неужели?

Автор: AntonSaburov 11.1.2005, 15:37

Цитата(Quadri @ 11.1.2005, 15:26) Гораздо эффективней - что это значит - программа будет работать быстрее? быстрее чем в Delphi - имеется ввиду скорость разработки? Неужели? Ну то, что быстрее - это надо смотреть код на MSIL, который будет скомпилирован из Pascal. То, что разработка будет быстрее - тоже не факт, кому чем удобнее. Но как язык C# имеет явные удобства, которых нет в ObjectPascal. Переменные объявлять, цикл по коллекциям и спискам foreach. Хотя опять же это достаточно субъективное мнение. Кому-то нравиться чистый Си и всякие ОО ему до лампочки.

Автор: Cheba 11.1.2005, 17:46

Цитата(AntonSaburov @ 11.1.2005, 15:37) Но как язык C# имеет явные удобства, которых нет в ObjectPascal. Переменные объявлять, цикл по коллекциям и спискам foreach. Мда... А тремя постами выше о чем речь идет?

Автор: AntonSaburov 11.1.2005, 18:01

Цитата(Cheba @ 11.1.2005, 17:46) Мда... А тремя постами выше о чем речь идет? Не понял. Если я хочу ввести переменную для использования в цикле, то в Pascal мне надо бежать в начало функции и описывать прямо там. Это уже давняя болезнь. И она меня уже лично достает не первый год. foreach - тут лопухнулся, не смотрел. Согласен

Автор: Cheba 11.1.2005, 23:18

AntonSaburov Ох не знаю, не знаю... Как говорится, каждому свое... Я вот тут лабораторки сдавал по С++... СОбственно я его семестр как изучаю, а Delphi (pascal) с восьмого класа учу. Так это для меня такая проблема была - переменные... Сначала писал, как все сишники и как препод учил. Но потом забил на все и начал выписывать все перемменные в начале программы/функции. От хочшь верь, хочешь не верь, но сразу кучу ошибок нашел. Ну, не могу я так. Теряю я эти переменные. Хотя это скорее всего привычка...

Автор: dm9 12.1.2005, 05:58

Я тоже был фанатом Паскаля. Си я, честно говоря, толком не знаю, хотя с базовым синтаксисом, конечно, знаком. А вот на PHP кое-что пришлось пописать. Javascript вот тоже пробую. Честно скажу - после этих языков Delphi кажется жутко громоздким. Могу понять Пегаса про то, что на Delphi разработка идёт медленнее.

Автор: Ser9a 7.3.2005, 11:03

Все зависит не только от предподчтения разработчиков, но и от веяний рынков. Моя б воля вжизни с Дельфей не слез бы. Но надо значит надо. Delphi конечно на месте не стоит, но работодатели то смотрят в сторону Майкрософта.

Автор: Cr@$h 10.4.2005, 18:40

Цитата(Ser9a @ 7.3.2005, 11:03) Delphi конечно на месте не стоит, но работодатели то смотрят в сторону Майкрософта. Ага, щас. Все смотрят в сторону билдеров, как раз... но это уже

Автор: Balu 25.7.2005, 18:19

Цитата(Pegas @ 21.12.2004, 05:13) В C# не предусмотрено прямого эквивалента const-параметров. Тем не менее, в случае необходимости может быть построена семантически эквивалентная конструкция (аналогия вышеприведенному примеру): Код class ReadOnlyString {   ReadOnlyString(string S) { this.S = S; }   public readonly string S;   static void Test(ReadOnlyString s) { Console.Write(s.S); }   static void Main() {     string s = "проверка const-параметров";     ReadOnlyString.Test(new ReadOnlyString(s));   } } Приведенный код иллюстрирует использование классов-<оберток> (т.н. wrappers) и полей <только для чтения>. Это не совсем верно, константа определяется как: <область видимости> const <тип> название

Автор: Void 25.7.2005, 20:46

Balu Речь идет о том, что в C# нет понятия deep immutability. Т.е. если объект reference-типа содержит методы, изменяющие его состояние, то нет никаких способов, передав его в качестве параметра метода, защитить его от изменения. Приходиться писать wrapper.

Автор: sgi1981 15.7.2006, 00:00

А вот мне лично нравится ассемблер. Я много раз занимался тем, что переводил разные фрагменты программы в ассемблерные вставки, а переведенные фрагменты закомментировал. И программа выполнялась в 1.5 раза быстрее ! Потому что процессор выполнял мой код а не компилеровский.     Пускай там что хотят пишут про разные языки, про удобства или неудобства их использования, а мне как то по барабану какой там синтаксис. Железо не знает синтаксиса. Хех. Говорят. "А вот давайте посмотрим, как это сделано в C++, а как в C#". Ну давайте посмотрим. Смешно, блин, смотреть от мысли что все равно кристалл процессора выполняет микрооперации. Для тех кто не знает что такое микрооперация могу сообщить новость. Процессор декодирует машинные инструкции в микрооперации, то есть ещё больше разбивает код. Вот. так вот я как посмотрел в окно CPU и стало не в кайф - какой же там несовершенный код. В общем в цикле изменяющая свое значение переменная раз-поз-раз с каждым проходом цикла сохраняет его из регистра процессора в память и из памяти опять загружает в регистр. А зачем ? Ведь это значение могло бы хранится в регистре все время и этот регистр ничем не занят. Да и вообще много приемов есть оптимальности. Вот например, абсолютно параллельное выполнение целочисленных и вещественных команд. Эти два типа команд выполняются разными участками кристалла процессора и эти участки кристалла могут работать параллельно, если на конвеере АЛУ будут попеременно команды целоч. и вещественные. А команды расширения АЛУ SSE2 - это же вообще рулёз. За один такт выполняются сразу четыре арифметические операции или логические. Для тех кто незнаком вкратце объясню - операнды хрянятся в 128-разрядных XMM-регистрах в упакванном виде - 4 целых 32-битных числа может поместится. Вот допустим есть пара таких регистров, или регистр и 128-битная ячейка памяти. И есть команды для параллельного выполнения операций. Ускорение - в 4 раза. Ну куда там тем языкам ЯВУ до такого... ? Хотя фирма INTEL разработала свой компилятор для C под процессоры Pentium 4, и утверждает, что он учитывает всю специфику оптимизации по Пенёк. Ну так вот вы теперь можете мне ответить - не хочешь не пиши на C#. Правильно. А какой кайф от того, что понимаешь что твоя прога будет выполняться не АЛУ напрямую, а ещё через компилятор JIT проходить ? Так же не интересно. Я в общем привык писать под проц с мыслью о том что он не будет работать как мудак. А тут ещё 2 компилера... Ну в общем, что там Anders Hejlsberg про это думает ? Как там насчет быстродействия ? Весь кайф портится, не так ли ? Ответ тут только один. Надо писать DLL на Асм и связывать их с кодом на C#. Насчет отладки Асм-кода - даже не знаю пока хорошего решения. Наверно писать надо сначала в C++ а потом переводить в C#. Что худшего в C++ ? Генерится код в пол метра минимум, даже если на форме нет ни одного контрола. А по какой причине столько кода ? есть вероятность того, что он выполнится ? Microsoft стремится сделать программы кросплатформенными. .................................................

Автор: Medved 15.7.2006, 01:00

Цитата(sgi1981 @  15.7.2006,  03:00 ) А вот мне лично нравится ассемблер. ... Дружище! Один топик - один вопрос!  Не нарушайте пожалуйста правила форума.

Автор: mr.DUDA 15.7.2006, 11:37

Автор: Medved 15.7.2006, 15:36

Правила форума: можно прочитать вот здесть - http://forum.vingrad.ru/index.php?s=&act=SR&f=27

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)