.NET для унаследованного разработчика VC ++ 6.0

Question

Каковы некоторые из лучших книг / подходов для изучения .NET для унаследованного разработчика VC ++ 6.0? Я не решаюсь изучать новый язык, такой как C # или VB.NET, по разным причинам. У меня есть опыт программирования на C ++ / Win32. Я более склонен изучать C ++ / CLI, чтобы получить опыт разработки .NET. Это хороший подход? Что вы сделали, чтобы сделать .NET погружение? Вы должны были изучить C # или VB? Я также планирую получить одну из следующих книг для того же самого. Есть идеи / мысли?

1. http://www.amazon.com/reader/1430210532?encoding=UTF8&ref=sib_dp_bod_toc&page=5#reader
2. http://www.amazon.com/Foundations-CLI-Visual-Language-Experts/dp/1430210230/ref=pd_bxgy_b_text_b

Answer 1

Не бойся C #. Как бывший программист C ++ (и я думаю, что вы найдете это в большинстве случаев), я нашел переход на C # очень удобным. Ваш образ мышления (если вы захотите) будет хорошо переведен с помощью всего лишь нескольких модификаций. Есть некоторые странности в языке, но по мере того, как мы перешли с C # 1 на C # 3, вещи стали еще ближе к тому, как разработчик C ++ может взглянуть на мир (например, дженерики). Я бы проверил виртуальные лаборатории на C # . Они довольно приличные и позволяют быстро освоить язык.

Answer 2

Если вы хотите использовать .NET со своими программами, вам, вероятно, лучше изучать C #. С помощью макросов и пользовательских определений операторов C ++ / CLI действительно является совершенно новым языком.

C ++ / CLI лучше всего подходит для сценариев взаимодействия с нативной библиотекой, которые слишком сложны для обработки C # / pinvoke.

Некоторые интересные вещи о переходе с C ++ на C #:

1. Это управляемый код, поэтому у вас нет удалить ваши указатели.
2. В C ++ вы можете выбрать создание экземпляра типа в стеке или в куче в зависимости от того, как вы объявляете тип. В C # то, создается ли тип в стеке или в куче, зависит от самого типа, а не от того, как вы его объявляете: если тип происходит от ValueType, среда выполнения создает экземпляр типа в стеке. Если тип не является производным от ValueType, среда выполнения создает экземпляр типа в куче.
3. В C ++ структура и класс аналогичны, различие заключается только в видимости членов по умолчанию (по умолчанию структуры являются общедоступными, по умолчанию классы являются закрытыми). В C # структура представляет собой ValueType и имеет специальные правила, такие как отсутствие наследования.
4. В C ++ у вас есть множественное наследование; в C # у вас есть единичное наследование и возможность наследовать от интерфейсов. Интерфейсы в C # - это (по сути) чисто абстрактные типы в C ++.

Это еще не все, но это некоторые из распространенных ошибок. Вот хорошая статья с дополнительной информацией.

Answer 3

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

Существует небольшая легкая книга "Справочник по манипулированию текстом на C #", в которой вы познакомитесь с основным синтаксисом языка и научите вас некоторым полезным библиотекам обработки строк, которые вы будете использовать снова и снова. Затем вам нужно взять книгу, в которой рассказывается о новейших языковых возможностях, о которых обычно пишут книги о LINQ (например, LINQ in Action). Обе эти книги короткие, но полные хороших вещей.

После этого вы захотите получить книги, относящиеся к конкретному типу приложений (WPF, WinForms, ASP.NET и т. Д.). Это должно включать использование ADO.NET для доступа к базам данных из этого типа приложения.

Я занимался разработкой C / C ++ для Win32 каждые 5 лет, и сейчас я даже не думаю о возвращении. Я могу сделать гораздо больше с помощью платформы .Net.

Answer 4

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