Что дает мне .NET, а Win32 - нет?
Используя ваши ответы и некоторые другие потоки, я написал это приглашение, которое хочу поделиться с вами. Я сделал снимок экрана, в котором вы можете увидеть:
- Белый: код последнего возврата
- Зеленый и отметка метки означают успех (код возврата равен 0)
- Красная и поперечная отметка означает ошибку (код возврата был> 0)
- (зеленый или красный): время выполнения последней команды в скобках
- (зеленый или красный): текущая дата ( \ t)
- (зеленый, если не root, красный, если корень): зарегистрированное имя пользователя
- (зеленый): имя сервера
- (синий): pwd и обычный $
Вот код, который нужно вставить в файл ~ / .bashrc:
function timer_now {
date +%s%N
}
function timer_start {
timer_start=${timer_start:-$(timer_now)}
}
function timer_stop {
local delta_us=$((($(timer_now) - $timer_start) / 1000))
local us=$((delta_us % 1000))
local ms=$(((delta_us / 1000) % 1000))
local s=$(((delta_us / 1000000) % 60))
local m=$(((delta_us / 60000000) % 60))
local h=$((delta_us / 3600000000))
# Goal: always show around 3 digits of accuracy
if ((h > 0)); then timer_show=${h}h${m}m
elif ((m > 0)); then timer_show=${m}m${s}s
elif ((s >= 10)); then timer_show=${s}.$((ms / 100))s
elif ((s > 0)); then timer_show=${s}.$(printf %03d $ms)s
elif ((ms >= 100)); then timer_show=${ms}ms
elif ((ms > 0)); then timer_show=${ms}.$((us / 100))ms
else timer_show=${us}us
fi
unset timer_start
}
set_prompt () {
Last_Command=$? # Must come first!
Blue='\[\e[01;34m\]'
White='\[\e[01;37m\]'
Red='\[\e[01;31m\]'
Green='\[\e[01;32m\]'
Reset='\[\e[00m\]'
FancyX='\342\234\227'
Checkmark='\342\234\223'
# Add a bright white exit status for the last command
PS1="$White\$? "
# If it was successful, print a green check mark. Otherwise, print
# a red X.
if [[ $Last_Command == 0 ]]; then
PS1+="$Green$Checkmark "
else
PS1+="$Red$FancyX "
fi
# Add the ellapsed time and current date
timer_stop
PS1+="($timer_show) \t "
# If root, just print the host in red. Otherwise, print the current user
# and host in green.
if [[ $EUID == 0 ]]; then
PS1+="$Red\\u$Green@\\h "
else
PS1+="$Green\\u@\\h "
fi
# Print the working directory and prompt marker in blue, and reset
# the text color to the default.
PS1+="$Blue\\w \\\$$Reset "
}
trap 'timer_start' DEBUG
PROMPT_COMMAND='set_prompt'
14 ответов
Ответ довольно прост: более высокий уровень абстракции и отделения от «реальных» вещей за кулисами. Вот почему .NET может быть реализован в других операционных системах.
На самом деле все это возможно без .NET, но нецелесообразно. Краткий пример: WCF в .NET предоставляет вам первоклассную платформу IPC и SOA, которую может использовать каждый. Он встроен в функционал. В win32 вы получаете такое же самокодирование со сторонними библиотеками или чем-то еще. База пользователей небольшая, у вас нет большого сообщества, которое поддерживает вас в решении ваших проблем, и его вообще сложно реализовать. .NET Framework дает вам все это из коробки.
Для огромного количества приложений .NET ускорит время разработки и сделает разработку просто дешевле.
Для специальных приложений верно обратное. Например, (почти) невозможно разрабатывать приложения реального времени с .NET, потому что сборщик мусора на уровне 2 замораживает все ваши потоки.
Дополнение:
.NET framework 4.5 включает расширенный сборщик мусора. Он включает многопоточную фоновую сборку мусора для сборщика мусора сервера (включается с помощью элемента
К сожалению, сборщик мусора Mono не настолько продвинут, поэтому базовое утверждение все еще верно для Mono.
Он включает многопоточную фоновую сборку мусора для сборщика мусора сервера (включается с помощью элементаК сожалению, сборщик мусора Mono не настолько продвинут, поэтому базовое утверждение все еще верно для Mono.
Он включает многопоточную фоновую сборку мусора для сборщика мусора сервера (включается с помощью элементаК сожалению, сборщик мусора Mono не настолько продвинут, поэтому базовое утверждение все еще верно для Mono.
Виртуальные машины, такие как .NET, очень хороши для кроссплатформенного кодирования. Если вы не выполняете никаких неуправляемых вызовов функций вне .NET, тогда он может работать везде, где поддерживается .NET.
Например, X-Box 360. Или Windows CE / Mobile / что угодно.
Он будет Это хорошо для разработчиков Microsoft и Windows, потому что устройства с низким энергопотреблением будут более эффективными с таким процессором, как ARM. ARM не будет запускать ваше приложение IA32 для Windows, но он будет запускать ваше приложение .NET после того, как MS завершит сборку .NET для ARM WinCE.
Java, конечно же, делает то же самое, и это лучше и более зрелая в кроссплатформенной поддержке, если это то, что вы хотите.
Я обнаружил, что редактор форм в Visual Studio Express 8 постоянно приводит к сбою всей IDE, когда я кодирую C ++ с .NET. Этого не происходит, когда я работаю на C ++ с простым Win32. Этого не происходит, когда я кодирую формы с помощью .NET и C #, поэтому я был вынужден больше никогда не использовать .NET, кроме как с C #.
Помимо того, что вы уже сделали ...
- .NET менее зависим от платформы (в mono он будет работать в Windows, Linux, OS X, BSD и т. Д.)
- Вы можете писать код .NET на VB, C #, C ++ и т. Д. И иметь модули, написанные на разных языках, и все они будут работать вместе без особых проблем.
На самом деле, я думаю, вы найдете .NET включает в себя множество функций Win32.
Когда я разрабатывал приложения для MS-DOS, я тоже задавался вопросом о разработке для Windows. Windows была интересной, но я чувствовал, что DOS более практична. Так было до тех пор, пока я не начал писать приложения для Windows и не заметил, что Windows API весьма полезен. Среда RAD, которую я использовал для Windows (Delphi), упростила для меня разработку красивого графического интерфейса для моего приложения. С Borland Pascal это было немного сложнее, хотя Turbo Vision действительно предоставил очень полезную среду для DOS. Когда около 8 лет назад был представлен .NET, я просто считал его большой библиотекой времени выполнения для приложений Windows, точно так же, как сама Windows была классной графической библиотекой для MS-DOS. Это не серебряная пуля или золотой молоток, которые помогут найти решения ваших проблем. Это просто то, что упрощает разработку.
Тем не менее, когда я сравниваю свои приложения для Windows с MS-DOS, я все еще чувствую, что DOS была еще более надежной. Но Windows дает мне гораздо больше возможностей делать с большой легкостью. То же самое относится и к сравнению .NET с WIN32. Просто стало легче развиваться.
Некоторые преимущества:
Поддержка нескольких языков. Теперь легко написать приложение на Delphi и использовать логику этого приложения в коде, написанном на VB. Больше никаких COM, никаких экзотических методов вызова - просто «Добавить ссылку», и это просто работает. В основном потому, что, как всегда, возникают некоторые проблемы, но проблемы с .NET практически отсутствуют по сравнению с COM.
Простота использования. В Win32 API каждый вызов должен содержать много кода инициализации. После инициализации вам обычно приходилось вызывать метод API с некоторыми флагами, чтобы знать, чего ожидать и как выделять буферы для этого вызова, а затем снова вызывать этот метод API с другими параметрами для фактического выполнения работы. В конце концов, там был какой-то код очистки. В .NET вы обычно просто вызываете какой-то метод, так как весь беспорядок был спрятан внутри.
.NET намного выше WinAPI. Так, сейчас Framework написан с использованием WinAPI, но через несколько лет (скажем, Windows 9?) это будет .NET Framework, который будет доступен ядру. Устаревшие приложения будут использовать какой-нибудь унаследованный переводчик - WinAPI, написанный на .NET Framework.
.NET дает вам возможность писать хранимые процедуры Sql Server на реальных языках. Попробуйте сделать это в Win32 DLL.
WinAPI предназначен для взаимодействия с Windows на самом низком уровне и охватывает все функции, которые ОС Windows предоставляет потребителям.
.Net - это структура, среда выполнения и большая коллекция библиотек, которые служат разным целям и абстрагируются от Windows API. Он в основном предоставляет объектно-ориентированные абстракции, которые скрывают API Windows.
Если вы используете .Net, вы по-прежнему прозрачно используете WinAPI и можете использовать его напрямую, если захотите, через PInvoking в собственный API.
выбор .Net вместо WinAPI зависит от типа создаваемого приложения. Если это приложение с высокой степенью интеграции оболочки, используйте WinAPI, если нет, но вам нужно использовать мощные библиотеки XML, подключения (WCF), графические (WPF) или доступа к данным (ADO.Net, Linq) и требуется повышение производительности.
Я разрабатывал игры на C ++ около 8 лет, прежде чем переключился на веб-разработку на ASP.NET / ASP.NET MVC. С моей точки зрения, это наиболее важные преимущества при использовании .NET вместо собственного кода C ++:
- Очень хорошие инструменты IDE. Resharper может сделать гораздо больше, чем VisualAssist
- Больше никаких ошибок неверного / нулевого указателя или проблем с утечкой памяти
- Надежная среда выполнения с гораздо более приятным API, чем Win32
- Множество отличных библиотек .NET с открытым исходным кодом, более чем Я смог найти для C ++ (хотя C # Boost отсутствует)
- Благодаря Mono перенос вашего программного обеспечения на другую платформу проще, чем с C ++
Трудно ответить на этот вопрос, не зная больше о природе вашего приложения. Если это типичное внутреннее бизнес-приложение с большим количеством доступа к БД и генерации отчетов, я бы сказал, что .NET приносит много пользы. Если это, например, игра, обработка изображений или вообще что-то, что вы продаете широкому кругу клиентов, я бы остановился на Win32.
Простота использования. И легкая совместимость с остальной частью .NET framework (части, не связанные с Win32).
В .NET нет ничего волшебного, это просто огромное количество предопределенных классов для простого выполнения общих задач. И многие из этих задач похожи на «создать окно» или другие функции Win32.
Что касается того, что Win32 «простой и надежный», я так не думаю.
Вот замечательный пример: Один из самых Основные функциональные возможности, которые понадобятся программисту: Сообщение об ошибке, связанное с только что возникшей ошибкой:
http://msdn.microsoft.com/en-us/library/ms679351%28VS.85%29.aspx
- 7 параметров
- Две таблицы, которые необходимо прочитать, чтобы понять параметры
- Замечания по безопасности, которые необходимо учитывать
- Специальные специальные функции (LocalFree), которые должны быть вызваны для освобождения выделенного системой буфера.
Просто для достижения этой простой функциональности ? И это «прямолинейно»?
Win32 API - один из наихудших, наиболее запутанных и трудных в использовании (по крайней мере, правильно) существующих API. Единственное, что ему удается делать последовательно, - это делать простое, интуитивно понятное использование неправильным и требовать много усилий для достижения правильности.
Но, конечно, любой, кто ' Те, кто провел десять лет, работая с API, уже столкнулись с этими проблемами и привыкли к ним. Для вас это может быть не проблема. И даже лучше, поскольку у вас уже есть приложение, вы можете продолжать его использовать. Нет причин отказываться от этого и начинать заново в .NET
Но , если вы начинали проект с нуля сегодня, то
- Кривая обучения была бы намного проще в .NET (но Опять же, если вы уже прошли кривую обучения, это менее важно)
- Возможности ошибки будут уменьшены в .NET (гораздо труднее вызывать функции «неправильным» способом, и даже если вы это сделаете, меньше могут случиться плохие вещи)
- Было бы легче найти новых программистов, которые присоединились бы к вашей команде
- Большинство людей гораздо более продуктивно работают с таким языком, как C #, чем с C или C ++. Одна из главных вещей. NET предлагает возможность использовать языки .NET. По сравнению с этим библиотеку классов можно считать вишенкой на торте.
ИМХО, только тот, кто занимается разработкой Win32 более 15 лет, может назвать это простым и надежным. И если вы хотите написать все 250 000 строк самостоятельно, а не использовать компоненты, то, конечно, ваше приложение легко установится. Я не уверен, что компромисс того стоит.
.NET дает вам более быструю разработку по разным причинам. Более высокие абстракции, отличные компоненты для добавления, никаких проблем с указателями, меньше необходимости управлять собственной памятью или дескрипторами. Если вы разрабатываете Win32 15 лет, возможно, вам это не понадобится. Вы когда-нибудь нанимали молодых программистов? Я уверен, что они выучат .NET быстрее, чем Win32. В Win32 есть чему поучиться, прежде чем вы даже сможете сказать «Привет, мир».
Сама .NET фактически является оболочкой Win32 API, поэтому в принципе нет ничего, что вы могли бы сделать с .NET, чего не могли бы сделать с Win32 API. Преимущество .NET заключается в простоте разработки, что также означает более быструю доставку и меньшее количество ошибок. Возможности отладки в .NET также намного лучше.
Скорость установки и выполнения .NET не является большой проблемой. Вы можете написать дрянное программное обеспечение на любом языке, так же как вы можете написать хорошее программное обеспечение на любом языке. В .NET есть разные советы и приемы, чем в C ++ (так что это определенно кривая обучения), но, в конце концов, оба одинаково хороши.
I ' До нас дошли даже слухи, что хорошо написанная программа на C # на самом деле может быть быстрее, чем эквивалентная программа на C ++, потому что JIT-компилятор может оптимизировать сборку для конкретного процессора, в то время как оптимизатор C ++ может выполнять только общие оптимизации. Однако я не знаю, правда ли это.
Совместимость программного обеспечения .NET также похожа на C ++. С одной стороны, для этого требуется установка .NET framework, но с другой - больше не будет аду DLL из-за строгих имен и GAC. И многие вещи уже находятся в установке по умолчанию, для которой вам обычно требуются сторонние библиотеки на C ++ (например, синтаксический анализ XML, подключение к БД, веб-службы SOAP, RPC и т. Д.). Я думаю, что это уравновешивает, и меньший размер Исполняемые файлы .NET - определенно бонус.
Совместимость программного обеспечения .NET также аналогична C ++. С одной стороны, для этого требуется установка .NET framework, но с другой стороны - больше не будет аду DLL из-за строгих имен и GAC. И многие вещи уже находятся в установке по умолчанию, для которой вам обычно требуются сторонние библиотеки на C ++ (например, синтаксический анализ XML, подключение к БД, веб-службы SOAP, RPC и т. Д.). Я думаю, это уравновешивает, и меньший размер Исполняемые файлы .NET - определенно бонус.
Совместимость программного обеспечения .NET также аналогична C ++. С одной стороны, для этого требуется установка .NET framework, но с другой стороны - больше не будет аду DLL из-за строгих имен и GAC. И многие вещи уже находятся в установке по умолчанию, для которой вам обычно требуются сторонние библиотеки на C ++ (например, синтаксический анализ XML, подключение к БД, веб-службы SOAP, RPC и т. Д.). Я думаю, что это уравновешивает, и меньший размер Исполняемые файлы .NET - определенно бонус.