Наиболее распространенные или порочные ошибки в разработке C# для опытных программистов на C++

1. Постоянное использование структур в пользу классов .
2. Постоянное использование параметров in, out и ref (это результат пункта 1).
3. Использование значений int в качестве условий ошибки вместо использования исключений
4. Использование виртуального ключевого слова вместо ключевого слова override .
5. Считается, что char - это 8-битное значение со знаком .

Думая, что "сборка мусора" = "Я никогда не нужно вообще беспокоиться о времени жизни объекта ". Например, открыть FileStream и забыть закрыть его.

Или:

1. Выделение большого количества объектов
2. Помещение их в большой глобальный словарь (обычно после «Я знаю, я сделаю кеш»)
3. Интересно, почему использование памяти приложением всегда увеличивается и никогда не отключается («но он должен собирать мусор!»)

Попытка реализовать корректность const в строке s.

• RAII vs IDispose
• тип значения vs тип ссылки (структура vs класс, упаковка распаковка и т. д.)

Вызов GC.Collect .

, используя Венгерская нотация и другие соглашения об именах C ++

private int m_iMyIntField;
class CWidget { ... }

Между прочим, компилятор C # имеет ряд эвристик для помощи опытному программисту C ++, который является начинающим программистом C #. Например, если вы скажете

int x[];

, компилятор поможет указать, что [] является частью типа в C #, поэтому вы, вероятно, имели в виду

int[] x;

C # также позволяет такие вещи, как размещение ненужных точек с запятой в конце объявления класса так что программисты на C ++, которые имеют такую ​​привычку, не укусили это.

Каждый раз записывает полное пространство имен.

Это нормально в C ++, когда вы набираете std :: this или boost :: that . Не так хорошо в C #, когда вы повсюду повторяете System.Windows.Forms.Whatever .

Один, который меня поразил, и я думаю, что у многих людей, не относящихся к C ++, происходила утечка памяти из-за зарегистрированных событий, поддерживающих объект в живых.

IDisposable с самого начала не понравился (и до сих пор, если честно), но совершенно очевидно, что это будет разница при переходе от нативного к управляемому коду, поэтому я не ожидал, что разработчики C ++ на самом деле столкнутся с , им это просто не понравится.

Путаница "передача по ссылке" и "ссылочный тип":

void GetAnArray(int input, ref string[] output);

(Сравните с C ++: void getAnArray (int input, std :: vector & output); )

Забыть указать модификаторы доступа для каждого члена класса.

Я видел, как многие программисты C ++ кодируют в стиле COM на C #, пытаясь справиться с недостатками языка. C # предоставляет много типобезопасной поддержки для ваших перечислений, и обычно есть более приятные API, чем P / Invoking обратно в C ++.

Другая вещь, которую я заметил, уловила большинство людей, - это то, что обобщенные шаблоны C # не являются шаблонами.