Всю мою недолгою жизнь прогроммировал на Delphi, и вот в силу того что C++ Builder очень на дельфю смахивает , хотел спросить : как по вашему. что лучше?

QUOTE (MuratMusic @ Sep 21 2006, 10:13)

Известно также, что авторы языка C# учли опыт и взяли всё лучшее из C/C++, Java и даже Turbo Pascal/Delphi

Еще из Вижуал Бейсика.

 

Не знаю, в каком месте там переносимость. . Net - это скорее альтернатива обычному Виндоус-программированию, кривым MFC и кошмарному CОМ-у. Для Юникса и Макоси дотнета нет. Дотнет на сматртфонах я только на картинках видел.

QUOTE (ashoka @ Sep 24 2006, 11:14)

QUOTE (MuratMusic @ Sep 21 2006, 10:13) Известно также, что авторы языка C# учли опыт и взяли всё лучшее из C/C++, Java и даже Turbo Pascal/Delphi Еще из Вижуал Бейсика.   Не знаю, в каком месте там переносимость. . Net - это скорее альтернатива обычному Виндоус-программированию, кривым MFC и кошмарному CОМ-у. Для Юникса и Макоси дотнета нет. Дотнет на сматртфонах я только на картинках видел. А mono?

QUOTE (MuratMusic @ Sep 23 2006, 23:30)

QUOTE (P.L. @ Sep 23 2006, 09:43) но вот тезис что с++ куда-то в низкоуровневое программирование затаскивает мне лично не очень понятен, так что встречный вопрос - а низкий уровень это что? Низкоуровневое программирование в буквальном смысле - это ассемблерное (или даже на уровне двоичных кодов) программирование на уровне регистров и команд микропроцессора, на уровне реальных адресов памяти (чего не позволяет Windows, там адреса не привязаны напрямую к железу).   Более точно я бы выразился так. Я считаю, что C++ более близок к тонкостям взаимодействия разрабатываемой программы с операционной системой (с железом напрямую мешает во многом контактировать сама операционка, но это даже во благо), чем C#. За это приходится расплачиваться более громоздким кодом. казалось бы причём тут Лужков, тьфу, с++

QUOTE (MuratMusic @ Sep 21 2006, 11:13)

Вопрос к людям, имеющим опыт программирования в Visual Studio как на C++, так и на C#. Имеет ли смысл разрабатывать обычные программы (не расчитанные на сетевые соединения), отдавая предпочтение разработке на C# вместо C++ (если быстродействие программы не является важным фактором). Насколько быстрее разрабатываются среднестатистичные несетевые приложения на C# чем на C++. Что мне уже известно? Знаю, что C++ позволяет добиваться большего быстродействия из-за возможности программирования низкоуровневых операций. Известно также, что авторы языка C# учли опыт и взяли всё лучшее из C/C++, Java и даже Turbo Pascal/Delphi и постарались избежать выявленные с годами слабые стороны названных языков. Известно, что за переносимость приходится платить быстродействием, но сейчас быстродействие как фактор не всегда перевешивает быстроту разработки. Мной делается предположение, что в ближайшем будущем в компьютерах у большинства обычных пользователей смогут выполняться приложения, расчитанные на .NET.

C# частично избавляет от необходимости думать. Для многих программистов это практически единственная возможность наваять хоть что-то вменяемое.

QUOTE (anton_t @ Sep 24 2006, 12:26)

А mono?

Mono - поделка энтузиастов. До сих пор несовместима на уровне библиотек, Например, Windows,Forms не работают на никсах.

Предполагаю, что при компиляции C++ (а тем более C) программ компилятору значительно проще (более короткий путь) преобразовывать исходный код в команды микропроцессора по сравнению с C# (тем более, что в .NET перед компиляцией в машинный код программа компилируется ещё и в MSIL код). Например, деление по модулю (оператор %) в C/C++ допускается только для целочисленных значений (что очень напоминает особенности ассемблерных команд), в то время как C# позволяет делать эту же операцию и для типов с плавающей запятой (впрочем, процессорные/ассемблерные команды деления по модулю для плавающей арифметики скорее всего уже давно имеются в новом железе).

 

Тот факт, что при умножении двух 8-разрядных целых чисел мы получаем в C# те же сюрпризы как и в асме и C/C++ (то есть мы должны заранее сами заботиться о том, чтобы результат умножения помещался как минимум в 16-разрядную переменную), этот факт наводит меня на мысль, что разработчики-авторы C# всё-таки старались сохранить близость компилятора этого языка к командам процессора.

 

Немного на тему низкого уровня:

 

Что меня однажды насторожило в ассемблерных вставках asm { ... } для C++? Я изменил содержимое регистра eax ради эксперимента. Запустил полученный exe-файл и комп как ни в чём не бывало продолжал работать дальше. Когда я сделал то же самое с помощью известного отладчика SoftICE, тогда комп внезапно показал мне "синий экран смерти", пришлось нажимать RESET. Я испытал трепет восхищения к мощи SoftICE, значит я действительно смог командовать микропроцессором напрямую. Почему этого не произошло с помощью ассемблерных вставок в Visual C++? Для меня это загадка. Может быть Visual Studio безопасно эмулирует операции с регистрами, либо автоматически возвращает состояние регистров процессора в начальное состояние при выходе из asm { ... }. Кто знает, напишите пожалуйста, если есть время.

QUOTE (P.L. @ Sep 24 2006, 12:37)

QUOTE (MuratMusic @ Sep 23 2006, 23:30) QUOTE (P.L. @ Sep 23 2006, 09:43) но вот тезис что с++ куда-то в низкоуровневое программирование затаскивает мне лично не очень понятен, так что встречный вопрос - а низкий уровень это что? Низкоуровневое программирование в буквальном смысле - это ассемблерное (или даже на уровне двоичных кодов) программирование на уровне регистров и команд микропроцессора, на уровне реальных адресов памяти (чего не позволяет Windows, там адреса не привязаны напрямую к железу).   Более точно я бы выразился так. Я считаю, что C++ более близок к тонкостям взаимодействия разрабатываемой программы с операционной системой (с железом напрямую мешает во многом контактировать сама операционка, но это даже во благо), чем C#. За это приходится расплачиваться более громоздким кодом. казалось бы причём тут Лужков, тьфу, с++ При чём тут C++? Вы имели в виду "при чём тут связь C++ с низкоуровневостью"?   Ведь мы имеем право считать Delphi или Visual Basic языками более высокого уровня, чем C++? Лично я так считаю по причине того, что Delphi или Visual Basic в большей степени чем C++ ограждают разработчиков от необходимости вникать в мельчайшие тонкости взаимодействия программы с операционнкой.   В общем я думаю, что низкоуровневость в буквальном смысле - это регистры и система команд процессора. А если говорится "более низкоуровневый", то я полагаю, что это означает "поближе к машине (или даже операционке) и подальше от удобных абстракций".

Изменено 24 сентября, 200619 г. пользователем Гость

QUOTE (MuratMusic @ Sep 25 2006, 00:24)

Немного на тему низкого уровня: Что меня однажды насторожило в ассемблерных вставках asm { ... } для C++? Я изменил содержимое регистра eax ради эксперимента. Запустил полученный exe-файл и комп как ни в чём не бывало продолжал работать дальше. Когда я сделал то же самое с помощью известного отладчика SoftICE, тогда комп внезапно показал мне "синий экран смерти", пришлось нажимать RESET. Я испытал трепет восхищения к мощи SoftICE, значит я действительно смог командовать микропроцессором напрямую. Почему этого не произошло с помощью ассемблерных вставок в Visual C++? Для меня это загадка. Может быть Visual Studio безопасно эмулирует операции с регистрами, либо автоматически возвращает состояние регистров процессора в начальное состояние при выходе из asm { ... }. Кто знает, напишите пожалуйста, если есть время.

Просто SoftICE - отладчик уровня ядра. А твой код, скорее всего, выполнялся на уровне пользователя.

QUOTE (ashoka @ Sep 24 2006, 16:15)

QUOTE (anton_t @ Sep 24 2006, 12:26) А mono? Mono - поделка энтузиастов. До сих пор несовместима на уровне библиотек, Например, Windows,Forms не работают на никсах. Говорят ASP.NET у моно вполне приличный.

QUOTE (Gesser @ The Cat,Sep 24 2006, 13:49)

C# частично избавляет от необходимости думать. Для многих программистов это практически единственная возможность наваять хоть что-то вменяемое.

От необходимости о чём думать избавляет C#?

QUOTE (MuratMusic @ Sep 25 2006, 01:24)

Кто знает, напишите пожалуйста, если есть время.

Я не буду комментировать весь тот бред, который ты понаписал. Скажу тебе лишь то, что деление по модулю обеспечивается не таинственными изобретениями Майкрософта а сопроцессором, который на современных архитектурах уже не выделяется просто в отдельную железку - но сохраняет, так сказать, "интерфейс". Этот самый сопроцессор и делит, и умножает, и косинусы-синусы берёт и много чего ещё делает с чиселками, в которых чёрт знает где плавает запятая %)

 

Что касается размера переменной: мы живём в реальном мире, где эти грёбаные чиселки пишутся в оперативную память компа, на винчестер и т.п. Если компилятор будет думать за тебя, сколько памяти бы отожрать на нужды общества, то в большинстве случаев быстродействие будет ещё более удручающим, нежели в случае Java/C#.

 

Вообще, я всегда считал, что оценка максимального-минимального значения в переменной должно выполняться в мозжечке программиста за сотые доли секунды. И выбор между char, short int, int, long и long long должен происходить автоматически и без напрягов.

 

А по части ручками менящегося значения в регистре - их восстановлением действительно может озаботится компилятор (хотя и не должен). Дай бог памяти, полгода назад правил целую плеяду ассемблерных вставок в сишный код, где в вычислеиях использовалось сразу куча регистров, в том числе и относительно служебный esp. Ну так вот, всё нормуль работало, если компилять gcc3x. А вот 4ый gcc решил, что нафиг надо пддерживать безолаберность программистов, вставлять лишние операнды при входе-выходе из блока и перестал заботится о том, что же там наменя.т в asm{}

QUOTE (MuratMusic @ Sep 25 2006, 01:30)

[Ведь мы имеем право считать Delphi или Visual Basic языками более высокого уровня, чем C++? Лично я так считаю по причине того, что Delphi или Visual Basic в большей степени чем C++ ограждают разработчиков от необходимости вникать в мельчайшие тонкости взаимодействия программы с операционнкой.

Ещё бы! Я же говорю - меньше думаешь, больше получаешь - но без искры божей разума человеческого, если можно так выразиться https://academ.club/html/emoticons/smile.gif Исскуственный интеллект пока ещё не изобрели, однако.

 

Тут, как я понимаю, речь вообще идёт за разработку десктопного софтваря. Так вот что я скажу: к чертям все эти интерпретаторы. Основной бонус интерпертируемых и интерпретируемых с промежуточной компиляцией языков в том, что легко и просто реализуется модификация кода в run-time режиме. Всё, что кроме, спокойно реализуется в рамках различных библиотек-фреймворков в С++. Какие-то лексические обороты, конечно, становятся чуть более нагромождены (ну, надо написать вместо шести символов десять, о ужас!). Но всё остальное работает превосходно, причём гораздо более качественней и не ограничивает программиста средой, операционкой и прочим

QUOTE (anton_t @ Sep 25 2006, 02:58)

QUOTE (Gesser @ The Cat,Sep 24 2006, 13:49) C# частично избавляет от необходимости думать. Для многих программистов это практически единственная возможность наваять хоть что-то вменяемое. От необходимости о чём думать избавляет C#? Вообще. Меньше думаешь, напрягаешся - больше рисуешь абстрактные механизмы, более лёгкие для восприятия неподготовленного человеческого разума.

QUOTE (anton_t @ Sep 25 2006, 01:55)

QUOTE (MuratMusic @ Sep 25 2006, 00:24) Немного на тему низкого уровня: Что меня однажды насторожило в ассемблерных вставках asm { ... } для C++? Я изменил содержимое регистра eax ради эксперимента. Запустил полученный exe-файл и комп как ни в чём не бывало продолжал работать дальше. Когда я сделал то же самое с помощью известного отладчика SoftICE, тогда комп внезапно показал мне "синий экран смерти", пришлось нажимать RESET. Я испытал трепет восхищения к мощи SoftICE, значит я действительно смог командовать микропроцессором напрямую. Почему этого не произошло с помощью ассемблерных вставок в Visual C++? Для меня это загадка. Может быть Visual Studio безопасно эмулирует операции с регистрами, либо автоматически возвращает состояние регистров процессора в начальное состояние при выходе из asm { ... }. Кто знает, напишите пожалуйста, если есть время. Просто SoftICE - отладчик уровня ядра. А твой код, скорее всего, выполнялся на уровне пользователя. Если мой exe-шник выполнялся на уровне пользователя, то почему тогда Windows мне не сообщила о том, что программа пыталась выполнить недопустимую операцию?   Может стоит снова попробовать установить у себя SoftICE, запустить его, потом запустить экспериментальный exe-файл (в котором в ассемблерной вставке меняется содержимое регистра eax), и с помощью SoftICE отследить как себя действительно поведёт регистр eax.   А ведь и в самой Visual Studio должно быть средство просмотра содержимого регистров процессора. Или нет (типа операционка ограничивает прямое воздействие на регистры, тогда зачем же в Visual C++ позволительны ассемблерные вставки???)?

QUOTE (Gesser, The Cat @ Sep 25 2006, 02:22)

Скажу тебе лишь то, что деление по модулю обеспечивается не таинственными изобретениями Майкрософта а сопроцессором, который на современных архитектурах уже не выделяется просто в отдельную железку - но сохраняет, так сказать, "интерфейс". Этот самый сопроцессор и делит, и умножает, и косинусы-синусы берёт и много чего ещё делает с чиселками, в которых чёрт знает где плавает запятая %)

Так я про то же самое и писал -> (впрочем, процессорные/ассемблерные команды деления по модулю для плавающей арифметики скорее всего уже давно имеются в новом железе). Под новым железом я и подразумевал процессор (как бы со встроенным сопроцессором).

 

А вообще спасибо за сочувствие и за интересные сведения https://academ.club/html/emoticons/smile.gif

 

Интересно, а Микрософт до сих пор решительно внедряет NET-совместимость в свои новые операционки типа ЛонгХорн или Виста (если не напутал названия)? Или их энтузиазм стал утихать насчёт NET?