Разница между С# и С++

Привет всем,

до этого времени я как то программировал как любитель на С, и С++ ну и пробовал и другие языки. Но мне показалось что С++ самое надежное.
и решил сконнцентророваться на этот язык. недавно узнал о С# и разные дискусии на эту тему. Как я был информирован... С# это новоя находка Микрософта, с целью решить проблемы с технологией СОМ. вообщем это язык или среда где надежность Бинарной Компактности самое высокое..
я конкреткно в этом еще не разабрался.. но я думаю буду продолжать.. С++...
если, кто нибудь хорошо знает может мне обяснить... коротко и точно разницу.. между С++ и С#...не в том плане какой лучше а какой нет...просто какие свойства..

Заранее Благодарен..

(дочитай до конца, это правда ответ на твой вопрос)
Новая фишка Microsoft - .NET Framework. Это такая... хм... виртуальная машина что ли... Ну, вообще-то это просто набор стандартов, но если по-печному, это такая среда для исполнения программ, написаных на языке CIL (Common Intermediate Language). CIL - не язык вроде С++ или Паскаля, это такой машинный код, с тем лишь отличием, что машины, которая могла бы исполнять этот код, в природе не существует. Есть только _спецификация_, как должна работать эта машина. Есть спецификация на набор инструкций этого кода. Есть много всяких спецификаций вокруг этого всего.
Основная фишка вот в чем: CIL - язык _объектный_. То есть, если в процессорах x86, к примеру, есть команды типа сложить два числа, записать что-то в память и т.п., то в CIL есть прямо инструкции типа 'вызвать метод объекта'. Или: 'создать новый объект'. И в таком духе.
Дальше - больше. Как же исполнять такие программы, если аппаратного обеспечения для них нет и, скорее всего, не будет? А очень просто: надо их перед исполнением перевести в 'настоящий' машинный код (типа 'докомпилировать'). Причем вот что интересно: компиляция эта делается не программистом (типа как обычная компиляция из исходного кода), а самой операционной системой, причем прямо на лету. Запустил ты программу - а она на CIL написана. Операционная система это быстренько просекла, и рррраз - скомпилила обычный exe-шничек, сложила его в специальный кеш, и уже потом выполнила. Разумеется, такая бодяга происходит не каждый раз, а только однажды. А потом уже готовый скомпилированный код из того самого кеша берется.
Называется такая фигня гордо: 'двухфазная компиляция'. Или еще: 'Пи-код'. Или 'байт-код'. Или еще как-нибудь... Идею вообще-то придумал еще Вирт.

Нафиг огород городить, спросите вы? Плюсов тут до фига, и вот главные из них:
1) Многоплатформенность. Сам код на CIL не привязан к конкретному процессору или операционной системе, следовательно, если написать такой вот 'докомпилятор' (называется, кстати, JIT-компилятор, от Just In Time) для, к примеру, UNIX'а, то можно эти программы и на UNIX'е выполнять. И на чем угодно - хоть на кофеварке!
2) Оптимизация. Не секрет, что разные процессоры (да и разные ОС) заточены под разные нужды. Для разного аппаратного обеспечения эффективно применять разные техники генерации кода. Хорошие компиляторы (хороший пример - интеловские С-компиляторы) очень хорошо осведомлены об особенностях платформы и умеют генерировать офигительно эффективный код. Да вот беда: если программу скомпилировать под третий пень, она на нем просто летать будет, зато на пне первом даже медленно не пойдет - вообще не запустится. Приходится компилировать под самый старый процессор, теряя преимущества новых. А что же наши программки на CIL? А тут все как раз схвачено: коли мы программу 'докомпилируем' на каждом компьютере отдельно, то можно и оптимизировать _именно под этот данный конкретный компьютер_, со всеми его аппаратными и программными частями, все равно на другой компьютер скомпилированный код никогда не попадет. А то, что язык очень высокоуровневый (см. выше) дает гораздо больше возможностей для оптимизации.
3) Межъязыковое взаимодействие. Так как CIL - язык высокоуровневый (например, есть инструкция типа 'вызвать метод объекта'), программы, написанные на разных языках, но скомпилированные в CIL, могут прекрасно друг друга понимать: ведь исчезла специфика реализации хранения данных и вызова функций в разных компиляторах. Теперь вызов функции компилируется не в простыню машинного кода, который к тому же получается разный в разных компиляторах, а в одну инструкцию - 'вызов функции'. И на чем бы ни был написан исходный код, CIL-программа в результате

1

To Name_fa:
Спасибо за исчерпывающее объяснение.
Еще один маленьлий вопросик.
Допустим у меня установлен .NET и я разрабатываю в нем программы. После компиляции и первого запуска моя программа компилируется в оптимальный машинный код моей платформы. Если я хочу этот машинный код запустить на другом ПК, нужен ли .NET?

2Novichek:
Компиляция в машинный код происходит 'на лету' при каждом запуске программы. Этого можно избежать воспользовавшись утилитой ngen, создающей образ программы в машиином коде. Однако полученный образ не является обычным исполняемым файлом Windows и при попытке запуска выдает сообщение об ошибке. Так что перенести этот исполняемый файл на другую платформу не получится.

0

2bazil:

НЕТ, НЕ КАЖДЫЙ РАЗ!!! (сколько уже можно повторять?!), а только при первом запуске. Или если файл с кодом изменился с момента последней компиляции.

2Novichek:

Нет, не сможете, если только вы не крутой хакер. Дело в том, что в результате компиляции не получается полноценного исполняемого модуля. Даже более того: методы объектов компилируются отдельно, по мере надобности. И если какой-то метод никогда не вызывался, то он никогда и не будет скомпилирован.
Теоретически, поскольку получается все равно машинный код, его можно оттуда достать и заставить запускаться. Но это только если вы (как я уже писал) крутой хакер. Но даже в этом случае аналогичной процедуре придется подвергнуть все используемые библиотеки, а их даже в простенькой программе используется немало.

0

2Name_fa:

А ты не повторяй, а просто покажи где ты такое прочитал?

Я уже пару дней пытаюсь хоть в одной статье на MSDN найти фразу где говорится что JIT компиляция делается только один раз и вместо этого нахожу только фразы где говорится что это делается каждый раз. И именно поэтому и нужна утилита ngen.

0

2Name_fa:

Прочитай то что сам пишешь:

> методы объектов компилируются отдельно, по мере надобности.
> И если какой-то метод никогда не вызывался, то он
> никогда и не будет скомпилирован.
Как такое может быть если ты говоришь что компиляция в машинный происходит только один раз?

Вышеописанное поведение это как раз признак комиляции 'на лету' заново при каждом запуске.

0

To bazile:
Я тоже долго не мог 'врубиться' в эту загадочную компиляцию 'на лету'.
На http://www.gotdotnet.ru/ есть несколько неплохих статейек, проясняющих картину. (Архитектура .NET (обзор), Microsoft .NET Framework FAQ)
Напр. пишут:

Перед выполнением, MSIL преобразуется в машинный код. Он не интерпретируется.

или

Перед тем, как выполнять управляемый код CLR должен сначала скомпилировать управляемые MSIL инструкции в инструкции процессора. Здесь возникает типичная проблема: когда пользователь запускает программу, он не намерен ждать пока вся программа скомпилируется, тем более, что большинство функций программы не будут вызваны. Поэтому CLR, компилирует MSIL код в инструкции процессора, когда функции непосредственно вызваны. Всякий раз, когда такая функция вызывается в будущем, сразу выполняется машинный код (а компилятор уже не вовлекается в процесс).

To Novichek:
на том же http://www.gotdotnet.ru есть статья '.NET - Проблема распространения приложений', подробно описывающая данную проблему.

2Пернатый:

Что я не понял из ответа так это за какую точку зрения ты выступаешь?
То что JIT-компиляция происходит один раз или наоборот при каждом запуске?

> Перед выполнением, MSIL преобразуется в
> машинный код. Он не интерпретируется
> ...
> Перед тем, как выполнять управляемый код CLR должен
> сначала скомпилировать управляемые MSIL инструкции в инструкции
> процессора.
Само собой. Я никогда не пытался утверждать обратного

> Здесь возникает типичная проблема: когда пользователь
> запускает программу, он не намерен ждать пока вся
> программа скомпилируется, тем более, что большинство
> функций программы не будут вызваны. Поэтому CLR, компилирует
> MSIL код в инструкции процессора, когда функции непосредственно
> вызваны. Всякий раз, когда такая функция вызывается в будущем,
> сразу выполняется машинный код (а компилятор уже
> не вовлекается в процесс).
Все правильно. И так при каждом новом запуске программы. JIT-компиляция происхожит в динамически выделямых областях памяти из-за чего для отладки и профилирования .NET приложений существует отдельный набор API функций.

0

Компиляция-то в памяти происходит, а скомпилированный образ складывается в кеш на диске.
А то, что методы компилируются отдельно, вовсе не означает, что каждый раз заново. Просто каждый метод компилируется один раз при первом его вызове, а потом складывается в кеш. При последующих вызовах он просто берется из кеша (если он еще не в памяти)

0

2Name_fa
Еще раз прошу - скажи где ты такое прочитал?
Я понял твою точку зрения и считаю что ты заблуждаешься. Подверди свои слова доказательствами.

В свою очередь привожу выдержку из статьи 'Performance Considerations for Run-Time Technologies in the .NET Framework' с сайта MSDN.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp

When Does Code Get JITed?
Here is the path your code goes through when it is executed:

1. Your program is loaded, and a function table is initialized with pointers referencing the IL.

2. The Main method is JITed into native code, which is then run. Calls to functions get compiled into indirect function calls through the table.

3. When another method is called, the run time looks at the table to see if it points into JITed code.

a. If it has (perhaps it has been called from another call site, or has been precompiled), the control flow continues.

b. If not, the method is JITed and the table is updated.

4. As they are called, more and more methods are compiled into native code, and more entries in the table point into the growing pool of x86 instructions.

5. As the program runs, the JIT is called less and less often until everything is compiled.

6. A method is not JITed until it is called, and then it is never JITed again during the execution of the program. You only pay for what you use.

0

To basile:
Полностью согласен. Программа хранится в MSIL-коде и при каждом запуске компилирутся JIT-ом в PE-подобный код.
Альтернативы уже упоминались: 'ngen.exe' или 'install-time code generation mode'
Вообще это неплохо описано на MSDN: Compiling MSIL to Native Code
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconjitcompilation.asp

Там нигде не написано, что это происходит каждый раз.
Честно скажу: я не могу привести никаких доказательств, поскольку мой источник - устная беседа с компетентными лицами, а также экспериментальные данные. Однако я продолжаю настаивать на своей точке зрения.

0

To Name_fa:

попробуем пойти от обратного.
Допустим, что программа после первого запуска откомпилировалась и сохранилась в чистом машинном коде на диске. Тогда ее невозможно будет просмотреть ILDASM-ом.
Попробуйте.

Вы правы, что у .NET есть кэш на диске (так называемый native image cache). И Вы абсолютно правы, что когда программа запускается, откомпилированные ее части сохраняются в этом кэше и по при надобности не компилируются заново, а берутся в готовом виде из него.
Можно 'поселить' откопилированный образ программы самостоятельно в кэш, воспользовавшись Native Image Generator (Ngen.exe). С его же помощью можно посмотреть текущее содержимое кэша ngen.exe /show.

да там же ясно написано... программное ядро компилируется один раз, а остальные функции как бы 'подключаются'(компилятся) на лету. Если программа изменяется, то он опять перекомпилирует !ядро!, но не функцию, ибо они всегда компилятся при просьбе ядра ('то есть кликнул, а в ответ тишина' вовсе не значит что прога фигня, просто функция глючит или старый комп =))

ВоПРОС ко всем, кто-нибудь знает проект о разносе мелкомягкой заразы на Юних или Солярис

0

>> Тогда ее невозможно будет просмотреть ILDASM-ом.

Почему же невозможно? Сам-то IL-код при этом никуда не девается.

0