грите шарп это просто?
а вот например обращение к сдрому, чтение геометрии, кроме конечно вми и апи, есть примеры?
а вот например обращение к сдрому, чтение геометрии, кроме конечно вми и апи, есть примеры?
» Самый перспективный язык программирования
simplexe, для системных вещей можно пользоваться DllExport'ом: использование функций API из C#. Причём всё managed 
segeich
C# отлавливает кучу багов в compile-time, а то и в design-time. Начиная от преобразования типов, заканчивая Exception'ами разными.
C# для домохозяек?
Позвольте не согласиться. C# - это индустриальный язык. Если бы не было потребности в нём (ну, быть может не в нём самом, а в технологии), то он не завоевал бы такую популярность.
segeich
C# отлавливает кучу багов в compile-time, а то и в design-time. Начиная от преобразования типов, заканчивая Exception'ами разными.
C# для домохозяек?
Позвольте не согласиться. C# - это индустриальный язык. Если бы не было потребности в нём (ну, быть может не в нём самом, а в технологии), то он не завоевал бы такую популярность.
Inochkin
Цитата:
Цитата:
ну вообще-то rtti никто не отменял
Цитата:
if(Param is A)MessageBox.Show("Parameter is A type");
if(Param is B)MessageBox.Show("Parameter is B type");
Цитата:
В С++ то же самое пришлось бы делать ловлей исключений при приведении типов,
ну вообще-то rtti никто не отменял
Цитата:
А как же Kylix???
Вы действительно думаете, что Kylix перспективен в nix??? Во-первых, его код так же громоздок, как код дельфей, во-вторых, он - если я не ошибаюсь - умеет работать только с Qt...
Добавлено:
Inochkin
Цитата:
Я всегда считал, что "смена" - это когда что-то заканчивается, а на его место приходит что-то другое. Потому и попросил привести пример технологии, разработанной Microsoft, которая "кончилась" и канула в лету.
Я имею в виду смену в плане, если угодно, популярности. Так или иначе в процессе продвижения некой технологии забываются другие. Забываются не значит исчезают, но эти понятия до боли близки.
Цитата:
Только лишний раз убеждаюсь в консервативности технарей)
Это не консервативность, это личные предпочтения и убеждения. Я не против 'реформ', я не против технических революций, но, имхо, все нововведения должны быть удачными.
Цитата:
Что-то я не уловил его мнения. Насколько я понял, он просто отказался его высказывать и предупредил, чтобы его не пытались переубеждать. Я не прав? Ну тогда прошу объяснить мне глубинный смысл этих слов.
Цитата:
If you want to write exclusively for the .Net platform, C# isn't the worst alternative, but remember that C++ is a strongly supported - though less strongly hyped - alternative on that platform.
WiseAlex
Цитата:
В приведенном контексте rtti - стрельба из пушки по воробьям. Здесь ИМХО разумнее просто сделать несколько процедур через полиморфизм.
Цитата:
ну вообще-то rtti никто не отменял
В приведенном контексте rtti - стрельба из пушки по воробьям. Здесь ИМХО разумнее просто сделать несколько процедур через полиморфизм.
Цитата:
simplexe, для системных вещей можно пользоваться DllExport'ом: использование функций API из C#. Причём всё managed
кроме конечно вми и апи, читайте внимательней, я прекрасно понимаю, что можно воспользоваться импортом, а в последствии и вми но без них не как
Inochkin
Цитата:
Ловко жонглируешь, однако
- C# + Windows Forms сравниваешь с голым C + WinAPI (который тоже отнюдь не С++ style). Ты уж либо в коде C# не используй Windows.Forms, либо в код С++ добавь что-нибудь вроде MFC, Qt и т.п.
- А try/catch ты не забыл в коде C# поставить? А то введет хитрый segeich буковки в окно edit'а и полетит твоя прога ко всем чертям
А теперь сравним:
Код: public void GetNum()
{
try {
int i = int.Parse(this.textbox.text);
}
catch (Exception e) {
// обработка ошибок
}
}
Цитата:
то же самое на c++, естессно, с использованием только винапи
Ловко жонглируешь, однако
- C# + Windows Forms сравниваешь с голым C + WinAPI (который тоже отнюдь не С++ style). Ты уж либо в коде C# не используй Windows.Forms, либо в код С++ добавь что-нибудь вроде MFC, Qt и т.п.
- А try/catch ты не забыл в коде C# поставить? А то введет хитрый segeich буковки в окно edit'а и полетит твоя прога ко всем чертям
А теперь сравним:
Код: public void GetNum()
{
try {
int i = int.Parse(this.textbox.text);
}
catch (Exception e) {
// обработка ошибок
}
}
Самым перспективным считаю C# под .NET. Однако, как сказал DesertFox
Цитата:
В общем, ИМХО, будущее за C#, настоящее за С++.
Цитата:
Перспективность необходимо оценивать для какого-либо конкретного направления..., т.е. C# скороее всего будет основным под новую версию Windows. ИМХО сыроват еще, (версию 2.0 я не видел еще). Однако, C++ еще ой как нескоро отомрет (если отомрет вообще). В некоторой степени на каждом языке основана какя-то технология (или наоборот). Например на основе C++ COM (DCOM), которые в освоении по моему достаточно сложны. C# как раз разраболтан под .NET. Насчет ассемблера... ну если писать только микрокоды. А так по словам людей работающих с программированием контроллеров на чистом асме уже врядли кто-то пишет. Есть же среды, которые например используют язык высокого уровня (с некоторыми расширениями), например С, и потом транслируют программу на ассемблер целевой машины.
В общем, ИМХО, будущее за C#, настоящее за С++.
Inochkin
Цитата:
Не только знаем, но и умеем. Если кто-то всерьез верит, что RTTI появилось сугубо в C#, то он, мягко говоря, неправ. RTTI в C++ было еще в 1995, когда C# и в проекте не было.
Ваш пример на C++ (найдите 10 отличий кроме синтаксических):
Код: class object {};
class A : public object {};
class B : public object {};
void C(object* Param)
{
std::cout << typeid(*Param).name() << std::endl;
}
Цитата:
Впрочем, если вы знаете более изящные решения на С++, то буду благодарен)
Не только знаем, но и умеем. Если кто-то всерьез верит, что RTTI появилось сугубо в C#, то он, мягко говоря, неправ. RTTI в C++ было еще в 1995, когда C# и в проекте не было.
Ваш пример на C++ (найдите 10 отличий кроме синтаксических):
Код: class object {};
class A : public object {};
class B : public object {};
void C(object* Param)
{
std::cout << typeid(*Param).name() << std::endl;
}
To: segeich...
Цитата:
... Это ИМХО несколько не то... Сборщик мусора в C# - это его неотъемлимая часть. В С++ же, такого нету в принципе. Все только ручками... "new" & "delete". Использование шаблонов - это тема не для новичков. Auto_ptr - это использование либо самописного шаблона либо шаблона из STL или аналогичной библиотеки типов. Уж новички шаблонами точно не скоро начинают пользоваться. Конечно использование auto_ptr в С++ одно из решений за контролем освобождения памяти, но не очень удобно то получается. В COM дык вообще замучаешься с вызовом AddRef и Release, а если еще где-то лишний раз сделаешь вызов AddRef, то начинаются непростые поиски того, почему объект не был уничтожен. C# лишен таких недостатков благодря сборщику мусора. Можно и в С++ реализовать сборщик мусора, но ИМХО, это достаточно не простая задача.
Цитата:
Что есть автоматическое распределение памяти? Если имеется ввиду освобождение памяти, то оно и С++ есть.
Код:
auto_ptr<T> p1(new T);
... Это ИМХО несколько не то... Сборщик мусора в C# - это его неотъемлимая часть. В С++ же, такого нету в принципе. Все только ручками... "new" & "delete". Использование шаблонов - это тема не для новичков. Auto_ptr - это использование либо самописного шаблона либо шаблона из STL или аналогичной библиотеки типов. Уж новички шаблонами точно не скоро начинают пользоваться. Конечно использование auto_ptr в С++ одно из решений за контролем освобождения памяти, но не очень удобно то получается. В COM дык вообще замучаешься с вызовом AddRef и Release, а если еще где-то лишний раз сделаешь вызов AddRef, то начинаются непростые поиски того, почему объект не был уничтожен. C# лишен таких недостатков благодря сборщику мусора. Можно и в С++ реализовать сборщик мусора, но ИМХО, это достаточно не простая задача.
DigiWhite
Цитата:
А зачем, когда они и так есть? Если хочешь непременно сам, читай Шилдта, Искусство программирования на C++.
Добавлено:
И ради бога, исправьте, наконец, в заголовке слово будующее!
Цитата:
Можно и в С++ реализовать сборщик мусора, но ИМХО, это достаточно не простая задача.
А зачем, когда они и так есть? Если хочешь непременно сам, читай Шилдта, Искусство программирования на C++.
Добавлено:
И ради бога, исправьте, наконец, в заголовке слово будующее!
Inochkin
Цитата:
Без проблем. Технология Win95.
На свякий случай объясняю: технология WinNT/2000/XP - это технология, пришедшая вместе с автором из DEC. Т.е. к Билли и его верным последователям никакого отношения не имеющая и не являющаяся развитием технологии Win95. Если вдруг не в курсе.
Кстати, очень трудно (мне например не удалось), найти в продукции MicroSoft технологию действительно разработанную Microsoft, а не чужую, купленную мелкомягкими и "развитую" до летального исхода (не все так "развиты", но на развал приличного продукта время нужно. IMHO Visual FoxPro - ближайший претендент на нирвану ). Потому примером может выступать только немногое, чей прототип тоже канул в Лету.
cainz
Цитата:
Ну ежели не видеть разницы между интерпретатором и компилятором, ежели послать нафиг отличия в синтаксисе и семантике, то все языки можно считать адаптированными модификациями С. В том числе и Лисп, Кобол, Фортран и кучу прочих древних. Так и будем называть: С-для-интернета, С-для-матричных уравнений, С-для-банков и т.п.
TheChampion
Цитата:
Не понял. Кто покойник-то? САМ Borland?
Цитата:
Потому и попросил привести пример технологии, разработанной Microsoft, которая "кончилась" и канула в лету.
Без проблем. Технология Win95.
На свякий случай объясняю: технология WinNT/2000/XP - это технология, пришедшая вместе с автором из DEC. Т.е. к Билли и его верным последователям никакого отношения не имеющая и не являющаяся развитием технологии Win95. Если вдруг не в курсе
. Кстати, очень трудно (мне например не удалось), найти в продукции MicroSoft технологию действительно разработанную Microsoft, а не чужую, купленную мелкомягкими и "развитую" до летального исхода (не все так "развиты", но на развал приличного продукта время нужно
. IMHO Visual FoxPro - ближайший претендент на нирвану ). Потому примером может выступать только немногое, чей прототип тоже канул в Лету. cainz
Цитата:
То-есть С стал стандартом. А для каждого специфического направления, для решения опеделенного типа задач существуют его адаптированніе модификации.
Ну ежели не видеть разницы между интерпретатором и компилятором, ежели послать нафиг отличия в синтаксисе и семантике, то все языки можно считать адаптированными модификациями С. В том числе и Лисп, Кобол, Фортран и кучу прочих древних. Так и будем называть: С-для-интернета, С-для-матричных уравнений, С-для-банков и т.п.
TheChampion
Цитата:
Отсюда все трудности с компоновкой приложений DirectX на компиляторах покойного ныне Borland'а.
Не понял. Кто покойник-то? САМ Borland?
DigiWhite
Цитата:
Это действительно один из самых серьезных недостатков с++ - его сложность (кстати как с точки зрения создания компиляторов - до сих пор нет полностью соответстветствующих стандарту компиляторов (см. 40 новых задач Саттера), так и с точки зрения освоения языка). С++ похож на естественный язык - есть язык улиц и язык Достоевского (в с++ это Иванов и Александреску)
Цитата:
Уж новички шаблонами точно не скоро начинают пользоваться.
Это действительно один из самых серьезных недостатков с++ - его сложность (кстати как с точки зрения создания компиляторов - до сих пор нет полностью соответстветствующих стандарту компиляторов (см. 40 новых задач Саттера), так и с точки зрения освоения языка). С++ похож на естественный язык - есть язык улиц и язык Достоевского (в с++ это Иванов и Александреску)
sk Asgard
Цитата:
Угу... если учесть, что C# язык новый, только только по сути появившийся. Может пока что у него нет такого большого количества возможностей, как например у С++ (например шаблоны). Однако щас уже есть версия 2.0, в которой появились аналоги шаблонов + многое другое.
Каждый язык предназначен для своих целей. По сути, каждый язык пропагандирует свою философию, а к ней нужно привыкнуть. Например, зная концепции ООП и программировать, придерживаясь этих концепций, я вообще никак не могу принять Lisp (да простят меня его последователи). Да, после С++ мне C# тоже не понравился, вообще не мог смириться с тем, что нет указателей, было не удобно то, что простые типы - тоже объекты и прочее. Так что, поживем увидим ИМХО. С++ тоже не сразу стал тем, что есть. Да и писать Win приложения, на C# достаточно удобно. Используя еще и Rational XDE под VS .NET, получается довольно таки мощный инструмент.
P.S.: по заверениям разработчиков, в С# попытались вобрать идее из Java и С++.
Мдя.. и давайте еще не забывать про область применения..., т.е. какие мы цели преследуем, то соответсвенно, выбираем наиболее подходящие для достижения этих целей инструменты.
Цитата:
Ни одного серьёзного. Так уж получилось, что пришлось переходить от родного и любимого мне nix программирования в win программирования. Естественно пришлось прочитать книжонку по шарпу, благо после жабы и С++ он дался без особого гимора. Честно говоря, не нравится он мне, шарп - это зло, имхо, Не хочу ни кого обидеть своим, возможно, слишком радикальным высказыванием, но, имхо, шарп - язык для домохозяек. На нём НЕ интересно программировать.
Угу... если учесть, что C# язык новый, только только по сути появившийся. Может пока что у него нет такого большого количества возможностей, как например у С++ (например шаблоны). Однако щас уже есть версия 2.0, в которой появились аналоги шаблонов + многое другое.
Каждый язык предназначен для своих целей. По сути, каждый язык пропагандирует свою философию, а к ней нужно привыкнуть. Например, зная концепции ООП и программировать, придерживаясь этих концепций, я вообще никак не могу принять Lisp (да простят меня его последователи). Да, после С++ мне C# тоже не понравился, вообще не мог смириться с тем, что нет указателей, было не удобно то, что простые типы - тоже объекты и прочее. Так что, поживем увидим ИМХО. С++ тоже не сразу стал тем, что есть. Да и писать Win приложения, на C# достаточно удобно. Используя еще и Rational XDE под VS .NET, получается довольно таки мощный инструмент.
P.S.: по заверениям разработчиков, в С# попытались вобрать идее из Java и С++.
Мдя.. и давайте еще не забывать про область применения..., т.е. какие мы цели преследуем, то соответсвенно, выбираем наиболее подходящие для достижения этих целей инструменты.
Ну вот. Отсутствовал один день, а уже накидали проблем) Имейте в виду, что исчезну до выходных, поэтому прошу меня сильно не пинать, пока буду отсутствовать, и считайте меня героем - лечу в ханты-мансийск, а там, говорят, комары как собаки)
Ну, по порядку.
simplexe
Ну что ж вы батенька, хотите от такого молодого языка. Не спешите. Видимо, это дело будет развиваться, так что дождетесь еще и классов для работы с CDROM. Мне вот тоже в Framework1.1 не хватает классов для COM-порта. Приходится пользоваться апишными функциями и пресловутым DllImport.
По поводу RTTI отвечу сразу всем: ну да ребята, я до вчерашнего дня не имел никакого представления о typeid и иже с ним. Но это говорит только о том, что мне пора бы все-таки найти время, чтобы полностью прочитать последний стандарт. Больше ни о чем. Но скажу вам честно - меня жутко пугает этот пдф на 1022 страницы. Впрочем, что говорить о языке, в котором "противоестественно соединены низкоуровневый и абстрактный подходы к программированию" (с) не помню чье, было в какой-то из приведенных мной ссылок. Естественно, такой язык будет невероятно громоздким. Впрочем, потихоньку прочитаем и такой стандарт, хотя и не скоро.
sk Asgard
Ну объясните мне, каким образом можно отдать предпочтение чему-то, зная хорошо только один вариант. Ведь вы же сами говорите, что не писали на C# ничего серьезного. А вы попробуйте. Те же самые паттерны, скажем синглетон, в сишарпе реализуются на уровне языка, если можно так назвать факт присутствия ключевого слова sealed. Я уверяю вас, вам понравится.
А вот мнение Страуструпа по поводу C# я все-таки не уловил. Ну вот убейте, а не могу я явно вывести из этой цитаты его отношение к языку. А читать между строк и строить догадки мне тоже не хочется.
2 Kuvaldum и все остальным, кто высказывался по поводу полиморфизма
Приведенный пример есть всего лишь пример с целью продемонстрировать удобство использования ключевого слова is (не забываем, что я не знал о существовании typeid). Никакого контекста там нет и не было. Пример был сляпан за две минуты и никакого отношения к реальности не имеет. Поэтому говорить о полиморфизме здесь не стоит - не тот случай, берегите свое красноречие.
Во-вторых. Скажите, если вам понадобится вывести пару отладочных окошек, вы действительно будете создавать "несколько процедур через полиморфизм"?
segeich
Признаю, малость сжульничал. Ну уж если по-честному, то давайте по-честному. Итак, вводим ограничение: только чистый язык, никаких библиотек, оберток и шаблонов. То есть заметьте: даже несмотря на то, что STL описана в стандарте, мы ею не пользуемся! Только средства языка! Второе ограничение: пишем весь код полностью. Третье: пишем работающий код, то есть чтобы его можно было откомпилировать, запустить и получить ожидаемый результат. Ну и четвертое - это критерии оценки: лаконичность кода и его соответствие принципам ООП. С точки зрения правильности проектирования код не рассматриваем. Итак:
Код:
namespace Example
{
public class ExampleClass
{
public ExampleClass()
{
}
private int Parse(string s)
{
try
{
return int.Parse(s);
}
catch{throw;}
}
public static void Main()
{
ExampleClass EC = new ExampleClass();
try
{
string a = "25";
EC.Parse(a);
a = "e25";
EC.Parse(a);
}
catch
{ //тут ошибка, но сообщение о ней вывести не можем поскольку действует ограничение 1
}
finally
{ //в принципе не нужно, но все равно напишу:)
}
}
}
}
Ну, по порядку.
simplexe
Ну что ж вы батенька, хотите от такого молодого языка. Не спешите. Видимо, это дело будет развиваться, так что дождетесь еще и классов для работы с CDROM. Мне вот тоже в Framework1.1 не хватает классов для COM-порта. Приходится пользоваться апишными функциями и пресловутым DllImport.
По поводу RTTI отвечу сразу всем: ну да ребята, я до вчерашнего дня не имел никакого представления о typeid и иже с ним. Но это говорит только о том, что мне пора бы все-таки найти время, чтобы полностью прочитать последний стандарт. Больше ни о чем. Но скажу вам честно - меня жутко пугает этот пдф на 1022 страницы. Впрочем, что говорить о языке, в котором "противоестественно соединены низкоуровневый и абстрактный подходы к программированию" (с) не помню чье, было в какой-то из приведенных мной ссылок. Естественно, такой язык будет невероятно громоздким. Впрочем, потихоньку прочитаем и такой стандарт, хотя и не скоро.
sk Asgard
Ну объясните мне, каким образом можно отдать предпочтение чему-то, зная хорошо только один вариант. Ведь вы же сами говорите, что не писали на C# ничего серьезного. А вы попробуйте. Те же самые паттерны, скажем синглетон, в сишарпе реализуются на уровне языка, если можно так назвать факт присутствия ключевого слова sealed. Я уверяю вас, вам понравится.
А вот мнение Страуструпа по поводу C# я все-таки не уловил. Ну вот убейте, а не могу я явно вывести из этой цитаты его отношение к языку. А читать между строк и строить догадки мне тоже не хочется.
2 Kuvaldum и все остальным, кто высказывался по поводу полиморфизма
Приведенный пример есть всего лишь пример с целью продемонстрировать удобство использования ключевого слова is (не забываем, что я не знал о существовании typeid). Никакого контекста там нет и не было. Пример был сляпан за две минуты и никакого отношения к реальности не имеет. Поэтому говорить о полиморфизме здесь не стоит - не тот случай, берегите свое красноречие.
Во-вторых. Скажите, если вам понадобится вывести пару отладочных окошек, вы действительно будете создавать "несколько процедур через полиморфизм"?
segeich
Признаю, малость сжульничал. Ну уж если по-честному, то давайте по-честному. Итак, вводим ограничение: только чистый язык, никаких библиотек, оберток и шаблонов. То есть заметьте: даже несмотря на то, что STL описана в стандарте, мы ею не пользуемся! Только средства языка! Второе ограничение: пишем весь код полностью. Третье: пишем работающий код, то есть чтобы его можно было откомпилировать, запустить и получить ожидаемый результат. Ну и четвертое - это критерии оценки: лаконичность кода и его соответствие принципам ООП. С точки зрения правильности проектирования код не рассматриваем. Итак:
Код:
namespace Example
{
public class ExampleClass
{
public ExampleClass()
{
}
private int Parse(string s)
{
try
{
return int.Parse(s);
}
catch{throw;}
}
public static void Main()
{
ExampleClass EC = new ExampleClass();
try
{
string a = "25";
EC.Parse(a);
a = "e25";
EC.Parse(a);
}
catch
{ //тут ошибка, но сообщение о ней вывести не можем поскольку действует ограничение 1
}
finally
{ //в принципе не нужно, но все равно напишу:)
}
}
}
}
К сожалению COM, а уж тем более COM+ очень уж сложны. Кстати, 98 Win, основан на технологии COM, а NT используют COM+.
От чего вас защитит C# (отвечая на приглашение багов в студию):
- в C++ любое число можно привести к указателю и вуаля. Буквально вчера сел за изучение WinAPI, смотрю как нарисовать белый фон - необходимо указать параметр типа HBRUSH (который является на самом деле HANDLE, который в свою очередь является typedef void *), так вот в примере делается (HBRUSH)COLOR_WINDOW (#define число какое-то). Застрелиться Нет, естественно это работает. Только представьте себе отладку подобного бага...
- допустим в C++ мы выделили память, и два указателя ссылаются на эту область. Потом в одном месте мы удалили память (free, delete) - во втором месте что? Нет, не Exception, там грязное чтение (хотя, конечно, можно этого избежать). В C# что? Так не получится просто-напросто.
Но эти все баги применимы, конечно же, только НЕ к специалистам (которые ну ооочень редко такие баги делают, а если и делают, у них опыта достаточно, чтобы не потратить на это очень много времени). C# от многого избавлен, точнее, он более защищён...
Win98 и WinNT имеют разные ядра (удивлены?). К сожалению ли, или к счастью, Microsoft обязана поддерживать старые продукты (ибо деньги за них уплочены), а следовательно в ядре присутствуют старые функции, оставшиеся от Win98, а в MSDN мы читаем "нежелательно пользоваться функцией, устарела" и т.п.
Конечно же, для разных целей разные средства. Хотите драйвер написать, тут вряд ли C# поможет (кстати, можно написать, только это не будет эффективным решением). Споры можно продолжать до бесконечности, но сейчас всё больше и больше прикладные приложения, приложения автоматизации бизнес-процессов и т.п. пишутся на высокоуровневых языках: Java и C#. C++ более дорог: хороший специалист ценится дороже. За Java и C# идёт неплохой довесок в виде различных Framework.
З.Ы. Очень мне нравится C - нравится простота (ну, относительная, конечно), нравится мне то, что можно делать, что хочу (почти ). Но вот C++ я сторонюсь - за долгие года из него сделали настоящего монстра. И чем мне нравится C# - люди посмотрели, что есть хорошего, что плохое, выкинули плохое (ну, если будет угодно, места, где больше всего ошибок), добавили новых фич и т.п.. В итоге мы получили стройный, красивый язык. И Java мне нравится, хотя, в виду длительного развития она обросла монстроватостью
- в C++ любое число можно привести к указателю и вуаля. Буквально вчера сел за изучение WinAPI, смотрю как нарисовать белый фон - необходимо указать параметр типа HBRUSH (который является на самом деле HANDLE, который в свою очередь является typedef void *), так вот в примере делается (HBRUSH)COLOR_WINDOW (#define число какое-то). Застрелиться
Нет, естественно это работает. Только представьте себе отладку подобного бага... - допустим в C++ мы выделили память, и два указателя ссылаются на эту область. Потом в одном месте мы удалили память (free, delete) - во втором месте что? Нет, не Exception, там грязное чтение (хотя, конечно, можно этого избежать). В C# что? Так не получится просто-напросто.
Но эти все баги применимы, конечно же, только НЕ к специалистам (которые ну ооочень редко такие баги делают, а если и делают, у них опыта достаточно, чтобы не потратить на это очень много времени). C# от многого избавлен, точнее, он более защищён...
Win98 и WinNT имеют разные ядра (удивлены?). К сожалению ли, или к счастью, Microsoft обязана поддерживать старые продукты (ибо деньги за них уплочены), а следовательно в ядре присутствуют старые функции, оставшиеся от Win98, а в MSDN мы читаем "нежелательно пользоваться функцией, устарела" и т.п.
Конечно же, для разных целей разные средства. Хотите драйвер написать, тут вряд ли C# поможет (кстати, можно написать, только это не будет эффективным решением). Споры можно продолжать до бесконечности, но сейчас всё больше и больше прикладные приложения, приложения автоматизации бизнес-процессов и т.п. пишутся на высокоуровневых языках: Java и C#. C++ более дорог: хороший специалист ценится дороже. За Java и C# идёт неплохой довесок в виде различных Framework.
З.Ы. Очень мне нравится C - нравится простота (ну, относительная, конечно), нравится мне то, что можно делать, что хочу (почти
). Но вот C++ я сторонюсь - за долгие года из него сделали настоящего монстра. И чем мне нравится C# - люди посмотрели, что есть хорошего, что плохое, выкинули плохое (ну, если будет угодно, места, где больше всего ошибок), добавили новых фич и т.п.. В итоге мы получили стройный, красивый язык. И Java мне нравится, хотя, в виду длительного развития она обросла монстроватостью Inochkin
Цитата:
Именно поэтому в нем всего 64 ключевых слова против 100(???) в C#.
Добавлено:
oSLikus
Цитата:
А заодно алгоритмы, итераторы и контейнеры... Класс! Вот и думаю --- нафиг вся эта байда с quicksort впереди! Да здравствует Vista и 512 МБайт только для ОС. Быстродействие все покроет...
Цитата:
На мой взгляд, самая большая проблема C++ в том, что это ну очень сложный язык.
Именно поэтому в нем всего 64 ключевых слова против 100(???) в C#.
Добавлено:
oSLikus
Цитата:
C# - люди посмотрели, что есть хорошего, что плохое, выкинули плохое
А заодно алгоритмы, итераторы и контейнеры... Класс! Вот и думаю --- нафиг вся эта байда с quicksort впереди! Да здравствует Vista и 512 МБайт только для ОС. Быстродействие все покроет...
Чтобы не говорили, в западном мире и Америке работодатели выбирают преимущественно 2 технологии J2EE(Java Enterprice Edition) и .NET для приложений масштабов крупных предприятий и банков. Вот теперь и думаем, какие и ТЕХНОЛОГИИ перспективные.
Именно технологии, потому что язык сам по себе ничего не стоит. Главное - идеология области применения. Можно ли на Java написать операционку? или наоборот на том же классическом C++ приложения с бизнес-логикой мощности Hibernate или Spring framework?
Почему так много программистов пишут на C++? Да потому что на территории бывшего CCCP в вузах преподают в самом начале C++ как основу, а дальше как повезет. Я о Java вообще ничего не знал, только когда пришел на работу в крупную IT-фирму и меня включили в проект на Java. Тонкостям синтаксиса обучился за неделю, а вот идеологию только через месяца 3.
PS из всех .NET'ных языков конечно флагманом является C#, но и он какой-то недоделанный C++ из Java - ни туда, ни сюда
Именно технологии, потому что язык сам по себе ничего не стоит. Главное - идеология области применения. Можно ли на Java написать операционку? или наоборот на том же классическом C++ приложения с бизнес-логикой мощности Hibernate или Spring framework?
Почему так много программистов пишут на C++? Да потому что на территории бывшего CCCP в вузах преподают в самом начале C++ как основу, а дальше как повезет. Я о Java вообще ничего не знал, только когда пришел на работу в крупную IT-фирму и меня включили в проект на Java. Тонкостям синтаксиса обучился за неделю, а вот идеологию только через месяца 3.
PS из всех .NET'ных языков конечно флагманом является C#, но и он какой-то недоделанный C++ из Java - ни туда, ни сюда
Быстродействие... Знаешь, вот у всех моих знакомых комп не ниже п3-1 ГГц. Вполне нормально там работают .NET-приложения. Да, не так быстро, как winapi-программы. Но что с того? Техника не месте не стоит. А раз так, то давайте делать более качественное ПО за меньшие деньги. А потребителям придётся покупать хорошие компы. Что поделаешь - прогресс.
DigiWhite
Цитата:
STL такая же неотъемлимая часть C++, как и сборщик мусора в C#. Только в отличие от C#, C++ не навязывает тебе конкретный метод. Тебе надо авто сборку мусора? - пожалуйте, auto_ptr и иже с ним помогут. Что, не надо авто сборки?, нужно что-то другое? - и это пожалуйте.
Цитата:
Какая нежная забота о новичках Такие базовые вещи, как cin, cout, vector и т.п. - тоже шаблоны, и вроде бы это никак не мешало огромному числу людей изучать С++.
Цитата:
См. _com_ptr_t и ему подобные.
И не путай программирование на С с программированием на С++.
Цитата:
Все уже давно реализовано. Спрашивайте в аптеках вашего города
Inochkin
Цитата:
А когда через некоторое время в программу будут добавлены новые типы объектов, ты что предлагаешь делать? Просматривать весь код в поисках всех тех мест, где выводится "пара отладочных окошек" и добавлять еще пару? Нет уж, увольте. Нам этого и задаром ненать
Цитата:
Продолжаешь жульничать, однако
Никаких библиотек говоришь? ОК, пойди тогда в свойства проекта С# и поставь там:
Do not use Mscorlib = True
Никаких шаблонов и STL? Хмм, вообще-то это средство "чистого языка" С++. Можно я тогда запрещу тебе использовать try/catch в С#, а лучше int.Parse, во!
Цитата:
Неужели ты всерьез думаешь, что вещи вроде int это средство языка С#?
int - всего лишь псевдоним типу System.Int32 из .NET Framework. И, согласно введенным тобою же ограничениям, ты не можешь им воспользоваться (никаких библиотек!). Забудь об int.Parse! Ой, боюсь ты ни одной программы на С# не сможешь написать с такими ограничениями.
Если же говорить серьёзно, то сравнивать надо не голые языки, т.к. ими никто никогда не пользуется, а всю совокупность средств, доступных программисту на том или другом языке. Ты же не будешь по улицам нагишом ходить, но и одежду сам себе ты вряд ли будешь шить. Все типовые задачи уже давно реализованы (сшиты) другими, нужно лишь уметь этим воспользоваться.
Ты вроде бы это и сам понимаешь:
Цитата:
Зачем же тогда приводишь бестолковые примеры с int.Parse и просишь парсить строку на чистом C++? Ведь знаешь же прекрасно, что это также легко делается на С/С++ с разницой лишь в названиях функций и синтаксисе языков.
Цитата:
А кто пользуется указателями на функции в С++? Ты не путаешь С с С++?
Цитата:
Ты не понял мое замечание, или же я недостаточно внятно объяснил.
Пользовательский интерфейс должен строиться на языке, понятном человеку, а не транслятору. Мнемоничность имен в программе тут не причем.
Warm_Sensor не является корректной английской фразой (т.к. содержит _) и она непонятна человеку, не владеющему английским. Толковая программа, будучи запущена под английской виндой, должна отобразить в списке: Warm Sensor, a под русской виндой: Датчик Тепла, под японской - соответствующие иероглифы, ну и т.д.
И чем тебе поможет та замечательная конструкция в решении этой задачи? Ты ведь даже пробел в названии константы не сможешь поставить.
Цитата:
Хмм... интересная фича. Ей можно воспользоваться в учебных целях, в школах например.
Цитата:
Меня все устраивает просто увидев непривычный мне термин, я переспросил, что имеется ввиду, сборка мусора (т.е. авто-освобождение неиспользуемой памяти) или же речь о чем-то другом.
oSLikus
Цитата:
Где ты тут С++ разглядел? WinAPI - это С, а вовсе не С++.
Цитата:
Согласен, такую ошибку легко допустить в С++, но это опять же если программировать на С++ в стиле С. Если же человека изначально учили (или сам учился) С++, то никаких проблем не будет, т.к. он воспользуется чем то вроде shared_ptr.
Цитата:
Кто же спорит. Вот только есть альтернативы, позволяющие к этому списку добавить 1 или 2 существенных плюса: переносимость и большую производительность.
Вопрос к людям, пропагандирующим С# и называющим его самым перспективным:
Приведите конкретные примеры (а не голословные утверждения) преимуществ С# над C++ в реальных и серьезных задачах (а не поделках на 5 минут), т.е. чего такого позволит мне сделать С#, чего я не смогу (или очень сложно) сделать в С++.
Вот только просьба, не надо сравнивать С# с С или С# c WinAPI, сравнивайте с С++. А то складывается такое впечатление, что люди, владеющие старым добрым С и нахватавшиеся пары новых фич вроде классов и new/delete, начинают думать (с перепугу наверное ), что они знают С++. Спешу огорчить...
Я ведь не просто так интересуюсь и не для того, чтобы С# очернить, отнюдь. Я пытаюсь понять, даст ли переход на С# какие-либо существенные преимущества лично мне (и нашей команде), или же это из разряда менять шило на мыло.
Цитата:
Сборщик мусора в C# - это его неотъемлимая часть.
STL такая же неотъемлимая часть C++, как и сборщик мусора в C#. Только в отличие от C#, C++ не навязывает тебе конкретный метод. Тебе надо авто сборку мусора? - пожалуйте, auto_ptr и иже с ним помогут. Что, не надо авто сборки?, нужно что-то другое? - и это пожалуйте.
Цитата:
Использование шаблонов - это тема не для новичков.
Какая нежная забота о новичках
Такие базовые вещи, как cin, cout, vector и т.п. - тоже шаблоны, и вроде бы это никак не мешало огромному числу людей изучать С++. Цитата:
В COM дык вообще замучаешься с вызовом AddRef и Release
См. _com_ptr_t и ему подобные.
И не путай программирование на С с программированием на С++.
Цитата:
Можно и в С++ реализовать сборщик мусора, но ИМХО, это достаточно непростая задача.
Все уже давно реализовано. Спрашивайте в аптеках вашего города
Inochkin
Цитата:
Скажите, если вам понадобится вывести пару отладочных окошек, вы действительно будете создавать "несколько процедур через полиморфизм"?
А когда через некоторое время в программу будут добавлены новые типы объектов, ты что предлагаешь делать? Просматривать весь код в поисках всех тех мест, где выводится "пара отладочных окошек" и добавлять еще пару? Нет уж, увольте. Нам этого и задаром ненать
Цитата:
Итак, вводим ограничение: только чистый язык, никаких библиотек, оберток и шаблонов.
Продолжаешь жульничать, однако
Никаких библиотек говоришь? ОК, пойди тогда в свойства проекта С# и поставь там:
Do not use Mscorlib = True
Никаких шаблонов и STL? Хмм, вообще-то это средство "чистого языка" С++. Можно я тогда запрещу тебе использовать try/catch в С#, а лучше int.Parse, во!
Цитата:
Только средства языка!
Неужели ты всерьез думаешь, что вещи вроде int это средство языка С#?
int - всего лишь псевдоним типу System.Int32 из .NET Framework. И, согласно введенным тобою же ограничениям, ты не можешь им воспользоваться (никаких библиотек!). Забудь об int.Parse! Ой, боюсь ты ни одной программы на С# не сможешь написать с такими ограничениями.
Если же говорить серьёзно, то сравнивать надо не голые языки, т.к. ими никто никогда не пользуется, а всю совокупность средств, доступных программисту на том или другом языке. Ты же не будешь по улицам нагишом ходить, но и одежду сам себе ты вряд ли будешь шить. Все типовые задачи уже давно реализованы (сшиты) другими, нужно лишь уметь этим воспользоваться.
Ты вроде бы это и сам понимаешь:
Цитата:
поэтому прошу вас быть объективным: либо пользоваться в примерах STL и не придираться к использованию .NET в моих примерах, либо привести примеры в соответствие с ограничением 1, которое я привел выше
Зачем же тогда приводишь бестолковые примеры с int.Parse и просишь парсить строку на чистом C++? Ведь знаешь же прекрасно, что это также легко делается на С/С++ с разницой лишь в названиях функций и синтаксисе языков.
Цитата:
Надеюсь вы признаете факт, что указатели на функции куда менее соответствуют принципам ООП, чем делегаты.
А кто пользуется указателями на функции в С++? Ты не путаешь С с С++?
Цитата:
Ну а по поводу третьего примера, я вам расскажу где эту штуку применил: есть некий комбобокс, в который нужно вывести названия неких устройств. В зависимости от выбора пользователя меняется логика работы программы.
Ты не понял мое замечание, или же я недостаточно внятно объяснил.
Пользовательский интерфейс должен строиться на языке, понятном человеку, а не транслятору. Мнемоничность имен в программе тут не причем.
Warm_Sensor не является корректной английской фразой (т.к. содержит _) и она непонятна человеку, не владеющему английским. Толковая программа, будучи запущена под английской виндой, должна отобразить в списке: Warm Sensor, a под русской виндой: Датчик Тепла, под японской - соответствующие иероглифы, ну и т.д.
И чем тебе поможет та замечательная конструкция в решении этой задачи? Ты ведь даже пробел в названии константы не сможешь поставить.
Цитата:
Кстати, уж не знаю, баг это или фича, но компилятор в VS2003 принимает и русские идентификаторы
Хмм... интересная фича. Ей можно воспользоваться в учебных целях, в школах например.
Цитата:
Ну и по поводу автоматического распределения памяти. Если вас не устраивает термин, то я буду пользоваться любым, какой вы предложите. Хотя бы и "освобождение".
Меня все устраивает
просто увидев непривычный мне термин, я переспросил, что имеется ввиду, сборка мусора (т.е. авто-освобождение неиспользуемой памяти) или же речь о чем-то другом. oSLikus
Цитата:
- в C++ любое число можно привести к указателю и вуаля. Буквально вчера сел за изучение WinAPI, смотрю как нарисовать белый фон - необходимо указать параметр типа HBRUSH (который является на самом деле HANDLE, который в свою очередь является typedef void *), так вот в примере делается (HBRUSH)COLOR_WINDOW (#define число какое-то). Застрелиться Нет, естественно это работает. Только представьте себе отладку подобного бага...
Где ты тут С++ разглядел? WinAPI - это С, а вовсе не С++.
Цитата:
- допустим в C++ мы выделили память, и два указателя ссылаются на эту область.
Согласен, такую ошибку легко допустить в С++, но это опять же если программировать на С++ в стиле С. Если же человека изначально учили (или сам учился) С++, то никаких проблем не будет, т.к. он воспользуется чем то вроде shared_ptr.
Цитата:
А раз так, то давайте делать более качественное ПО за меньшие деньги.
Кто же спорит. Вот только есть альтернативы, позволяющие к этому списку добавить 1 или 2 существенных плюса: переносимость и большую производительность.
Вопрос к людям, пропагандирующим С# и называющим его самым перспективным:
Приведите конкретные примеры (а не голословные утверждения) преимуществ С# над C++ в реальных и серьезных задачах (а не поделках на 5 минут), т.е. чего такого позволит мне сделать С#, чего я не смогу (или очень сложно) сделать в С++.
Вот только просьба, не надо сравнивать С# с С или С# c WinAPI, сравнивайте с С++. А то складывается такое впечатление, что люди, владеющие старым добрым С и нахватавшиеся пары новых фич вроде классов и new/delete, начинают думать (с перепугу наверное
), что они знают С++. Спешу огорчить... Я ведь не просто так интересуюсь и не для того, чтобы С# очернить, отнюдь. Я пытаюсь понять, даст ли переход на С# какие-либо существенные преимущества лично мне (и нашей команде), или же это из разряда менять шило на мыло.
segeich
Поддерживаю все утверждения. Хочу еще добавить: почти для всех объектов в Стандарте C++ приведена оценка временной сложности работы. Есть ли она для C#?
Поддерживаю все утверждения. Хочу еще добавить: почти для всех объектов в Стандарте C++ приведена оценка временной сложности работы. Есть ли она для C#?
segeich
Цитата:
Да вообще-то в C# никто не навязывает вам конкретны метды. Хотите, хоть всю STL на C# с нуля напишите. А сборщик мусора - это часть архитектуры .NET, а не возможности языка.
Цитата:
Ну ладно..., открытваем занчит книгу "Сущность технологии COM", Дональда Бокса. Смотрим.... первый же раздел называется "COM как улучшенный C++". Я чего-то не понимаю, где я что напутал...
Цитата:
А вы тогда не используйте никаких заголовочных файлов вместе с библиотеками. Ок? Никаких stdio.h и прочих. Глупо, правда ведь?
Цитата:
Вроде бы никто не мешает использовать укзатели на функции в C++, если это удобно. И Страуструп о них упоминает в свойе книге ("Язык программирования С++", спец. издание, Страуструп, страница 474 ) как указатель на на члены. Даже если пришли эти указатели из С.
Цитата:
Т.е. если не используется ООП подход, то это уже не С++, даже если мы, например,
внутри функций используем STL?
Цитата:
Вроде никто не говорит, что он самый перспективный вообще. Возможно, он самый перспективный для разработки бизнес-приложений для OS Windows(XP и следующие). Скороее всего, что сделать на C++ можно столько-же, сколько и на C#, и вероятнее всего, даже больше, т.к., как уже говорилось, C# молодой. Только только вышла 2.0 версися, которую мало кто еще видел в глаза. Москва не сразу строилась. Вероятно по этому, например я, не могу привести никаких примеров больших проектов. Вохможно, что большая часть их является Web сервисами, основаными на технологии .NET Remoting. Кстати, Web сервис просто написать на C++?
Ну и наконец про временную сложность работы алгоритмов в С# вообще ничего не могу сказать. Не интересовался. Хотя 100%, под управлением .NET("управляемые") приложения работают несколько медленне чем "неуправляемые" приложения.
Цитата:
STL такая же неотъемлимая часть C++, как и сборщик мусора в C#. Только в отличие от C#, C++ не навязывает тебе конкретный метод. Тебе надо авто сборку мусора? - пожалуйте, auto_ptr и иже с ним помогут. Что, не надо авто сборки?, нужно что-то другое? - и это пожалуйте.
Да вообще-то в C# никто не навязывает вам конкретны метды. Хотите, хоть всю STL на C# с нуля напишите. А сборщик мусора - это часть архитектуры .NET, а не возможности языка.
Цитата:
См. _com_ptr_t и ему подобные.
И не путай программирование на С с программированием на С++.
Ну ладно..., открытваем занчит книгу "Сущность технологии COM", Дональда Бокса. Смотрим.... первый же раздел называется "COM как улучшенный C++". Я чего-то не понимаю, где я что напутал...
Цитата:
Никаких библиотек говоришь? ОК, пойди тогда в свойства проекта С# и поставь там:
Do not use Mscorlib = True
Никаких шаблонов и STL? Хмм, вообще-то это средство "чистого языка" С++. Можно я тогда запрещу тебе использовать try/catch в С#, а лучше int.Parse, во!
А вы тогда не используйте никаких заголовочных файлов вместе с библиотеками. Ок?
Никаких stdio.h и прочих. Глупо, правда ведь? Цитата:
А кто пользуется указателями на функции в С++? Ты не путаешь С с С++?
Вроде бы никто не мешает использовать укзатели на функции в C++, если это удобно. И Страуструп о них упоминает в свойе книге ("Язык программирования С++", спец. издание, Страуструп, страница 474
) как указатель на на члены. Даже если пришли эти указатели из С. Цитата:
Где ты тут С++ разглядел? WinAPI - это С, а вовсе не С++.
Т.е. если не используется ООП подход, то это уже не С++, даже если мы, например,
внутри функций используем STL?
Цитата:
Вопрос к людям, пропагандирующим С# и называющим его самым перспективным:
Приведите конкретные примеры (а не голословные утверждения) преимуществ С# над C++ в реальных и серьезных задачах (а не поделках на 5 минут), т.е. чего такого позволит мне сделать С#, чего я не смогу (или очень сложно) сделать в С++.
Вроде никто не говорит, что он самый перспективный вообще. Возможно, он самый перспективный для разработки бизнес-приложений для OS Windows(XP и следующие). Скороее всего, что сделать на C++ можно столько-же, сколько и на C#, и вероятнее всего, даже больше
, т.к., как уже говорилось, C# молодой. Только только вышла 2.0 версися, которую мало кто еще видел в глаза. Москва не сразу строилась. Вероятно по этому, например я, не могу привести никаких примеров больших проектов. Вохможно, что большая часть их является Web сервисами, основаными на технологии .NET Remoting. Кстати, Web сервис просто написать на C++? Ну и наконец про временную сложность работы алгоритмов в С# вообще ничего не могу сказать. Не интересовался. Хотя 100%, под управлением .NET("управляемые") приложения работают несколько медленне чем "неуправляемые" приложения.
Да не в том дело, что C# перспективнее или ещё что-то (C++, Java, Delphi). А в том, что если ты специалист - ты найдёшь себе работу, за которую тебе будут платить достойные деньги.
Для того, чтобы писать рабочие приложения на C# необходимо затратить меньше времени на изучение (самого языка и библиотеки), чем если бы мы начинали писать на C++. Ну, это, конечно же, субъективное мнение, основанное на том, что наиболее известные ошибки - это указатели, переполнение буфера и утечки памяти. В C# подобных проблем быть не должно (в виду отсутствия указателей в managed режиме) и наличия GC (Garbage Collector).
Из задач... недавно у меня был курсач - переписать на C# и распараллелить с помощью .NET Remoting программу, написанную на С++ (мат. расчёт). Распараллеливание - примерно 50-100 строк нормального кода: 6 строк инициализации Remoting, строк 10 - пометка нужных классов атрибутом [Serializable] (чтобы класс можно было по сети передавать), класс для чтения файла с серверами, класс для раздачи заданий серверам. Ну, может чуть больше строк, не суть. Что в итоге получилось? Никакой возни с протоколами, сетью и т.п. Никаких проблем синхронизации (ну, WaitForMultiplyObjects не считается
). По сети передаётся с каждым заданием 50-100 лишних байт. Кстати говоря, время выполнения программы на C++ 1400 секунд (если Intel Compiler, то 1050 секунд), а на C# 2300.
Работа с БД:
using (SqlConnection con = new SqlConnection(conString))
{
SqlCommand cmd = new SqlCommand("SELECT * FROM Users", con);
con.Open();
SqlDataReader dr = cmd.ExecuteReader();
while (dr.Read())
{
// читаем из ридера: dr["ID"], dr["Name"] и т.п.
}
}
Интерфейс... по крайней мере ГОРАЗДО проще, чем Win API или MFC.
Написать сайт... ну, тут, я думаю, спорить никто не будет...
segeich: если вы специалист по C++, у вас не должно быть проблем ни с работой, ни с тем, "что лучше". Какой смысл _востребованному_ специалисту переквалифицироваться? Только из интереса, я думаю.
!!! Я не говорю, что C++ отстой, отнюдь. Но... всегда есть но Писать приложения на C# с помощью .NET Framework _удобнее_. Точно так же и с Java - на ней удобнее написать кросс-платформенно приложение: если оно написано целиком на Java и использует только java-компоненты, то оно будет работать везде и будет выглядеть везде одинаково За что мы платим производительностью... но важной ли, что список будет показываться не 100 миллисекунд, а 500, если приложение будет написано быстрее на дцать дней/месяцев?
Для того, чтобы писать рабочие приложения на C# необходимо затратить меньше времени на изучение (самого языка и библиотеки), чем если бы мы начинали писать на C++. Ну, это, конечно же, субъективное мнение, основанное на том, что наиболее известные ошибки - это указатели, переполнение буфера и утечки памяти. В C# подобных проблем быть не должно (в виду отсутствия указателей в managed режиме) и наличия GC (Garbage Collector).
Из задач... недавно у меня был курсач - переписать на C# и распараллелить с помощью .NET Remoting программу, написанную на С++ (мат. расчёт). Распараллеливание - примерно 50-100 строк нормального кода: 6 строк инициализации Remoting, строк 10 - пометка нужных классов атрибутом [Serializable] (чтобы класс можно было по сети передавать), класс для чтения файла с серверами, класс для раздачи заданий серверам. Ну, может чуть больше строк, не суть. Что в итоге получилось? Никакой возни с протоколами, сетью и т.п. Никаких проблем синхронизации (ну, WaitForMultiplyObjects не считается
). По сети передаётся с каждым заданием 50-100 лишних байт. Кстати говоря, время выполнения программы на C++ 1400 секунд (если Intel Compiler, то 1050 секунд), а на C# 2300. Работа с БД:
using (SqlConnection con = new SqlConnection(conString))
{
SqlCommand cmd = new SqlCommand("SELECT * FROM Users", con);
con.Open();
SqlDataReader dr = cmd.ExecuteReader();
while (dr.Read())
{
// читаем из ридера: dr["ID"], dr["Name"] и т.п.
}
}
Интерфейс... по крайней мере ГОРАЗДО проще, чем Win API или MFC.
Написать сайт... ну, тут, я думаю, спорить никто не будет...
segeich: если вы специалист по C++, у вас не должно быть проблем ни с работой, ни с тем, "что лучше". Какой смысл _востребованному_ специалисту переквалифицироваться? Только из интереса, я думаю.
!!! Я не говорю, что C++ отстой, отнюдь. Но... всегда есть но
Писать приложения на C# с помощью .NET Framework _удобнее_. Точно так же и с Java - на ней удобнее написать кросс-платформенно приложение: если оно написано целиком на Java и использует только java-компоненты, то оно будет работать везде и будет выглядеть везде одинаково За что мы платим производительностью... но важной ли, что список будет показываться не 100 миллисекунд, а 500, если приложение будет написано быстрее на дцать дней/месяцев?oSLikus
Цитата:
Здесь вынужден не согласиться... Вернее согласен, но придется компенсировать это более произваодительным оборудованием. Что в общем то, в некоторой степени, уменьшает плюс в скорости разработки приложения.
Цитата:
За что мы платим производительностью... но важной ли, что список будет показываться не 100 миллисекунд, а 500, если приложение будет написано быстрее на дцать дней/месяцев?
Здесь вынужден не согласиться... Вернее согласен, но придется компенсировать это более произваодительным оборудованием. Что в общем то, в некоторой степени, уменьшает плюс в скорости разработки приложения.
За всё приходится платить Я не отрицаю этого. Я не говорю, что фирме N разработка продукта S на C# будет стоить меньших денег, чем разработка на C++. Но время будет сэкономлено.
Могу пример из жизни привести: там, где я работаю, все пишут на C#, но возникла необходимость в программе-клиенте, которая будет работать на win98 + занимала мало (всё-таки, .NET Framework - это довесок в 20 Мб к программе, не у всех winxp со вторым Service Pack)... делаем на C++. Но только клиент, сервер пишется на C# (быстрее писать, безопаснее).
Я не отрицаю этого. Я не говорю, что фирме N разработка продукта S на C# будет стоить меньших денег, чем разработка на C++. Но время будет сэкономлено. Могу пример из жизни привести: там, где я работаю, все пишут на C#, но возникла необходимость в программе-клиенте, которая будет работать на win98 + занимала мало (всё-таки, .NET Framework - это довесок в 20 Мб к программе, не у всех winxp со вторым Service Pack)... делаем на C++. Но только клиент, сервер пишется на C# (быстрее писать, безопаснее).
TheChampion
Цитата:
Вряд ли. Ведь нынче мода пошла такая - писать программы по-быстрому, раз-два и готово, а как уж они будут потом работать, спринтеров не волнует. Это, по их мнению, проблемы пользователя - пусть upgrade делает, если не доволен.
Зато какая выгода, по их мнению, - можно набрать посредственных разработчиков, быстренько обучить их языку (особо стараться не надо, ведь среда за них все сама сделает, и от ошибок убережет, и кучу кода нагенерит и т.п.) и усё, можно в короткие сроки начать штамповать шедевры и сэкономить кучу средств.
При этом они еще верят, что подобные поделки обладают более высоким качеством и надежностью. Блажен кто верует...
DigiWhite
Цитата:
Зачем мне это? Да и, боюсь, слабоват C# окажется для такого.
Цитата:
Верно. Тут я ошибся.
Цитата:
Это называется метафора
Цитата:
Глупо, конечно. Но почему ты мне об этом пишешь? Это не моя идея голышом бегать была - все вопросы к Inochkin.
Цитата:
Вроде бы никто не мешает выходить из дома через окно, если это удобно. Вот только станут ли разумные люди так поступать?
В С++ много возможностей, унаследованных от С. И существуют они в языке вовсе не для того, чтобы ими пользоваться, а для совместимости с тоннами кода, написанного за долгие годы на С.
Цитата:
Не передергивай. Речь шла о WinAPI, который ты можешь вызывать из любой программы, хоть на С, хоть на Basic, хоть Delphi, хотя на C#. От этого они в программы на С++ не превратятся, и проблемы, упомянутые oSLikus (вроде преобразования числа в указатель) никуда не денутся. Ну и причем тут С++?
oSLikus
Цитата:
А никто про переквалификацию и не говорит. Для разных задач разные средства хороши. Вот я и пытаюсь понять, для каких задач C# (вернее .NET конечно же) лучше подходит, чтобы в следующих проектах более полно представлять многообразие возможных решений, и, стало быть, сделать более удачный выбор.
Что касается разработки Web сервисов, сайтов и тому подобных вещей, предполагающих написание серверных компонентов, то тут, я думаю, спорить никто не будет... - .NET в ее нынешнем виде абсолютно не подходит для этих целей, пусть даже на ней и очень легко писать такой софт.
Ведь если в сфере офисного/домашнего ПО я еще с некоторой натяжкой могу признать доминирование Windows, то в серверном секторе это далеко не так. И нужно быть очень странным (это еще легко сказано) разработчиком, чтобы делать ставку на .NET и терять половину потенциальных покупателей (пользователей).
Цитата:
Есть ли она для C#?
Вряд ли. Ведь нынче мода пошла такая - писать программы по-быстрому, раз-два и готово, а как уж они будут потом работать, спринтеров не волнует. Это, по их мнению, проблемы пользователя - пусть upgrade делает, если не доволен.
Зато какая выгода, по их мнению, - можно набрать посредственных разработчиков, быстренько обучить их языку (особо стараться не надо, ведь среда за них все сама сделает, и от ошибок убережет, и кучу кода нагенерит и т.п.) и усё, можно в короткие сроки начать штамповать шедевры и сэкономить кучу средств.
При этом они еще верят, что подобные поделки обладают более высоким качеством и надежностью. Блажен кто верует...
DigiWhite
Цитата:
Хотите, хоть всю STL на C# с нуля напишите.
Зачем мне это? Да и, боюсь, слабоват C# окажется для такого.
Цитата:
А сборщик мусора - это часть архитектуры .NET, а не возможности языка.
Верно. Тут я ошибся.
Цитата:
первый же раздел называется "COM как улучшенный C++". Я чего-то не понимаю, где я что напутал...
Это называется метафора
Цитата:
А вы тогда не используйте никаких заголовочных файлов вместе с библиотеками. Ок? Никаких stdio.h и прочих. Глупо, правда ведь?
Глупо, конечно. Но почему ты мне об этом пишешь? Это не моя идея голышом бегать была - все вопросы к Inochkin.
Цитата:
Вроде бы никто не мешает использовать укзатели на функции в C++, если это удобно.
Вроде бы никто не мешает выходить из дома через окно, если это удобно. Вот только станут ли разумные люди так поступать?
В С++ много возможностей, унаследованных от С. И существуют они в языке вовсе не для того, чтобы ими пользоваться, а для совместимости с тоннами кода, написанного за долгие годы на С.
Цитата:
Т.е. если не используется ООП подход, то это уже не С++, даже если мы, например,
внутри функций используем STL?
Не передергивай. Речь шла о WinAPI, который ты можешь вызывать из любой программы, хоть на С, хоть на Basic, хоть Delphi, хотя на C#. От этого они в программы на С++ не превратятся, и проблемы, упомянутые oSLikus (вроде преобразования числа в указатель) никуда не денутся. Ну и причем тут С++?
oSLikus
Цитата:
Какой смысл _востребованному_ специалисту переквалифицироваться?
А никто про переквалификацию и не говорит. Для разных задач разные средства хороши. Вот я и пытаюсь понять, для каких задач C# (вернее .NET конечно же) лучше подходит, чтобы в следующих проектах более полно представлять многообразие возможных решений, и, стало быть, сделать более удачный выбор.
Что касается разработки Web сервисов, сайтов и тому подобных вещей, предполагающих написание серверных компонентов, то тут, я думаю, спорить никто не будет...
- .NET в ее нынешнем виде абсолютно не подходит для этих целей, пусть даже на ней и очень легко писать такой софт. Ведь если в сфере офисного/домашнего ПО я еще с некоторой натяжкой могу признать доминирование Windows, то в серверном секторе это далеко не так. И нужно быть очень странным (это еще легко сказано) разработчиком, чтобы делать ставку на .NET и терять половину потенциальных покупателей (пользователей).
В каком месте .NET не подходит для WebService? А я-то всегда думал, что это конёк .NET'а.
Цитата:
Возможности C были _расширены_ C++, но уж никак не возможности C++ были унаследованы... Но если уж и по-вашему: в студию то, чего есть в C, но не должно быть в C++...
Цитата:
Возможности STL перекрываются .NET Framework. И не спроста - при разработке Framework'а народ посмотрел, что есть в Java, что есть в STL, что есть в Delphi и сделали _лучше_ (что не удивительно - они делали, опираясь на чужой опыт).
А написать на C# можно что угодно из STL. Кроме управляемых указателей
Цитата:
Вроде бы никто не мешает выходить из дома через окно, если это удобно. Вот только станут ли разумные люди так поступать?
В С++ много возможностей, унаследованных от С. И существуют они в языке вовсе не для того, чтобы ими пользоваться, а для совместимости с тоннами кода, написанного за долгие годы на С.
Возможности C были _расширены_ C++, но уж никак не возможности C++ были унаследованы... Но если уж и по-вашему: в студию то, чего есть в C, но не должно быть в C++...
Цитата:
Зачем мне это? Да и, боюсь, слабоват C# окажется для такого.
Возможности STL перекрываются .NET Framework. И не спроста - при разработке Framework'а народ посмотрел, что есть в Java, что есть в STL, что есть в Delphi и сделали _лучше_ (что не удивительно - они делали, опираясь на чужой опыт).
А написать на C# можно что угодно из STL. Кроме управляемых указателей
Цитата:
Возможности STL перекрываются .NET Framework
В каком месте? Как известно, STL стоит на трех китах: контейнерах, итераторах и алгоритмах. И где оно в .NET Framework? Из всех алгоритмов есть только foreach, из итераторов --- только однонаправленные, из контейнеров --- только вектор. Кто кого тут перекрывает?
Еще вопрос: назовите хотя бы одну популярную программу, написанную на C#? Windows, ясен пень, написан на C/C++. Unix --- C/C++ без вопросов. Oracle --- C/C++ + Java. Меня убеждали, что Ил-2 Штурмовик написан на Java, но проблема в том, что JRE не требуется для его работы, файлов *.class я не обнаружил, зато в log-файле обнаружил строчку вида "произошло исключение в модуле xxxxx.cpp". Может быть, конечно, Олег Мэдокс такой приколист, что помещает Жаба-код в файлы .cpp, не знаю. Еще возьмем Battlefield 2. Графика --- C/C++, логика --- C/C++ + Python (!!!) Сам .NET Framework и C# написан на C/C++ --- умные люди сказали, что JVM написана на Java пополам с C --- почему вдруг C# составляет исключение? Да и не будут в MS переписывать код MSVS, дыр и без того хватает.
Еще я могу упомянуть Firefox, которым сейчас пользуюсь. TeX и OpenOffice. Ни одна из этих программ не написана на C#. Вам не кажется, что слухи о смерти льва оказались несколько преувеличины?
TheChampion
Цитата:
Уже в который раз говориться, что .NET и иже с ними очень молодые. Уже устали это повторять. Про смерть C++ вообще никто еще не говорит. Наверно на заре C точно так же постоянно кричали. Покажите то, покажите это!
segeich
Цитата:
Вот уж не поудмал бы... Т.е. я так понимаю, взяли мы язык, забили на всю технологию разработки ПО. И что-то я не замечаю, что среда за меня все делает. Да, среда от ошибок убережет, по крайней мере от синтаксических. От логических уберечь может только ваша собственная голова и хорошее проектирование. Быстренько научить их языку. Ну да. С++ на простом уровне осваиваивается за неделю или даже быстрее (Если имеется опыт программирования на дургих языках и очень надо). Но только на простом уровне. Тонкости придется постигать, пожалуй, годами. Написав не одну тонну кода. Как и C#. А без проектирования, как ни крути, ничего хорошего не напишешь. Ни на каком языке. Мдя, сужя по словам получается, что самые лучшие, это те кто пишет на С++. Это вообще, что же думают о людях, которые с Lisp работают...
segeich
Цитата:
Ах, ну да, простите. Просто реализация интерфейсов в COM делается через функции и глобальные переменные. Все, все. Это С. И никак иначе.
Цитата:
И в правду, чем это .NET абсолютно не подходит?. И на счет серверов. Все 100% из *nix подобные системы? Ой как не верю.
Цитата:
Еще вопрос: назовите хотя бы одну популярную программу, написанную на C#? Windows, ясен пень, написан на C/C++. Unix --- C/C++ без вопросов. Oracle --- C/C++ + Java. Меня убеждали, что Ил-2 Штурмовик написан на Java, но проблема в том, что JRE не требуется для его работы, файлов *.class я не обнаружил, зато в log-файле обнаружил строчку вида "произошло исключение в модуле xxxxx.cpp". Может быть, конечно, Олег Мэдокс такой приколист, что помещает Жаба-код в файлы .cpp, не знаю. Еще возьмем Battlefield 2. Графика --- C/C++, логика --- C/C++ + Python (!!!) Сам .NET Framework и C# написан на C/C++ --- умные люди сказали, что JVM написана на Java пополам с C --- почему вдруг C# составляет исключение? Да и не будут в MS переписывать код MSVS, дыр и без того хватает.
Еще я могу упомянуть Firefox, которым сейчас пользуюсь. TeX и OpenOffice. Ни одна из этих программ не написана на C#. Вам не кажется, что слухи о смерти льва оказались несколько преувеличины?
Уже в который раз говориться, что .NET и иже с ними очень молодые. Уже устали это повторять. Про смерть C++ вообще никто еще не говорит. Наверно на заре C точно так же постоянно кричали. Покажите то, покажите это!
segeich
Цитата:
Вряд ли. Ведь нынче мода пошла такая - писать программы по-быстрому, раз-два и готово, а как уж они будут потом работать, спринтеров не волнует. Это, по их мнению, проблемы пользователя - пусть upgrade делает, если не доволен.
Зато какая выгода, по их мнению, - можно набрать посредственных разработчиков, быстренько обучить их языку (особо стараться не надо, ведь среда за них все сама сделает, и от ошибок убережет, и кучу кода нагенерит и т.п.) и усё, можно в короткие сроки начать штамповать шедевры и сэкономить кучу средств.
При этом они еще верят, что подобные поделки обладают более высоким качеством и надежностью. Блажен кто верует...
Вот уж не поудмал бы... Т.е. я так понимаю, взяли мы язык, забили на всю технологию разработки ПО. И что-то я не замечаю, что среда за меня все делает. Да, среда от ошибок убережет
, по крайней мере от синтаксических. От логических уберечь может только ваша собственная голова и хорошее проектирование. Быстренько научить их языку. Ну да. С++ на простом уровне осваиваивается за неделю или даже быстрее (Если имеется опыт программирования на дургих языках и очень надо). Но только на простом уровне. Тонкости придется постигать, пожалуй, годами. Написав не одну тонну кода. Как и C#. А без проектирования, как ни крути, ничего хорошего не напишешь. Ни на каком языке. Мдя, сужя по словам получается, что самые лучшие, это те кто пишет на С++. Это вообще, что же думают о людях, которые с Lisp работают... segeich
Цитата:
Это называется метафора
Ах, ну да, простите. Просто реализация интерфейсов в COM делается через функции и глобальные переменные. Все, все. Это С. И никак иначе.
Цитата:
Что касается разработки Web сервисов, сайтов и тому подобных вещей, предполагающих написание серверных компонентов, то тут, я думаю, спорить никто не будет... - .NET в ее нынешнем виде абсолютно не подходит для этих целей, пусть даже на ней и очень легко писать такой софт
И в правду, чем это .NET абсолютно не подходит?. И на счет серверов. Все 100% из *nix подобные системы? Ой как не верю.
Страницы: 1234567891011121314151617181920212223
Предыдущая тема: Подскажите сайт о написании компьютерных игр.
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.