Здравствуйте, VladD2, Вы писали:

MS>>Иными словами, это ничего не говорит ни в пользу C# ни против него. С формальной логикой у тебя все-таки не лады
VD>Здесь обсуждался вопрос неприемлемости использования Шарпа в 3D-играх. По этому поводу какие-нибудь аргументы есть? Или признаем все попытки признать это мнение обычной инсинуацией?
Так и признаем. Притом инсинуациями занимаешься вроде как ты. Исходно речь велась о некоторых проблемах применения .Net и C# для разработки 3D-движков. Ну, ПК по неосторожности упомянул...

Впрочем, мы усвоили десять великих истин форума RSDN/Философия:

1. Если хочешь знать, что .Net — это всегда хорошо, то сначала обратись к RSDN/VladD2, а если этого не хватило, то возьми Janus, да проверь;
2. Если хочешь тестирований производительности для 3D, то возьми Janus, да проверь;
3. Если хочешь убедиться, что на .Net можно написать всё, то снова возьми Janus, да проверь;
4. Если хочешь убедиться, что продукты, разработанные на .Net не имеют проблем, то снова возьми Janus, да проверь;
5. Если хочешь убедиться, что гибкость продуктов, написанных с использованием .Net немерянна, то опять, возьми, балбес, Janus, да проверь;
6. Если хочешь логических доказательств и объяснений, то или обратись в RSDN/Философия, или возьми, наконец, Janus, да проверь;
7. Если хочешь убедиться, что C# "делает" C++ по всем статьям, то, обратно, возьми Janus, да проверь;
8. И вообще — возьми Janus, да проверь, как ты, кретин, ошибаешься;
9. Если ещё не считаешь себя лузером, то сообщи об этом в форуме "Философия", дабы развеять сомнения;
10. Если в чём-то ещё не убеждён до краёв тапочек, то начни с пункта 1. или хотя бы возьми Janus, да проверь.

Слава RSDN/Философии — вечному источнику универсального мнения всех. Кто не с нами, тот сам себе злобный Буратино!

PS. Всё вышесказанное — проявление моей (недостойного!) недостойной (же!) позиции в споре, достойной всяческого порицания.

VD>То что вам нечего сказать по делу видно уже давно.

Так уж исторически сложилось, что я привык спорить с вменяемыми собеседниками. А риторику я не изучал и в ней не силен. Извини еще раз.

Здравствуйте, VladD2, Вы писали:


VD>Пока. Как видишь первые ласточки уже есть. Со временем народ поймет, что писать несистемный код на С/С++ — это тоже самое, что зарывать деньги в песок на поле дураков. Думаю, что когда появится официальный C# 2.0, и когда выдет в свет Феникс, разговоры о применении C# в любой сфере прикладного программирования (за исключением наверно приложений реального времени) уйдут в небытие.

Я бы на твоем месте на это не надеялся. Никуда эти разговоры не уйдут. Как показывает практика, надо сорок лет пользования новой моделью, чтобы певцы предыдущей угомонились.
Оффтоп:
На штатовских тусняках, насколько мне известно, популярно нытье про натив вс оффшор. И при этом нативщики вовсю топчут оффшорников. Основной тезой там является принципиальная невозможность писать качественныйкод за $10 в час, а также априорная убежденность в крутизне CS depratment * State University супротив любого ВУЗа в третьих странах.

До боли напоминает аргументы критиков .Net

Автор:
Дата: 09.12.04

по своей незыблемости

Так вот, я думаю, что после выхода C# 2.0 критика только усилится. Сейчас еще есть народ, сидящий в нишах, который думает "до нас не докатится" и смеется. "Дотнет-дотда, а фортран девелоперы завсегда нужны!" Вот когда под ними опора зашатается, тогда и начнется "Это г. на дотнете просто не может быть лучше нашего суперпродукта. Ведь только на его отладку потратили восемь лет!"

Дарней,

> ПК> Для того, чтобы не портить чужую память в C++, идеальные программисты не нужны. В C++ нет опасных возможностей, которые не могут быть инкапсулированы безопасными обертками.

> Иными словами — сначала нам нужно разработать фреймворк, который будет инкапсулировать все опасные возможности C++

Не фреймворк, а библиотеку (т.е. на структуру программы ограничений она не накладывает). И разрабатывать с нуля не надо — уже давно есть. И не одна. Если в какой-то что-то не устраивает, всегда можно доработать. Благо, с открытым кодом хватает.

> (в результате мы получим подмножество языка, очень похожее на C#

Нет. С# не включает множества вещей, которые вполне останутся: шаблоны, позволяющие контролировать часть семантических ограничений во время компиляции, (generics не в счет), размещение объектов в стеке + деструкторы, что позволяет автоматизировать освобождение ресурсов, "свободные" функции и т.п. Если бы язык, действительно, являющийся "улучшенным C++", освобожденным от совмстимости от C, уже был бы создан, обсуждать было бы нечего. Java и C# таковыми не являются и близко. Это легко увидеть при сравнении наиболее типичных подходов в каждом из этих языков.

> Потом написать набор соглашений и требований к коду (один из таких документов, которые я видел — это талмуд объемом около 200 страниц)

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

> Потом нужно добиться, чтобы все программисты эти требования соблюдали. Правила конечно все равно будут нарушать... поэтому придется посадить некоторое количество людей, чтобы они вычитывали код.

Для приложений с повышенными требованиями к устойчивости code review — фактически, неизбежное дело, вне зависимости от языка. Даже таких языков, как Ада, это касается. Например, один бесконечный цикл в подходящем месте окажется не менее фатальным, чем проход по памяти. Или постепенное накопление процессом используемой памяти, которого автоматически нельзя избежать ни в одном языке, если не предпринимать специальных мер. И т.п.

> Ну и конечно, наиболее распространенные нарушения можно выявлять автоматически — достаточно написать парсер кода с некоторым набором правил проверки.

Это все уже написано давным-давно. См., например, тот же CodeWizard. Нарушения можно выявлять все, которые интересуют, а не "наиболее распространенные". Арифметика указателей (включая встроенные массивы), функции с переменным числом аргументов, некоторые "опасные" разновидности приведения типов и т.п. — все это легко диагностируется соответствующими инструментами.

> ПК> Это единственный способ "этого" избежать, если ты работаешь со злоумышленниками.

> при наличии достаточного количества программистов, можно обойтись и без злоумышленников

При наличии достаточного количества программистов с низкой квалификацией. Тут уже никакой язык не поможет.

> ПК> От многократного повторения данный тезис более истинным не становится.

> no comments

Гм... А что, становится? Если нет, то какая разница, сколько раз это уже обсуждалось?

Здравствуйте, VladD2, Вы писали:

VD>Думаю, ты еще не раз задумаешся над вопросом кто из нас более вменяем.

Ну давай вкурим твою фразу с точки зрения формальной логики. Допустим, что я являюсь невменяемым. Если так, то я никогда не признаю свою невменяемость по причине невменяемости и задумываться об этом не буду. Если же принять допуoщение о твоей невменяемости, то нафига мне об этом "не раз задумываться"?! Если же я все-таки буду "не раз задумываться", то это ставит под сомнение мою собственную вменяемость.

С логикой у тебя точно не лады.

Мне вспомнилась цитата из известного произведения.

- Вы, Шариков, чушь говорите. И возмутительнее всего то, что вы говорите это безапелляционно и уверенно.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>С интенсивной 3D графикой на .Net? Какие?

Ты хоть чуть чуть читаешь что рядом находится. Или мне в подпись поместить ссылки?

ArenaWarsDemoEnglishAndGerman.exe

ПК> Quake не считается, т.к. он написан очень своеобразно: ему GC вообще почти параллельна.

Если бы ты еще знал каковы накладные раскходы на ЖЦ, то с тобой бы даже можно было бы о чем-то по говорить. А так снова привосходство теории над разумом.


ПК>Но писать так все игры никто не будет, ибо очень дорого:

Ну, ссылка выше есть. Скачай поиграй. Так же тут не раз проходили ссылки на 3D-движок портированный с С++ на Шарп. Тоже скачай погоняй демки. Если заметишь тормоза, то приходи обсудим. Можешь еще демок к DX9 скачать. Так мк раз идентичный код на С++, ВБ и Шарпе.

Здравствуйте, AndrewVK, Вы писали:

AVK>В текущем проекте, который уже 2 года живет, не было ни одного случая потери ресурсов из-за забытого using. Веришь?

Да плевать ему на практику тысяч человек. Его теори незыблемы. Пробовать на практике ему в лом. Мне кажется все эти разговоры бессмысленны. Это упертость принципиальна. Надо завершать этот бессмысленный разговор.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Для того, чтобы не портить чужую память в C++, идеальные программисты не нужны. В C++ нет опасных возможностей, которые не могут быть инкапсулированы безопасными обертками. В результате достаточно некоторого набора соглашений по используемым возможностям языка, плюс соблюдение некоторых требований к процессу разработки.

Иными словами — сначала нам нужно разработать фреймворк, который будет инкапсулировать все опасные возможности C++ (в результате мы получим подмножество языка, очень похожее на C# ). Потом написать набор соглашений и требований к коду (один из таких документов, которые я видел — это талмуд объемом около 200 страниц). Потом нужно добиться, чтобы все программисты эти требования соблюдали. Правила конечно все равно будут нарушать... поэтому придется посадить некоторое количество людей, чтобы они вычитывали код. Ну и конечно, наиболее распространенные нарушения можно выявлять автоматически — достаточно написать парсер кода с некоторым набором правил проверки.
Все очень просто, нужно только сильно захотеть

ПК>Это единственный способ "этого" избежать, если ты работаешь со злоумышленниками.

при наличии достаточного количества программистов, можно обойтись и без злоумышленников

ПК>От многократного повторения данный тезис более истинным не становится.

no comments

Дарней,

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

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

> Единственный способ этого избежать — запускать каждый сеанс в отдельном процессе.

Это единственный способ "этого" избежать, если ты работаешь со злоумышленниками.

> Хотя это уже 10 раз везде обсуждалось и обсасывалось...

От многократного повторения данный тезис более истинным не становится.

Здравствуйте, prVovik, Вы писали:

AVK>>Зато он поможет в реальной оценке задержек в реальном приложении.
V>Реальные приложения бывают разными...

Я так понимаю вас не устроит любой тест, не доказывающий что .net это полный отстой?

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Зато он поможет в реальной оценке задержек в реальном приложении.
V>>Реальные приложения бывают разными...
AVK>Я так понимаю вас не устроит любой тест, не доказывающий что .net это полный отстой?

Я так понимаю, что должен устраивать любой тест, взятый с потолка?

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, alexeiz, Вы писали:

A>>Зато исключение в Dispose может оставить программу в неопределенном состоянии, и это явно хуже, чем "обрушить прогу"

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

A>>И кстати, не "обрушить", а вызвать terminate(), в котором ты волен произвести необходимые действия перед завершением (послать crash dump разработчику, например).

Д>Программа перестанет работать, не сохранив своих данных, не завершив сеанс работы и т.п. Крэш дамп конечно поможет разработчикам, но юзеру от этого легче не станет

Твоё недоумение скорее всего вызвано непониманием причин, по которым C++ обязывает программу аварийно завершиться при выбросе исключения при обработке другого исключения (скорее всего, когда деструктор выбрасывает). Почитай об этом в clc++.moderated или comp.std.c++. Здесь я, так как у меня нет времени это досконально разъяснять, скажу лишь, что проблеммы при выбросе исключений из деструкторов и из Dispose имеют один и тот же характер. Одна из таких проблем — это выброс исключения при обработке другого исключения, и она может случится, как с выбрасывающими десрукторами, так и с выбрасывающими Dispose. Эта проблемма не имеет удовлетворительного разрешения в том смысле, что невозможно обработать такую ситуацию и продолжить выполнение программы нормальным образом. Что-нибудь обязательно будет сломано в состоянии программы, ты на это можешь наткнуться и сразу вылететь, а можешь совсем не заметить, а можешь и произвести какие-нибудь деструктивные действия (вроде разрушения файлов пользователя при попытке сохранить его данные, эдак подложив пользователю своеобразную свинью).

Далее, тот факт, что .NET в этом случае позволяет тебе продолжить выполниние программы как ни в чём не бывало, является лишь непризнанием данной проблеммы как таковой дизайнерами .NET'а. Параллели между Dispose и деструкторами C++ очевидны. C++/CLI даже ставит их во взаимно однозначное соответствие. Почему дизайнеры .NET'а ничего криминального не увидели в продолжении выполнения программы в этом случае, для меня загадка. Скорее всего это было технически возможно сделать, и они решили "почему бы и нет?" Ведь в .NET программа не упадет при обращении к памяти с нуленым адресом, не перезапишет за пределы массива, т.е не сделает ничего такого, на что вполне способен в такой ситуации "wicked" C++. Поэтому они решили сделать .NET "более надёжным" и в данном случае. Но они не увидели принципиального недетерминированного поведения, access violation и buffer overrun всего лишь частные случаи которого.

Здравствуйте, VladD2, Вы писали:

VD>Если бы Шарп и дотнет имели какие-то серьезные недостатки, то они стабильно бы были в поной заднице по всем пунктам.

С чего это вдруг такой абсурдный вывод?!
Я могу легко привести примеры кода (разного, но решающего одну и ту же задачу) и доказать, что код на javascript в IE даст фору C++ в 400 или более раз. Что с того? Повторяю — код разный.

VD>Ну, а то что они иногда вырываются вперед очень сильно говорит как раз о том, что в Шарповской версии применены лучшие алгоритмы или контейнеры.

Это говорит лишь о том, что "в Шарповской версии применены лучшие алгоритмы или контейнеры". Иными словами, это ничего не говорит о свойствах самого языка. См. аргумент выше.

Влад, всем уже давно понятно, что C# круче вареных яиц. Я лишь возражаю против подобной постановки вопроса:
"С# круче вареных яиц, потому что некие люди решили некую прикладную задачу на нем в 400 раз быстрее, чем она когда-то однажды была решена на C++." См. аргумент выше.

Иными словами, это ничего не говорит ни в пользу C# ни против него. С формальной логикой у тебя все-таки не лады

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В чем именно? Я, например, ссылку дал с объяснением, что именно меня не устраивает в твоем сообщении.

Вот и прочел бы свою ссылку. Она как раз хорошо твои действия описывает.

>> попробуй скачать и запустить ту игрушку. Слушать эту галематью про "паузу" уже сильно надоело.

ПК>Как бы она ни работала, это ничего не скажет относительно верности утверждения

Автор: Павел Кузнецов
Дата: 08.12.04

, к которому ты прицепился, т.к. мы понятия не имеем, не используется ли в игре ручное распределение памяти.

Снова сфероконики? Игра написана на чистом шарпе. Возми Рефлектор (декомпайлер) и убедись в этом лично. Там несколько сборок чистого дотнетного кода. Все импорты там перечислены.

ПК>

ПК>Discussion tries to prove what is right; an argument tries to prove who is right.

И цитататы на английском тоже кончай сувать. Я их лично даже не буду пытаться переводить. Уж на русском форуме я хочу видеть русский текст. Мне и так хватает чего по английски читать.

ПК>К тому же, утверждение "о неправоте" от утверждения "о недостаточности компетенции" отличается вполне заметно. Да и подмену опровержения аргументации оппонента переходом к обсуждению его компетентности не заметить тоже сложно.

Зато ее очень удобно подмечать там где ее нет.

ПК>Так что если не хочешь, чтобы я регулярно напоминал тебе о рамках корректного ведения дискуссии, удерживайся в них самостоятельно.

В прошлом сообщении небыло и намека на твою компетенцию. Там был намек на втюхивание неверной информации. А то что ты на отрез отказывашся убидиться в своей неправоте наводит на мысль о намеренности этого втюхивания.

Еще раз повторюсь, что твои утверждения касательно невозможности приме

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Добавим к процитированному тобой предшествовавший контекст, плюс выделим ключевые слова:

А не надо добавлять. То что сказано уже однозначно выдает позицию.

В общем, не нужно вывертываться. Ты уж если не имеешь мнения, то ничего и не высказывай, а высказа или отказывайся от него или честно его придерживайся.

ПК>Теперь вопрос: ты по-прежнему считаешь, что здесь говорилось о невозможности написания игр на C#, или же о некоторых проблемах, связанных с использованием GC?

Считаю что ты всеми силами пыташся убедить всех в наличи проблем который в природе не существует. И подталкивашь к выводу о неприемлемости Шарпа для данных целей.

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


ПК>Что значит "предпосылки против того, чтобы писать игры на дотнете"? Некоторые проблемы с написанием игр на .Net вообще и C# в частности вполне есть.

Осталось доказать что это не пустые слова. Пока что я вижу имнно это.

ПК> При использовании других языков и платформ — другие проблемы.

А, ну, типа хочешь поговорить о сферокониках?

ПК> Что из этого является меньшим из зол для того или иного разработчика при разработке некоторой конкретной игры — то он и будет использовать.

Ну, в общем, мне все ясно. Когда ты с фактов и т.п. сбивашся на сферокоников — это явный признак, что ты осознал свою неправоту, но просто не хочешь открыто сказать, что ошибался.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это надо в ФАКу

Надо. Как создашь свой сайт, так сразу добавь.

1) C++ более богатый язык, нежели C#. Все средства языка, стандартной библиотеки, среды исполнения, которые есть в C# либо существют в C++ либо можно реализовать на C++. Обратное утверждение не верно.
2) C++ более универсальный язык, чем C#. Все что можно написать на C#, можно написать на C++. Обратное утверждение не верно.
3) Программы на C++ быстрее чем программы на C#. Для любой программы на C# можно написать аналогичню на C++, которая будет работать быстрее. Обратное утверждение не верно.
4) Программы на C++ более переносимы, чем программы на C#. Написанные на С++ программы (при должном уровне программирования) легко переносить на другие платформы, что в случае с C# довольно ограничено.
5) C++ более гибкий язык -- вы можете программировать на уровне ассемблера, а можете использовать языковые средства сверхвысокого уровня. В случае с C# это не верно.
6) На C++ написаны терабайты кода, при желании в сети можно найти библиотки и исходные коды, решающие любые задачи: от операционной системы, до движка для игры.
7) Для программ на C++ не нужны мегабайты дополнительных библиотек.
...

Этот список можно продолжать еще очень долго. Я срашиваю у сторонников C#: "что же может предложить это еще одно сомнительное изобретение Майкрософт в ответ на всю мощь, скорость, экспрессивность, гибкость и богатсвто C++?"

Здравствуйте, Дарней, Вы писали:

ГВ>>Я бы не стал называть это поиском проблем. Скорее уж, попыткой избавиться от каких-то неприятностей, свойственных традиционным решениям.
Д>Просто я прекрасно могу представить, какое количество проблем они приобретут взамен. И еще не факт, что применение C++ избавит их от старых.
Д>C++ очень опасно применять для кода, который регулярно будет изменяться, особенно — если это серверный код.

Опасно реализовывать непродуманные и поспешные решения. Вот это — в самом деле опасно. А на каком языке — да какая разница! Если научился писать багоустойчивый код на C++, то большой разницы между кодированием сервера и "клиента" уже нет. А если нет, то...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ну, тогда остаемся в текущей ситуации. Я высказал ряд тезисов с некоторой аргументацией.

Я бы сказал: кучу и без аргументации.

Здравствуйте, Павел Кузнецов, Вы писали:

>> Так что оставь сказаки про ЖЦ тем кто никогда с ним не сталкивался лично.

ПК>http://blacklight.h1.ru/oppo09.htm
ПК>

Демагогия с переходом на личности
ПК>d. Обвинение оппонента в незнании предмета обсуждения

Демагогия это твои слова. Кончай ее и таки попробуй скачать и запустить ту игрушку. Слушать эту галематью про "паузу" уже сильно надоело.

ЗЫ

И кончай чуть что прикрываться переходом на личности. А то уже тоже не смешо... лбое утверждение о твоей неправоте ты сразу объявляешь переходом на твои личности.

Здравствуйте, VladD2, Вы писали:

S>>Помню слышал те же слова от явовщиков...
VD>А я вот не помню.
Значит, ты не застал ту пору, когда Java только-только выпихивалась на рынок.

S>>Ну и как, Java заменила С++?
VD>В создании ПО для бизнеса — полностью.
Это в какой местности такая беда стряслась?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, prVovik, Вы писали:

VD>>>Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений.

VD>>>И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код.
V>>Гы, а что мешает делать то же самое в С++?

VD>Тут вроде бы уже 100 раз это говорили. Теоритически ничего. Практически весь дизайн языка.

Истерика какая-то. Сам же сказал, что что в деструкторах, что в диспозе исключения кидаться не должны. А насчет дизигна языка — а можно конкрено описать, как дизайн языка мешает мне как разраюотчику писать try/catch в деструкторе и не выпускать оттуда исключения?

VD>Ну, давай еще раз по пунктам:
VD>1. Повторная генерация исключения в диспозе или вообще не приводит к фатальным проблемам, или приводит обычно к потере одного ресурса, так как остальные диспозы вызываются из любого положения. При этом с огромной долей вероятности потерянный ресурсный объек реализует и финалайзер, так что он будет подобран при первой же сборке мусора. Если он не успел попасть в первое поколение, то это вопрос нескольких десятых долей секунды (максимум секунд). В С++ же повтораное генерирование исключений обычно приводит к вылету всейго приложения. Именно по этому при малейшем сборее мы видим AV-диалоги у большинства приложений окружающих нас сегодня.

Мы их видим не потому, что они на плюсах. Мыих видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.

VD>2. Необходимость ручного контроля в С++ не только за ресурсами ОС, но и за любыми динамически занятыми областями памяти. Это приводит или к ловле ликов и попыткам "окуратного" программирования, или к наклепыванию оберток на каждый чих. Четыре года назад наша контора придерживалась второго подхода, но тем не менее в конце концов пришлось писать нехилую систему отлова утечек памяти и в общемй сложнсоти убить не млао времяни на отладку в общем-то рабочего кода.

Все обертки давно наклеины Ваще долго тут читал ваши споры, много интересных мыслейЮ, но блин не смог сдержаться Тебя послушать, так до появляения .нет писалово программ было сущим адом — и обертки приклей, и лики лови годами, и надежности никакой, и сплошной AV. жуть... как же жыли то раньше...

VD>3. Отсуствие того же finally.

Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась

VD>4. Ненацелленность многих С/С**-библиотек на автоматический контроль ресурсов. Вспомним хотя бы CreateFile или fopen.

ну ты вспомнил ты еще какой нить int открывающий файл вспоми тот же std::ofstream абсолютно нормально особождает ресурс после разрушения. При чем детерминированно...

VD>Для того чтобы просто не получить кучи проблем, программист должен постоянно придерживаться целой кучи паттернов оберегающих его от граблей, и по стуи избегать тех самых мощьных возможностей С++, коими многие так часто гордятся. В итоге мы получаем ситуацию, ктода для написания одного и того же кода (что с точки зрения функциональности, что с точки зрения производительности) нам требуется соврершенно разный уровень квалификации программиста, совершенно разное время на решение задачи, и совершенно разное количество усилий.

Да не должен он ничего избегать — все мощные возможности в его распоряжении. Покажи мне пожалуйста пример того, как программисту на с++ приходится отказываться от какой-нить мощной возможности, чтоб не наступить на грабли?
Насчет времени готов спорить... Все очень зависит от задачи. Действительно, есть класс задач, в которых шарп выиграет по скорости разработки. Это задачи, которые не обладают сколь-нибудь значимой алгоритмической сложностью, а являются просто компоновкой тех или иных фич, типа там файлик открыли, прочитали, в мемо в окошке содержимое вывели, закрыли. Всякий там бухучет, который некритичен по времени исполнения, и который есть просто нагромождение кучи возможностей по выгребалову данных из юазы и их отображению, то есть где по сути все сводится к функциональностям типа add/delete/update/print report. Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени, что выигрышь в собственно кодировании будет весьма условный. Тут уже не в языке дело по сути, потому что что в плюсах, что в шарпе — везде есть свои нюансы — тамследишь за памятью, там завызовами диспозов — и все зависит от задачи. Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте. почему так? Наверное потому что плюсы их устраивают. То есть (как мне лично кажется) не имеет смысла переходить на новую технологию с уже обкатанной, если производственный процесс укладывается в установленные рамки. А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.

VD>Остается только один вопрос... Нафига козе баян?

Глубоко философский вопрос...

Дарней,

> ПК>Что-то я не очень понимаю, как unsafe поможет в достижении перечисленных выше моментов...

> Просто для всего, что ты перечисил, в C# есть аналог или что-то на замену.

Имхо, есть существенные отличия у предлагаемых "альтернатив"...

> шаблоны, позволяющие контролировать часть семантических ограничений во время компиляции, (generics не в счет)

"generics не в счет" не из-за того, что они "еще недоступны для большинства", а из-за их ограниченности

Автор: Павел Кузнецов
Дата: 20.11.04

. Считать это положительным или отрицательным моментом — дело вкуса. Однако для тех, кому нужна функциональность "полных" шаблонов C++, generics адекватной заменой не являются.

> размещение объектов в стеке + деструкторы, что позволяет автоматизировать освобождение ресурсов

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

> "свободные" функции

Этого вообще нет.

> А вот для тех (редких) случаев, когда производительности C# не хватает — для них и нужен unsafe

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

Здравствуйте, VladD2, Вы писали:

VD>А что до "методологически некорректными", они сравнивают две версии одного движка. Естественно на одинаковом железе и при одинаковых условиях (обратное твои домыслы), и делают они это совершенно корректно. То что их алгоритмы лучше не умаляет качества движка.

Что-то у тебя с логикой не лады. "Две версии одного движка" никак не могут дать столь существенной разницы при условии идентичности алгоритмической части. Следовательно, используемые алгоритмы существенно отличаются, следовательно, сравнение производительности с точки зрения используемых компиляторов — некорректно. Иными словами, мы должны сравнивать, наколько GC влияет на производительность, а мы сравниваем разные алгоритмы. Так понятней?

Да и вообще, поменьше бы агрессивности.

Здравствуйте, AndrewVK, Вы писали:

ГВ>>Тогда этот замер ничем не поможет в оценке произаодительности.
AVK>Зато он поможет в реальной оценке задержек в реальном приложении.

Ну да, согласен. Для оценки аппетита сферо... этого... в этом... как его...

Здравствуйте, McSeem2, Вы писали:

VD>>Если бы Шарп и дотнет имели какие-то серьезные недостатки, то они стабильно бы были в поной заднице по всем пунктам.

MS>С чего это вдруг такой абсурдный вывод?!
MS>Я могу легко привести примеры кода (разного, но решающего одну и ту же задачу) и доказать, что код на javascript в IE даст фору C++ в 400 или более раз. Что с того? Повторяю — код разный.

В производительности 3D-движка? Ну, покажи. Ты не забыл о чем идет речь? Или просто пытаешся тему подменить?

VD>>Ну, а то что они иногда вырываются вперед очень сильно говорит как раз о том, что в Шарповской версии применены лучшие алгоритмы или контейнеры.

MS>Это говорит лишь о том, что "в Шарповской версии применены лучшие алгоритмы или контейнеры". Иными словами, это ничего не говорит о свойствах самого языка. См. аргумент выше.

Нет. Это еще говорит и о том, что проблем в использовании ЖЦ нет. И что расказы о паузах — это всего лишь сказки которые пытаются выдать за действительность.

MS>Влад, всем уже давно понятно, что C# круче вареных яиц.

Я пока что вижу агалтелых его противников пытающихся за ужи притянуть разные сказочные обоснования его неприменимости. А его крутости речь собственно не идет. Для меня C# — это веха в развитии импиративных языков, и за одно начало заката С++. Неболее того.

MS> Я лишь возражаю против подобной постановки вопроса:

Возразишь ротив совбственной постановки вопроса? А зачем тогда его было так ставить?

MS>"С# круче вареных яиц, потому что некие люди решили некую прикладную задачу на нем в 400 раз быстрее, чем она когда-то однажды была решена на C++." См. аргумент выше.

Чушь и понты. Шарп не дает 400 раз в скорости. Раза 3-10 в лучшем случае. Однако уж 2 он дает в 90% задач. Но только по сравнению с плюсами. И если я имею гарантированные 2х ускорения разработки, а прой и больше, при этом теряя проценты производительности конечного приложения, то я невижу основания викидывать деньги и время на ветер.

MS>Иными словами, это ничего не говорит ни в пользу C# ни против него. С формальной логикой у тебя все-таки не лады

Здесь обсуждался вопрос неприемлемости использования Шарпа в 3D-играх. По этому поводу какие-нибудь аргументы есть? Или признаем все попытки признать это мнение обычной инсинуацией?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Впрочем, мы усвоили десять великих истин форума RSDN/Философия:

Это надо в ФАКу

Честно говоря, у меня вызывают умиление люди, которые говорят, что один язык _лучше_ другого. Вообще, предикат лучше не стоит использовать без дополнительных поясняющих условий, иначе он теряет всякий смысл.

Что же касается до Си, скажу следующее: Си язык в некотором роде уникальный -- он отражает то, что есть на реальном железе. Он естественен по своей структуре. Поэтому он не погибнет _никогда_, ведь трудно придумать более подходящего решения для создания самых нужных, основопологающих вещей -- операционных систем, СУБД, компиляторов, кодеков, компрессоров\декомпрессоров\архиваторов и проч. и проч.

Си++ имеет все преимущества Си, плюс он развивает его в том смысле, что вы можете делать на Си++ все что вам вздумается. Вы можете сделать сборку мусора, дефрагментатор памяти, умные указатели. Вы можете быть настолько свободны, насколько захотите. И это самое большое преимущество Си и Си++.

Когда же язык _заставляет_ меня делать что-то, что я считаю неправильным, то я отказываюсь от такого языка.

S>Здравствуйте, slegkapjan, Вы писали:
S>Люблю я этот форум. Аншлаг отдыхает.
Аншлаг действительно отдыхает.

S>>1) C++ более богатый язык, нежели C#. Все средства языка, стандартной библиотеки, среды исполнения, которые есть в C# либо существют в C++ либо можно реализовать на C++.
S>Да-да-да. Продемонстрируй мне Code Access Security на С++ (неуправляемом).
Честно говоря не совсем понимаю термин "Code Access Security". Если под этим понимается доступ (чтение/запись) к коду, то это вполне возможно в рамках ОС.

S>> Обратное утверждение не верно.
S>И что же такого из плюсов нельзя реализовать на C#?
S>>2) C++ более универсальный язык, чем C#. Все что можно написать на C#, можно написать на C++. Обратное утверждение не верно.
S>И что же такого из плюсов нельзя реализовать на C#?
Операционную систему.

S>>3) Программы на C++ быстрее чем программы на C#. Для любой программы на C# можно написать аналогичню на C++, которая будет работать быстрее.
S>Да ну правда что ли? Ускоряем прямо любые-любые программы? Как будем мерить производительность? На прогретой машине?
Это вообще неспортивно вести спор таким образом. C# медленнее чем C++, и не стоит хамить раз уж нет достойного ответа.

S>>Обратное утверждение не верно.
S>>4) Программы на C++ более переносимы, чем программы на C#. Написанные на С++ программы (при должном уровне программирования) легко переносить на другие платформы, что в случае с C# довольно ограничено.
S>А можешь подробнее изложить свои заблуждения об ограничениях легкости переноса C# на другие платформы?
Пожалуйста. Можно ли перенести программу на C# под Palm OS?

S>>5) C++ более гибкий язык -- вы можете программировать на уровне ассемблера, а можете использовать языковые средства сверхвысокого уровня. В случае с C# это не верно.
S>Какие возможности С++ по программированию на уровне ассемблера отстутствуют в C#? Какие языковые средства сверхвысокого уровня С++ отстутствуют в C#? Чем можно безуспешно попытаться заменить метаинформацию в С++?
Любые средства C# можно успешно заменить средством C++.

S>>6) На C++ написаны терабайты кода, при желании в сети можно найти библиотки и исходные коды, решающие любые задачи: от операционной системы, до движка для игры.
S>>7) Для программ на C++ не нужны мегабайты дополнительных библиотек.
S>Да? А как же терабайты кода из пункта 6? Или они уже перестали быть нужны?
Опять неспортивное поведение.

S>>Этот список можно продолжать еще очень долго.
S>Да. А можно остановиться и подумать.
Еще раз неспортивное поведение.

S>>>Да-да-да. Продемонстрируй мне Code Access Security на С++ (неуправляемом).
S>>Честно говоря не совсем понимаю термин "Code Access Security". Если под этим понимается доступ (чтение/запись) к коду, то это вполне возможно в рамках ОС.
S>А ты пойди и почитай. Грубо говоря, это возможность разрешать коду из пакета А выполнять код из пакета B, а коду из пакета C запрещать это делать.
Зачем запрещать что-то? Между C++ и C# есть разница в философии построения языка.

S>>>> Обратное утверждение не верно.
S>>>И что же такого из плюсов нельзя реализовать на C#?
S>>>>2) C++ более универсальный язык, чем C#. Все что можно написать на C#, можно написать на C++. Обратное утверждение не верно.
S>>>И что же такого из плюсов нельзя реализовать на C#?
S>>Операционную систему.
S>Ну-ну. А что, у нас есть примеры операционок на чистом С++? Или все-таки там фрагменты runtime на асме написаны?
Для большиства операционок небольшая часть кода написана на ассемблере, остальное на C++. Опять же C# использовать вместо C++ в этой связке невозможно.

S>>Это вообще неспортивно вести спор таким образом. C# медленнее чем C++, и не стоит хамить раз уж нет достойного ответа.
S>Спортивно-спортивно. Просто ты несешь такую чушь и с таким апломбом. Ты хоть понимаешь, что выражение "ускорить любую программу" означает примерно то же самое, что и "сжать любой бинарный вектор"? И точно так же можно построить программу на C#, которая будет джиттиться в неулучшаемый код?
Посмотри внимательнее на посты. Я не использовал термина "усокрить"

S>>>А можешь подробнее изложить свои заблуждения об ограничениях легкости переноса C# на другие платформы?
S>>Пожалуйста. Можно ли перенести программу на C# под Palm OS?
S>Да нет проблем. Ну нет (пока) фреймворка под палмос. Ну и что? Язык-то это как затрагивает?
А скажи пожалуйста, ты думаешь что можно в принципе написать фреймворк C# для любой платформы?

S>>>>5) C++ более гибкий язык -- вы можете программировать на уровне ассемблера, а можете использовать языковые средства сверхвысокого уровня. В случае с C# это не верно.
S>>>Какие возможности С++ по программированию на уровне ассемблера отстутствуют в C#? Какие языковые средства сверхвысокого уровня С++ отстутствуют в C#? Чем можно безуспешно попытаться заменить метаинформацию в С++?
S>>Любые средства C# можно успешно заменить средством C++.
S>Перечитай вопрос. Приведи пример успешной замены метаинформации в C# эквивалентным средством С++.
Скажи конкретные вещи, как они должны работать и я тебе приведу аналог в C++.

S>>>>6) На C++ написаны терабайты кода, при желании в сети можно найти библиотки и исходные коды, решающие любые задачи: от операционной системы, до движка для игры.
S>>>>7) Для программ на C++ не нужны мегабайты дополнительных библиотек.
S>>>Да? А как же терабайты кода из пункта 6? Или они уже перестали быть нужны?
S>>Опять неспортивное поведение.
S>А по существу?
Я просто как раз-то и не понимаю сути вопроса. Ты можешь сказать конкретно что тебя интересует?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Отчего же... Наоборот, хотят языковую поддержку для move constructors ввести. Это не "грабли", это "фича" — специальный способ указать на передачу владения. Если эта семантика не нужна, следует использовать другие указатели.

Нужно было просто не делать передачу владения неявной. И не пришлось бы тогда писать вумные книжки с советами наподобие "никогда не создавайте контейнеры из auto_ptr". Мне например кажется просто диким, что operator= изменяет свой правый аргумент.

И все-таки, возвращаясь к деструкторам. Допустим, Dispose бросает исключение. и часть объектов остались незавершенными. Однако завершение остальных объектов будет продолжаться.
С++ в аналогичной ситуации просто "умывает руки", и вообще отказывается освобождать ресурсы проги. Можно конечно попытаться это сделать из terminate, но я сомневаюсь, что из этого может получиться что-то путное. В семействе NT это не будет иметь катастрофических последствий, но то же самое нельзя сказать про ряд других ОС. Плюс к этому, прога может иметь ряд ресурсов, которые не управляются ОС — сеансы работы на сервере приложений, транзакции БД, например. Они конечно будут закрыты через некоторое время по таймауту, но за это время "повисшие" ресурсы могут парализовать работу ряда других юзеров. В результате такое поведение проги может вызвать неопределенное поведение в рамках всей операционной системы юзера, или в рамках корпоративной ИС
С этой точки зрения намного правильнее все-таки попытаться освободить ресурсы, какие получится. И только после этого — может быть, завершить программу.

из предисловия к книге Ал. Стивенса "ТЕХНИКА ПРОГРАММИРОВАНИЯ НА ТУРБО СИ"]

В данной книге вы столкнетесь с программами, написанными на
языке Си. Это замечательный язык, и хотя некоторым он не
нравится, но все же большинство программистов его любят. На Си вы
можете создавать программы, которые делают все, что вы пожелаете.
Нет другого такого языка, который бы так же стимулировал к
программированию. Создается впечатление, что остальные языки
программирования воздвигают искусственные препятствия для
творчества, а Си — нет. Использование этого языка позволяет
сократить затраты времени на создание работающих программ. Си
позволяет программировать быстро, эффективно и предсказуемо. Еще
одно преимущество Си заключается в том, что он позволяет
использовать все возможности вашей ЭВМ. Этот язык создан
программистом для использования другими программистами, чего о
других языках программирования сказать нельзя ............
.................................................................
.................................................................
...создан таким, чтобы менеджеры могли разбираться в написанных
этом языке программах; Бэйсик был создан для непрограммистов;
Фортран — для научных работников; Ада вообще был создан
прямо-таки правительственным комитетом; Пайлот создан для
учителей; Паскаль — для студентов; Лого — для детей; АПЛ — для
марсиан; Форт, Лисп и Пролог — специализированные языки. Один Си
— это язык для программистов.

Здравствуйте, VladD2, Вы писали:

VD>Пока. Как видишь первые ласточки уже есть. Со временем народ поймет, что писать несистемный код на С/С++ — это тоже самое, что зарывать деньги в песок на поле дураков. Думаю, что когда появится официальный C# 2.0, и когда выдет в свет Феникс, разговоры о применении C# в любой сфере прикладного программирования (за исключением наверно приложений реального времени) уйдут в небытие.

Помню слышал те же слова от явовщиков... Ну и как, Java заменила С++?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я бы не стал называть это поиском проблем. Скорее уж, попыткой избавиться от каких-то неприятностей, свойственных традиционным решениям.

Просто я прекрасно могу представить, какое количество проблем они приобретут взамен. И еще не факт, что применение C++ избавит их от старых.
C++ очень опасно применять для кода, который регулярно будет изменяться, особенно — если это серверный код.

Здравствуйте, Павел Кузнецов, Вы писали:

>> C++ очень опасно применять для кода, который регулярно будет изменяться, особенно — если это серверный код.

ПК>Это почему?

Типа, сам не знаешь и решил повысить свой образовательный уровень?

Здравствуйте, Павел Кузнецов, Вы писали:

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

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

McSeem2,

> VD> Сборка мусора в среднем занимает около 10 милесекунд с интервалом несколько секунд. А то и реже/быстрее.

> Уупс. Целых 10 миллисекунд?! Куда столько?! — этож почти целый кадр. Как говорится в малоизвестном стишке "вы охренели, братья румыны". За 10 миллисекунд я успеваю чисто софтварно отрендерить целую страницу мелкого текста (и Adobe Acrobat, кстати, тоже успевает).
> Может все-таки, 10 микросекунд?

Нет, именно миллисекунд. И это не потолок, скорее, характерное время для сбора мусора первого поколения. Сбор объектов поколения 2 может занять значительно дольше.

http://support.microsoft.com/default.aspx?scid=/servicedesks/webcasts/en/wc050102/wct050102.asp

If you look at the actual cost of garbage collecting, that's not collecting that memory that you've allocated, typically a GC of Generation 0 is similar to that of a page fault, so it's fairly cheap. If you look at the actual time that a Generation 0 garbage collection takes, it's typically between 0 and 10 milliseconds, which is fairly short. And then a collection of Generation 1 is typically between 10 and 30 milliseconds. Obviously, the GC of Generation 2 is going to be dependent on what your working set it, but full GCs should not happen that often.

Соответственно, в основном все будет хорошо, но периодически, при запуске уборки поколения 1, кадры будут выпадать, а иногда, при запуске уборки поколения 2, будут паузы, заметные пользвователю. Периодичность этих явлений будет сильно зависить от сценариев работы с памятью. И, в принципе, если реализовать все критичные действия по работе с памятью вручную, как, например, это сделано в Quake, то можно эти эффекты свести к минимуму. Вопрос только в стоимости разработки с ручным управлением памятью на системе, для этого не предназначенной.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Нет, именно миллисекунд. И это не потолок, скорее, характерное время для сбора мусора первого поколения. Сбор объектов поколения 2 может занять значительно дольше.

ПК>http://support.microsoft.com/default.aspx?scid=/servicedesks/webcasts/en/wc050102/wct050102.asp
ПК>

ПК>If you look at the actual cost of garbage collecting, that's not collecting that memory that you've allocated, typically a GC of Generation 0 is similar to that of a page fault, so it's fairly cheap. If you look at the actual time that a Generation 0 garbage collection takes, it's typically between 0 and 10 milliseconds, which is fairly short. And then a collection of Generation 1 is typically between 10 and 30 milliseconds. Obviously, the GC of Generation 2 is going to be dependent on what your working set it, but full GCs should not happen that often.

Ты бы хоть читал внимтельно. Да и ссылки на доисторические статьи давать не очень разумно. Есть статьи и по новее, где цифорки намного скромнее. Плюс надо понимать, что это цифры в рассчете на компьютер удовлетворящий минимальным требованиям, и цифры эти получаются при самых скромынх раскладах.

В любом случае выделение памяти в фрагментированном хипе может занять куда большее время. Но про это почиму-то никто не вспоминает.

Так что оставь сказаки про ЖЦ тем кто никогда с ним не сталкивался лично. На практике заметить сборку мусора на глаз невозможно в принципе.

VladD2,

> ПК>Ну что за манера подменять позицию собеседника?.. Этого я не утверждаю и не утверждал. Речь шла о проблемах, которые может вызывать GC. Еще в первом сообщении на эту тему было указано, что проблемы решаемые.

Добавим к процитированному тобой предшествовавший контекст, плюс выделим ключевые слова:

ПК>Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.

> Re[41]: Опять С++ vs С#

Автор: Павел Кузнецов
Дата: 11.11.04

>

> Ага. Мнений море. Вот только чущь полная. Игры то работают.

> С интенсивной 3D графикой на .Net? Какие? Quake не считается, т.к. он написан очень своеобразно: ему GC вообще почти параллельна. Но писать так все игры никто не будет, ибо очень дорого:...

Теперь вопрос: ты по-прежнему считаешь, что здесь говорилось о невозможности написания игр на C#, или же о некоторых проблемах, связанных с использованием GC?

> ПК>P.S. На этом я данное обсуждение с тобой закачиваю, если, конечно, вдруг, не последует какая-то новая информация.

> Ну, тоесть ты согласен, что собственно предпосылок против того чтобы писать игры на дотнете нет? И что реальные игры на дотнете есть и очень даже неплохо работают?

Что значит "предпосылки против того, чтобы писать игры на дотнете"? Некоторые проблемы с написанием игр на .Net вообще и C# в частности вполне есть. При использовании других языков и платформ — другие проблемы. Что из этого является меньшим из зол для того или иного разработчика при разработке некоторой конкретной игры — то он и будет использовать.

Здравствуйте, McSeem2, Вы писали:

MS>Так уж исторически сложилось, что я привык спорить с вменяемыми собеседниками. А риторику я не изучал и в ней не силен. Извини еще раз.

Ну, что достойная позиция в споре — вместо аргументов начать разбираться во вменяемости оппонента. Что и следовало ожидать.

Думаю, ты еще не раз задумаешся над вопросом кто из нас более вменяем.

Здравствуйте, slegkapjan, Вы писали:
Люблю я этот форум. Аншлаг отдыхает.
S>1) C++ более богатый язык, нежели C#. Все средства языка, стандартной библиотеки, среды исполнения, которые есть в C# либо существют в C++ либо можно реализовать на C++.
Да-да-да. Продемонстрируй мне Code Access Security на С++ (неуправляемом).
S> Обратное утверждение не верно.
И что же такого из плюсов нельзя реализовать на C#?
S>2) C++ более универсальный язык, чем C#. Все что можно написать на C#, можно написать на C++. Обратное утверждение не верно.
И что же такого из плюсов нельзя реализовать на C#?

S>3) Программы на C++ быстрее чем программы на C#. Для любой программы на C# можно написать аналогичню на C++, которая будет работать быстрее.
Да ну правда что ли? Ускоряем прямо любые-любые программы? Как будем мерить производительность? На прогретой машине?
S>Обратное утверждение не верно.
S>4) Программы на C++ более переносимы, чем программы на C#. Написанные на С++ программы (при должном уровне программирования) легко переносить на другие платформы, что в случае с C# довольно ограничено.
А можешь подробнее изложить свои заблуждения об ограничениях легкости переноса C# на другие платформы?
S>5) C++ более гибкий язык -- вы можете программировать на уровне ассемблера, а можете использовать языковые средства сверхвысокого уровня. В случае с C# это не верно.
Какие возможности С++ по программированию на уровне ассемблера отстутствуют в C#? Какие языковые средства сверхвысокого уровня С++ отстутствуют в C#? Чем можно безуспешно попытаться заменить метаинформацию в С++?
S>6) На C++ написаны терабайты кода, при желании в сети можно найти библиотки и исходные коды, решающие любые задачи: от операционной системы, до движка для игры.
S>7) Для программ на C++ не нужны мегабайты дополнительных библиотек.
Да? А как же терабайты кода из пункта 6? Или они уже перестали быть нужны?

S>Этот список можно продолжать еще очень долго.
Да. А можно остановиться и подумать.

Здравствуйте, alexeiz, Вы писали:

ГВ>> Да нет, по сути дела, никто не мешает и сейчас сделать некий аналог C++ server pages, и проблема в другом — не все хостеры будут рады такой технологии. А проблему со временем отклика можно урегулировать.

A>ATL Server?

Не, вот это: C++ server pages

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот не надо гнать, ладно?

ГВ>Ходи сюда и смотри. Крайний апдейт — 18 ноября этого года.

выдержки с той странички:

Incredibly high processing efficiency. Benchmarks have shown a range of 80 to 250 times higher processing speed than ASP.


The use of pure C++ allows the use of tons of libraries that are currently available. It is important to notice that the libraries written in C++ are tens or hundreds of times more than in any other language.


It is widely accepted that the most skilled programmers in the IT market are the C++ ones. However, CGI, ISAPI and other frameworks where C++ applies, do not provide the web developer with facilities for efficient application development. As a result, until now, Web Development could not take advantage of the best programmers.


The processing efficiency of CSP allows the use of affordable systems even for complex Web Applications with heavy algorithms.


The ability of making direct system calls, allows the development of advanced web applications that are impossible with ASP and JSP. For example, it is possible for a CSP page to use multiple threads and do blocking tasks (credit card check, database queries etc.) simultaneously and hence faster, whereas such an accomplishment is only a dream for other technologies.

After exhaustive performance tests of many millions of HTTP requests, the engine has proven absolute stability.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не, вот это: C++ server pages

не перестаю удивляться упорству, с которым люди ищут проблем на свои задницы

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не фреймворк, а библиотеку (т.е. на структуру программы ограничений она не накладывает). И разрабатывать с нуля не надо — уже давно есть. И не одна. Если в какой-то что-то не устраивает, всегда можно доработать. Благо, с открытым кодом хватает.

Если не накладывает, то грош ей цена. Никакой защиты она тогда не даст.
В том и проблема — что не одна. Потому что в одной библиотеке есть одна хороая вещь, в другой — другая, и так далее. В результате прога превращается в конгломерат из библиотек третьих разработчиков, в котором сам черт ногу сломит. (именно поэтому во многих больших фирмах разрабатывают свои библиотеки кода, а за использование постороннего кода бьют по рукам)

ПК>Нет. С# не включает множества вещей, которые вполне останутся: шаблоны, позволяющие контролировать часть семантических ограничений во время компиляции, (generics не в счет), размещение объектов в стеке + деструкторы, что позволяет автоматизировать освобождение ресурсов, "свободные" функции и т.п. Если бы язык, действительно, являющийся "улучшенным C++", освобожденным от совмстимости от C, уже был бы создан, обсуждать было бы нечего. Java и C# таковыми не являются и близко. Это легко увидеть при сравнении наиболее типичных подходов в каждом из этих языков.

В 99,9% случаев их хватает. А для оставшегося есть unsafe.
Я конечно не спорю, что C++ дает больше возможностей. И как программист я с этим совершенно согласен, и даже очень люблю C++ Но вот как человек, который разгребает чужой код и пытается проконтролировать правильность кодирования — люто его ненавижу

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

Упомянутая мной компания занимается разработкой самого обычного софта.. только этот софт стоит не на нескольких десятках машин, а на многих-многих тысячах. Ни в каких критически важных областях он не используется.

ПК>Для приложений с повышенными требованиями к устойчивости code review — фактически, неизбежное дело, вне зависимости от языка.

другой вопрос, насколько сильно он будет нужен

ПК>При наличии достаточного количества программистов с низкой квалификацией. Тут уже никакой язык не поможет.

А это и есть самый рядовой случай. Программистов с высокой квалификацией просто по определению не может быть много.
Именно поэтому и придумали C# с Явой — чтобы даже самая законченная обезьяна с гранатой не смогла слишком много набедокурить

ПК>Гм... А что, становится? Если нет, то какая разница, сколько раз это уже обсуждалось?

Многие люди отказываются от C++, и среди них немало людей с высокой квалификацией. И делают они это совсем не от хорошей жизни.

Кажется мне, что мы очень сильно отвлеклись от основной темы

vdimas,

> VD>Таких море. Просто понятие комерческого успеха сильно растяжимо. Есть и игры,

> Нет коммерчески успешных игр и не предвидится еще ооочень долго. Цикл разработки современной игрухи ныне 2-3 года, пока мы не слышали анонсов о том, что кто-то из заметных игроков на этом рынке начал писать на дотнете современный 3D-движок.

Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.

Здравствуйте, VladD2, Вы писали:

VD>Минимальные требования для дотнета — это PII 450. Так что на 2 ГГц — это будет где-то менее 2.5 милисек. И опять же в худшем случае, плюс раз в квартал.

Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.

Serginio1,

> ПК> А как будет происходить создание/удаление объектов? Через MyAllocator.new()/MyAllocator.delete()? IMHO, без детерминированных деструкторов и возможности перегрузки operator new "ручная" работа с памятью значительно осложняется...

> Можно и через TMyAllocator.Create TMyAllocator.Free
> Так или иначе даже при хорошем менеджере памяти, создание своего специально заточенного под определенный размер менеджера памяти вполне тривиальная задача и в нативе.

Я, наверное, недостаточно четко расставил акценты. Самой важной является выделенная часть. Именно это я и имел в виду ранее, говоря о "стоимости разработки с ручным управлением памятью на системе, для этого не предназначенной". В этом смысле, имхо, самым хорошим решением было бы сочетание плюсов от обоих миров: GC + средства для "ручного" управления памятью в виде детерминированных деструкторов и т.п. На первый взгляд в этом отношении C++/CLI кажется вполне удачным вариантом.

Здравствуйте, VladD2, Вы писали:

VD>ArenaWarsDemoEnglishAndGerman.exe

Так что у товарией наставивших минусы игрушка не запустилась? Или аргументы кончились?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>vdimas,

>> VD>Таких море. Просто понятие комерческого успеха сильно растяжимо. Есть и игры,

>> Нет коммерчески успешных игр и не предвидится еще ооочень долго. Цикл разработки современной игрухи ныне 2-3 года, пока мы не слышали анонсов о том, что кто-то из заметных игроков на этом рынке начал писать на дотнете современный 3D-движок.

ПК>Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.

So, it seems to me the only way to get good game performance from C# will be to eliminate ALL allocations from within the frame loop itself. Now, if you imagine the sort of code you're going to have to write to do that... it't starts making new and delete look pretty simple and cozy. You'll end up with something that looks like the quake source: fixed size tables all preallocated, arbitrary limits and tuning parameters everywhere. Bleh.

кхе...

Здравствуйте, VladD2, Вы писали:

VD>А что ж так? Такой виликий языки и вдруг сайты не тяент? Не уж-то надежности не хватет?

интерпретируемости не хватает.
а ты не знал, что С++ предназначен для компиляции?

V>>Тут дотнет отнимает рынок у ASP и PHP, опять же, не у С++, ибо на С сайты были, на С++ наверно уже нет (из-за того, что perl поспел одновременно с С++)

VD>Ага. Потому-что даже дохлые скрипты вроде ASP и PHP и те смогли у С++ тут рынок отнять. А ведь первые динамические сайты писались как раз на С/С++. CGI помнишь?

прекрасно помню. в твоей фразе ключевое слово — "скрипты".
второе ключевое слово — "дохлые"

кстати, ситуевина.
есть сервак приложений на С++. К нему добавили вэб-интерфейс на ASP. так на чем сайт?

панимашь, писать алгоритмы — это одно, а при разработке сайтов 90% работы — это проставление визуальных св-в у элементов. тут нужна среда, которая не требует компиляции. видел как сайт-девелопер работает? подкрутит что-то — тут же просмотрит страницу в соседнем окне, и т.д.

и еще. эти ASP и PHP отобрали рынок у С++ в период WWW-бума, когда вчерашние кухарки переучивались на вэб-мастеров. (именно так и обстояли дела в штатах). Тупая несложная работа, а С++ программеру платить надо

VD>Погоди немного и код на С++ будешь искать в красной книге.

между словами "и" и "код" вставил бы слово "хороший".

а плохой я буду искать в исходниках очередного Ротора.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Кроме того, CGI изначально считался относительно медленным, ибо запуск дополнительного процесса.

AVK>Про FastCGI никогда не слышал?

да, в период PHP-бума, когда кухарки переучивались на вебмастеров, это перспективное направление успешно похерили.

мешало еще на тот момент то, что в юнихах не было единой модели threads. тогда как раз в линухе появились динамически подгружаемые модули, можно было бы развить до очень эффективной системы...

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vdimas, Вы писали:

V>>Какой DX по счету будет полностью на дотнете писан?

AVK>А зачем?

собственно, к этому вопросу я и вел

Здравствуйте, Дарней, Вы писали:

ГВ>>Не, вот это: C++ server pages
Д>не перестаю удивляться упорству, с которым люди ищут проблем на свои задницы
Я бы не стал называть это поиском проблем. Скорее уж, попыткой избавиться от каких-то неприятностей, свойственных традиционным решениям.

VladD2,

> Неплохо было бы аргументировать этот набор ничем не обоснованных заявлений.

Гм... Читать умеем? Аргументация и/или примеры присутствуют. Если какие-то из аргументов полагаешь недостаточными, приводи контрпримеры, опровергай и т.п. Если есть какие-то конкретные положения, для которых аргументация отсутствует, указывай конкретно.

VladD2,

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

> Довольно глупо переписывать половину твоих реплик.

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

Здравствуйте, VladD2, Вы писали:

MS>>Может все-таки, 10 микросекунд?

VD>Это уже сравнимо с тактами процессора. И такие результаты могут быть только в нулевом поколении, объем памяти которого подгоняется под размер кэша процессора.

Да не особо. 2 ГГц, 10 микросекунд — это 20000 тактов, не так уж и мало.

VD>PS
VD>И все же, скачай таки ArenaWarsDemoEnglishAndGerman.exe и поиграй пору часиков. Заметишь хоть одну паузу, расскажи. Ну, а если не заметишь то перестань дезинформировать людей повторяя глупость про ЖЦ раз за разом.

В ответ на это я процитирую извесный мультик

- Поздравляю тебя, Шарик. Ты балбес...

Кого это я когда-либо дезинформировал насчет "ЖЦ"?! Кстати, что такое "ЖЦ"? А игрушку не хочу — там регистрироваться заставляют. Есть где-нибудь линк без регистрации?

VladD2,

> Ты бы хоть читал внимтельно.

Переадресую твое пожелание тебе же. Речь шла не о нулевом поколении, цифирки для которого ты так любезно подсветил, а о первом и втором:

> ПК>Нет, именно миллисекунд. И это не потолок, скорее, характерное время для сбора мусора первого поколения. Сбор объектов поколения 2 может занять значительно дольше.

> ПК>http://support.microsoft.com/default.aspx?scid=/servicedesks/webcasts/en/wc050102/wct050102.asp

> ПК>a collection of Generation 1 is typically between 10 and 30 milliseconds.

> Да и ссылки на доисторические статьи давать не очень разумно. Есть статьи и по новее, где цифорки намного скромнее.

На сколько "намного"? В два, три раза? Это не "намного", т.к. 5-15 или 3-10 это по-прежнему пропуск кадра. И это при сборке первого поколения. Сборка второго поколения, которой без ручной оптимизации работы с памятью в реальной игре не избежишь, будет заметно подольше.

> В любом случае выделение памяти в фрагментированном хипе может занять куда большее время. Но про это почиму-то никто не вспоминает.

И правильно делает, т.к. для уменьшения фрагментации кучи давным-давно есть масса распределителей памяти, замечательно с этим справляющихся.

> Так что оставь сказаки про ЖЦ тем кто никогда с ним не сталкивался лично.

http://blacklight.h1.ru/oppo09.htm

Демагогия с переходом на личности
d. Обвинение оппонента в незнании предмета обсуждения

VladD2,

> Демагогия это твои слова.

В чем именно? Я, например, ссылку дал с объяснением, что именно меня не устраивает в твоем сообщении.

> попробуй скачать и запустить ту игрушку. Слушать эту галематью про "паузу" уже сильно надоело.

Как бы она ни работала, это ничего не скажет относительно верности утверждения

Автор: Павел Кузнецов
Дата: 08.12.04

, к которому ты прицепился, т.к. мы понятия не имеем, не используется ли в игре ручное распределение памяти.

если реализовать все критичные действия по работе с памятью вручную, как, например, это сделано в Quake, то можно эти эффекты свести к минимуму

> И кончай чуть что прикрываться переходом на личности. А то уже тоже не смешо... лбое утверждение о твоей неправоте ты сразу объявляешь переходом на твои личности.

Discussion tries to prove what is right; an argument tries to prove who is right.

К тому же, утверждение "о неправоте" от утверждения "о недостаточности компетенции" отличается вполне заметно. Да и подмену опровержения аргументации оппонента переходом к обсуждению его компетентности не заметить тоже сложно.

Так что если не хочешь, чтобы я регулярно напоминал тебе о рамках корректного ведения дискуссии, удерживайся в них самостоятельно.

VladD2,

> MS> Да не особо. 2 ГГц, 10 микросекунд — это 20000 тактов, не так уж и мало.

> Минимальные требования для дотнета — это PII 450. Так что на 2 ГГц — это будет где-то менее 2.5 милисек. И опять же в худшем случае, плюс раз в квартал.

Т.е. сборка 1-го поколения — 2.5 — 7.5 миллисекунд. Все равно в среднем потеря кадра, т.к. времена сравнимы с временем пересчета состояния + отрисовки. Хотя уже, конечно, заметно лучше. К сожалению, при сборке второго поколения все равно будет заметные пользователю паузы (подергивания).

> ПК. Он уже тут очень долго расказывает сказку о "паузах" взыванных ЖЦ и вообще о невозможности создания игр из-за наличия ЖЦ.

Не о невозможности, а об определенных проблемах разработки. Никто не говорит, что эти проблемы не решаемы. Вопрос только в том, что разработчики предпочитают: решать эти плюс прочие проблемы, скажем, C#, или другие, связанные с использованием других языков. Все дела

Здравствуйте, McSeem2, Вы писали:

MS>Что-то у тебя с логикой не лады.

У меня то с ней все впорядке...

MS> "Две версии одного движка" никак не могут дать столь существенной разницы при условии идентичности алгоритмической части.

А зачем нужно "условие идентичности алгоритмической части"? Все и без того более чем можно сравнивать.

Если бы Шарп и дотнет имели какие-то серьезные недостатки, то они стабильно бы были в поной заднице по всем пунктам. Ну, а то что они иногда вырываются вперед очень сильно говорит как раз о том, что в Шарповской версии применены лучшие алгоритмы или контейнеры.

MS> Следовательно, используемые алгоритмы существенно отличаются, следовательно, сравнение производительности с точки зрения используемых компиляторов — некорректно.

Корректно сравнение двух версий. Версия написаная на Шарпе явно в основном лучше. Что несколько странно для портированного продукта.

Ну, а я указываю именно на то, что этот факт четко демонстрирует, что на Шарпе не просто возможно писать 3D игры, но и возможно писать игры как минимум конкурирующие с анменеджед-аналогами.

MS> Иными словами, мы должны сравнивать, наколько GC влияет на производительность, а мы сравниваем разные алгоритмы. Так понятней?

Это самотря какова цель сравнения. Ести мы хотим сравнить проиводительность 100%-но аналогичного кода (что в принципе тяжело из-за использования разных парадигм), то конечно такое сравнение некорректно и нужно делать тесты вроде тех что были в Шустриках

Автор(ы): Владислав Чистяков

.

Но если мы хотим сравнить возможность производства конкурентно-способных 3D-игн на дотнете, то это очень подходящий полигон для сравнения. Ну, и 100%-но корректным является сравнение двух продуктов решающих одни и теже задачи, но созданных на базе разных технлогий.

Ты вот лучше задумайся как оказалось так, что вроде как потенциально более медленных код, имеющий единого предка, и написанный вроде как на более медленном средстве и насанный не очень крутыми перцами (если верить мифам о том, что крутые перцы работают только на С/С++) оказался во многих случаях шустрее С++-ного аналога?

Случайность это или закономерность? А может кроме замедления связанного с GC, лишними байтами в структуре объектов и т.п. есть и другие факторы влияющие не возможность создания более быстрого продукта? Может быть среди них есть такие вещи, как простота и чистота дизайна, качество и количество базовых библиотек, модульность, простота отладки и скорость компиляции, ну, и многое другое? И может быть по этим параметрам С++ мягко говоря недотягивает?

MS>Да и вообще, поменьше бы агрессивности.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тогда этот замер ничем не поможет в оценке произаодительности.

Зато он поможет в реальной оценке задержек в реальном приложении.

Здравствуйте, McSeem2, Вы писали:

MS>Извини, Влад. Споры из серии "опять за рыбу деньги" мне не интересны.

То что вам нечего сказать по делу видно уже давно.

Здравствуйте, VladD2, Вы писали:

Знаешь, старик, очень долго читал, а как дочитал твой пассаж понял, что отвечать на него буду еще дольше и это было бы абсолютно бессмысленно А так как дискуссия зашла в тупик в очередной раз просто хочу озвучить мысль, что по моему мегасубъективному мнению ты крупно ошибаешся относительно того, что язык играет настолько фундаментальную роль, как ты это преподносишь — не играет рояли на чем напмсан конечный продукт. Ты очень часто делаешь упор на вопрос проектирования и привязки проектирвоания к языку — на мой взгляд, это неправильно — объяснения почему так смотри выше в предыдущем посте.
А ваще время рассудит, что там для чего выгоднее, шарп или плюсы Вот лет через 10 бы эту ветку поднять — вот тогда было бы интересно перетереть...

VD>Здравствуйте, Bigger, Вы писали:

B>>Чем же он убог до безобразия, блин,

VD>Это уже обсуждалось сотню раз. Сделай поиск.

А вот это уже просто смешно. Смешно и ничего более. На чем написана ОС, браузер, компилятор, имейл-клиент и проч. и проч.? Хмм... говорить, что язык, добившийся такой головокружительной высоты является "убогим"...

Здравствуйте, slegkapjan, Вы писали:

S>А вот это уже просто смешно. Смешно и ничего более. На чем написана ОС, браузер, компилятор, имейл-клиент и проч. и проч.?

История скоро изменится (с) Назад в будущее.

S> Хмм... говорить, что язык, добившийся такой головокружительной высоты является "убогим"...

Ага.

D>Может предложить только одно — стоимость проектов бля бизнес приложений СУЩЕСТВЕННО ниже. Поддержка СУЩЕСТВЕННО дешевле.
D>А для бизнеса только этот пункт существенен. А все остальное никого не интересует.
С этим абсолютно согласен.

S>>А что может помешать вирусу модифицировать фреймворк и вызывать любые методы которые ему только вздумаются? Или же эта защита работает только для вриусов, написанных под .NET?
S>Да, только для вирусов, написанных на дотнет. К примеру, мы можем потребовать от кода, загружаемого на общественный сервер, быть написанным на .Net. При этом можно будет писать любой код, но работать будут только безопасные методы. Аналогичной возможности для С++ не существует.
Вполне можно модифицировать операционную систему, добавив такие возможности...

S>> При желании и для C++ можно придумать подобную защиту, и гораздо более действенную.
S>Попробуй. Можешь хотя бы на пальцах объяснить, как ты на С++ реализуешь код, принимающий решение о возможности вызова в зависимости от того, откуда сделан вызов?
См. выше. Просто поддержка будет не со стороны языка, а со стороны ОС -- что гораздо правильнее.

S>>А потому, что нельзя определить что-то через него же самого. Нельзя написать фреймворк для C# на C#!
S>Ну и что. Фреймворк для C# — это, собственно, та небольшая часть кода, написанная на, допустим, ассемблере. В чем разница?
Небольшой такой участочек, написанные на ассемблере, мааааленький, строк 200. Это самое гениальное твое высказывание после "ты гонишь". Мы всем отделом смеялись до коликов.

S>>>Ты написал, что любую C# программу ты сможешь заменить эквивалентной программой на С++, которая будет более быстрой. Тебе все еще неочевидно, что ты гонишь?
S>>Скажи пожалуйста, а почему такое не может быть возможным?
S>Нет уж, это ты делаешь некоторое голословное утверждение. Будь любезен принести доказательство в студию. В науке, знаешь ли, действует презумпция недоказанности. Так что пока ты не приведешь метод, по которому ты выполнишь более быструю реализацию, аналогичную любой .Net программе, я буду считать твои заявления плодом религиозного экстаза.
Неужели ты этого сам не понимаешь? Как ты думаешь, можно ли, например, переписать zlib целиком на .NET, так чтобы zlib не отстовал от реализации на Си?

S>>Только воздержись пожалуйства от доказательств, содержащих такие гениальные идеи как неоптимизируемый код, самоускоряющиеся программы и проч. и проч.
Молодец, воздержался

S>>>>А скажи пожалуйста, ты думаешь что можно в принципе написать фреймворк C# для любой платформы?
S>>>Естественно! А что нам может помешать? Скажи пожалуйста, какие особенности C# могут помешать написать фреймворк на любой платформе?
S>>Т.е. ты утверждаещь, что, положим, можно написать фреймворк для PIC? Или для палмы с 300 килобайтами хипа?
S>Именно это я и утверждаю. А почему бы, собственно, нет? JVM прекрасно работает на пальме. Чем .Net хуже?
S>>Знаешь, есть такая функция GetProcAddress() Вполне можно сделать нечто подобное и для классов.
S>Знаю. Ты на приложение посмотрел? А теперь попробуй все же реализовать аналог на С++. Я даже не буду требовать, чтобы это работало для любых классов без доп. условий (как это работает в .Net). Иначе у тебя вообще ничего не получится. Попробуй-попробуй. И ты поймешь, что это не намного более удобно, чем реализация ООП с виртуальным множественным наследованием на макроассемблере.
Опять же, все что ты сказал сугубо субъективно. Вполне можно реализовать очень даже удобную, работоспособную систему.

S>1. Для любой программы на C# существует эквивалентная программа на С++ с более высоким быстродействием.
Пусть нам дана некоторая программа на C#, реализующая некий алгоритм. Т.к. с точки зрения управляющих конструкций C# является подмножеством C++, то мы можем написать программу на C++ действующую схожим образом. Уже на этом уровне, C++ должен быть как минимум не медленнее C#, т.к. C++ язык более низкого уровня. Однако у C# есть замечательная штука -- GC которая будет запускаться раз в N тактов и притормаживать всю систему.

На остальное отвечу потом, сейчас времени нет.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, slegkapjan, Вы писали:
S>>Что конкретно вызывает твои сомнения?
S>Отсутствие внятной аргументации существования такого метода. Еще раз: Это не я сделал голословное утверждение. Это ты сделал утверждение о том, что можно реализовать намного более действенную защиту, чем CAS, на С++. Я пока не вижу, как это можно сделать, не воспроизводя весь .Net Framework.
А скажи пожалуйста, на каком языка написан .netfw? На C++? Соответственно такое же средство можно реализовать и для C++ на самом C++.

Я все еще в цейтноте, поэтому постораюсь вечером из дома написать что-то более внятное.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это почему?

потому что идеальных программистов не бывает. Кто-нибудь обязательно накосячит при очередных изменениях, повредит чужую память, и весь сервер с треском рухнет — вместе со всеми текущими сенасами работы. Пользователи будут очень довольны. Что еще хуже, на поиск и отладку этого бага понадобится куча времени.
Единственный способ этого избежать — запускать каждый сеанс в отдельном процессе. Что создает такие накладные расходы, по сравнению с которыми накладные расходы той же самой Явы или C# покажутся детскими игрушками.
Хотя это уже 10 раз везде обсуждалось и обсасывалось...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>"generics не в счет" не из-за того, что они "еще недоступны для большинства", а из-за их ограниченности

Автор: Павел Кузнецов
Дата: 20.11.04

. Считать это положительным или отрицательным моментом — дело вкуса. Однако для тех, кому нужна функциональность "полных" шаблонов C++, generics адекватной заменой не являются.

Я в курсе.. увы, C++ шаблоны — это инструмент "не для всех". Большинство кодеров при виде заворота в стиле Александреску приходит в тихий ужас и норовит забиться куда-нибудь в уголок. Невразумительные сообщения об ошибках в пару кб текста длиной — это тоже далеко не плюс. Я уж не говорю про проблемы с компиляторами и поддержкой стандарта языка.
надеюсь, R# эту проблему в конце концов решит :-D

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

Можно рассматривать это и как плюс. Большое количество скрытой активности в деструкторах часто очень осложняет жизнь. Кстати говоря, выброс исключения из Dispose не может обрушить прогу — в отличие от C++

>> "свободные" функции
ПК>Этого вообще нет.

Никто не мешает использовать вместо них статические функции-члены.

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

Если так уж сильно приспичит, то можно написать наиболее критичную часть проги на MSIL или MC++

Здравствуйте, Дарней, Вы писали:
Д>Параллели между Dispose() и деструкторами С++ очевидны, но это все-таки не одна и та же вещь.
Правильно. Ребята, Dispose — это вообще сахар.
Нужно понимать, что никакого Dispose нет. Есть только try, catch, и finally.
Диспозы вызываются как finally-блок, и никакой неопределенности там нет. Неважно, брошено исключение в рамках Dispose или просто вот так:

try
{
  throw new Exception("1");
} finally
{
  throw new Exception("2");
}

Д>Единственная неопределенность в данном случае — это вопрос о том, какое из исключений будет обрабатываться далее — то, которое изначально привело к раскрутке стека, или одно из тех, которые возникли во время процесса раскрутки. Судя по результатам эксперимента — обрабатываться будет то, которое было выброшено последним.
Д>Это действительно не очень хорошо, т.к. информация о предыдущих исключениях теряется.
Это абсолютно нормально. Вызов Dispose — это часть пользовательского кода! Хочется иметь информацию об исходных исключениях — нет проблем:

using{IDisposable a)
{
  try
    {
    } catch (Exception e)
    {
       // no problem!
    }
}

Д> Однако, неопределенного поведения здесь все-таки нет.
И быть не может. Взаимодействие исключений и пользовательского кода в .Net намного проще, чем в плюсах, и именно из за недетерминистической финализации.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vdimas, Вы писали:

V>>панимашь, писать алгоритмы — это одно, а при разработке сайтов 90% работы — это проставление визуальных св-в у элементов. тут нужна среда, которая не требует компиляции. видел как сайт-девелопер работает? подкрутит что-то — тут же просмотрит страницу в соседнем окне, и т.д.

AVK>А как же JSP и ASP.NET? Там ведь компиляция.

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

да и опять же, я уже приводил аргумент насчет их прожорливости и того, что эти технологии стали принципиально возможны относительно недавно.

------
с удовольствием отдаю веб-интерфейс подобным технологиям,
действительно удобно.

осталось дождаться, когда на клиентской стороне в качестве языка скрипта к DHTML получит распространение C#, ибо писать страницу на ASP.Net/C# и делать вставки кода на JavaScript... в общем, ощущение корявости подхода не покидает.

Здравствуйте, bt, Вы писали:

bt>А вот это уже действительно интересно.
bt>Если можно, вкратце расскажи: как?

http://gzip.rsdn.ru/article/dotnet/inside_remoting1.xml

Автор(ы): Игорь Ткачев
Дата: 11.07.2003
Первая часть статьи, рассказывающая о новой технологии межпроцессной коммуникации — Remoting. Это "родная" для .NET Framework технология, использующая все преимущества платформы. В статье разбираются такие тонкие моменты, как работа с контекстом и перехват создания объектов и вызова методов.

Здравствуйте, VladD2, Вы писали:

VD>Ага. Потому-что даже дохлые скрипты вроде ASP и PHP и те смогли у С++ тут рынок отнять. А ведь первые динамические сайты писались как раз на С/С++. CGI помнишь?

Кроме того, CGI изначально считался относительно медленным, ибо запуск дополнительного процесса. В качестве альтернативы фильтры IIS знаешь? С другой стороны, причём тут "отъятие рынка"? ASP и PHP скорее у HTML-кодеров рынок отнимают.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кроме того, CGI изначально считался относительно медленным, ибо запуск дополнительного процесса.

Про FastCGI никогда не слышал?

Здравствуйте, Геннадий Васильев, Вы писали:

V>>>Если через сколько-то лет станет приемлимой время перекомпиляции подобной системы на С++, то эта причина в языке исчезнет.
AVK>>Вот когда станет, тогда и поговорим. А пока что этого нет.

ГВ> Да нет, по сути дела, никто не мешает и сейчас сделать некий аналог C++ server pages, и проблема в другом — не все хостеры будут рады такой технологии. А проблему со временем отклика можно урегулировать.

Время отклика теоретически должно быть минимально возможным
(речь о уже скомпилированной проге)

Здравствуйте, Павел Кузнецов, Вы писали:


ПК>Я, наверное, недостаточно четко расставил акценты. Самой важной является выделенная часть. Именно это я и имел в виду ранее, говоря о "стоимости разработки с ручным управлением памятью на системе, для этого не предназначенной". В этом смысле, имхо, самым хорошим решением было бы сочетание плюсов от обоих миров: GC + средства для "ручного" управления памятью в виде детерминированных деструкторов и т.п. На первый взгляд в этом отношении C++/CLI кажется вполне удачным вариантом.
Полностью согласен.

Здравствуйте, McSeem2, Вы писали:


MS>Что-то тут не так с Worst FPS. Я готов допустить, что при некоторых условиях C# работает даже быстрее. Но чтобы он работал быстрее в 400 раз — не верю, ибо это противоречит законам природы и нарушает причинно-следственные связи .

Думаю, просто пофиксили глюки.

MS> Следовательно, это не просто "порт", это существенная алгоритмическая переработка, позволившая достичь подобных результатов.

Естественно. Они над этим и работают.

MS> Возможны так же разные исходные условия (разные видеоадапторы), так же не исключен вариант банальной алгоритмической ошибки (O(N^2) вместо O(N log N)) в исходном движке, исправленной в версии C#. В любом случае, данные тесты являются методологически некорректными.

Какая разница? Тут речь идет о невозможности применения Шарпа в 3D играх. Этот движок хорошо доказывает, что эти слова бред. И что намного больше зависит от качества алгоритмов чем от накладных затрат дотнета. Так что эти тесты как нельзя лучше показывают несостоятельность позиции ПК и его сторонников. А что до "методологически некорректными", они сравнивают две версии одного движка. Естественно на одинаковом железе и при одинаковых условиях (обратное твои домыслы), и делают они это совершенно корректно. То что их алгоритмы лучше не умаляет качества движка.

MS>Так что, внимательней надо быть с выбором сравнительных тестов.

Внимательнее надо быть с чтением тем. Смысл нужно улавливать.

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, VladD2, Вы писали:


VD>>Тут речь идет о невозможности применения Шарпа в 3D играх.
V>Хм, а разве кто-то это утверждал?

Утверждал. Я незнаю, что ты под этим имеш ввиду, но тут ПК вот утверждает, что это делать нельзя, а то что это не только возможно но и удобно утверждает как минимум та игра которая прекрасно наботает будучи написанная на этом самом нжте.

V>P.S.: А ты знаешь, что объем рынка игр для PC уже сейчас составляет около семи процентов и с каждым годом он неумолимо падает?

7% чего?

V> Ну и о какой конкуренции шарпа с плюсами в компьютерных играх после этого вообще можно говорить? Ну займет он в лучшем случае один процент (хотя и в это слабо верится), а 99% достанется С++'у!!!

Ты бы привел хоать какие-то ссылки подтверждающие свои слова. Я вот припоминаю информацию из Игромании... там вроде бы говорилось, что рынок PC-игр постоянно растет. И что миллионы стали срывать даже игры второго эшелона.

К тому, же почти все игры выходящие на ХБоксе выходят и на PC. Так что закат этому рынку не грозит.

Ну, и самое главно — это чистеший офтоп. Размеры рынка неимеют никакого отношения к возможности или невозможности создания игр на том же C#.

VladD2,

> ПК> Вот еще достаточно интересное мнение по поводу некоторых трудностей при использовании языков со сборкой мусора для разработки игр.

> Ага. Мнений море. Вот только чущь полная. Игры то работают.

С интенсивной 3D графикой на .Net? Какие? Quake не считается, т.к. он написан очень своеобразно: ему GC вообще почти параллельна. Но писать так все игры никто не будет, ибо очень дорого:

So, it seems to me the only way to get good game performance from C# will be to eliminate ALL allocations from within the frame loop itself. Now, if you imagine the sort of code you're going to have to write to do that... it't starts making new and delete look pretty simple and cozy. You'll end up with something that looks like the quake source: fixed size tables all preallocated, arbitrary limits and tuning parameters everywhere. Bleh.

> Сборка мусора в среднем занимает около 10 милесекунд с интервалом несколько секунд. А то и реже/быстрее.

Это-то и мешает:

Look at it this way. In a game, you ideally are going to generate frames as fast as the monitor traces, ie 60hz or more. That means you've got a deadline ticking off every 16ms. MS's own docks say a generation 0 collection is roughly the same cost as a page fault (ouch!), and that a generation 1 collection can take 10ms to 30ms (OUCH!). So, basicly any collection is going to result in a dropped frame. A generation 2 collection is likely going to cause a "lockup" from the perspective of the player.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vdimas, Вы писали:

V>>мешало еще на тот момент то, что в юнихах не было единой модели threads. тогда как раз в линухе появились динамически подгружаемые модули, можно было бы развить до очень эффективной системы...

AVK>Ну так в виндах изначально были и потоки, и сервисы, и быстрый IPC для коммуникации. Однако ж и там оно не пошло.

помню статистику платформ для www где-то за 95-96 года,
там было примерно 97% всех серваков на основе различных юнихов (в т.ч. и от Sun)

-------
за точность цифр не ручаюсь, но порядок именно тот

Здравствуйте, AndrewVK, Вы писали:

V>> компонентная модель, позволяющая делать перекомпиляцию каждого отдельной странички независимо от других ...

AVK>Для этого компонентная модель не нужна, достаточно умение делать dll.

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

V>>осталось дождаться, когда на клиентской стороне в качестве языка скрипта к DHTML получит распространение C#, ибо писать страницу на ASP.Net/C# и делать вставки кода на JavaScript... в общем, ощущение корявости подхода не покидает.

AVK>Дык XAML.

это в ASP.Net 2.0 уже поддерживается?

Здравствуйте, AndrewVK, Вы писали:

ГВ>> Да нет, по сути дела, никто не мешает и сейчас сделать некий аналог C++ server pages, и проблема в другом — не все хостеры будут рады такой технологии.
AVK>Ну то есть кто то все таки мешает?

Да нет, никто не мешает. Есть он уже давно. Если уж кому-то кто-то (что-то) и мешает, так это мне моя собственная лень написать движок, аналогичный или превосходящий MicroNova. Технических проблем особых нет.

Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Ты ради хохмы создай страничку того же ASP.Net на МС++. Увидишь, что скорости компиляции за глаза хватает. Но МС++ все равно никто для этих целей не использует. И это потому, что толку от МС++ нет, а гемороя с ним больше. Т.е. потому, что в этой области он уже полностью пошел на свалку.

ГВ>Вот не надо гнать, ладно?

Что за выражения? Фу.

ГВ>Ходи сюда и смотри. Крайний апдейт — 18 ноября этого года.

Рад за них. Я вообще всегда радуюсь маньякам и мазохистам. Вот только то, что на С++ сайты в основном не пишут говорит о том, что мазохистов и маньяков все же не много.

ГВ>И вообще, да поможет тебе Google.

Спасибо, но я как-нибудь без этого.

Дарней,

> ПК> С# не включает множества вещей, которые вполне останутся: шаблоны, позволяющие контролировать часть семантических ограничений во время компиляции, (generics не в счет), размещение объектов в стеке + деструкторы, что позволяет автоматизировать освобождение ресурсов, "свободные" функции и т.п. Если бы язык, действительно, являющийся "улучшенным C++", освобожденным от совмстимости от C, уже был бы создан, обсуждать было бы нечего. Java и C# таковыми не являются и близко. Это легко увидеть при сравнении наиболее типичных подходов в каждом из этих языков.

> В 99,9% случаев их хватает. А для оставшегося есть unsafe.

Что-то я не очень понимаю, как unsafe поможет в достижении перечисленных выше моментов...

> Я конечно не спорю, что C++ дает больше возможностей. И как программист я с этим совершенно согласен, и даже очень люблю C++ Но вот как человек, который разгребает чужой код и пытается проконтролировать правильность кодирования — люто его ненавижу

По этому поводу мне нравится работать с программистами, чей код "разгребать" не приходится

> Именно поэтому и придумали C# с Явой — чтобы даже самая законченная обезьяна с гранатой не смогла слишком много набедокурить

Ну, это не ко мне, я с такими предпочитаю не работать

> Кажется мне, что мы очень сильно отвлеклись от основной темы

Здравствуйте, Павел Кузнецов, Вы писали:

Неплохо было бы аргументировать этот набор ничем не обоснованных заявлений.

Здравствуйте, Павел Кузнецов, Вы писали:

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

Дарней,

> Я не сомневаюсь, что в случае C++ выброс исключения во время раскрутки стека приводит к неопределенному поведению.

В данном случае, как уже говорил alexeiz, поведение вполне определено. А именно, будет вызвана функция std::terminate().

> Как показал тест — сначала завершаются вызовы Dispose для всех объектов текущего блока, и только затем продолжается раскрутка стека. Происходит это независимо от того, было ли выброшено исключение одним из вызванных методов, или нет <...> Однако, неопределенного поведения здесь все-таки нет.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это ответ совсем на другой вопрос. Тенденция, однако...

Как спрашиваешь, так и отвечаем, однако.


ПК>

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

ПК>т.е. код должен быть немного модифицирован:
ПК>

ПК>class Test : IDisposable
ПК>{
ПК>     public Test(string name) { _name = name; }

ПК>     string _name;

ПК>     public void Dispose()
ПК>     {
ПК>         Console.WriteLine(_name + ".Dispose()");
ПК>         throw new Exception("Exception in Dispose... (" + _name + ")");

ПК>         // вот здесь должны быть добавлены вызовы других функций, в частности, Dispose других, возможно, содержащихся в Test объектов
ПК>     }
ПК>}
ПК>

Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений. И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код.

Я за все время еще не видел проблем с исключениями в диспозе, а вот с проблемами исключений в конструктерах/деструктерах С++ я видел неоднократно. Уж не знаю, что на это больше влияет, но это факт.

Давай ты опишешь реальный случай, вот его и обсудим.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Именно это я и подразумевал под отсутсвием альтернативы деструкторам C++.

Такова плата за GC.
Можно еще очень долго рассуждать на тему "деструкторы vs Dispose", но на практике Dispose вполне хватает, и никаких особых граблей с ним не возникает.
Если уж искать в языках недостатки, то можно еще много чего вспомнить... например, совершенно уникальный std::auto_ptr с его разрушающим копированием (честное слово — ума не приложу, как вообще комитет мог пропустить такие грабли)
В любом случае — C# меня вполне устраивает, и устраивает больше, чем C++

ПК>Там тоже не все так просто: в таком случае информация о неосвобожденных ресурсах будет потеряна. Об аналогичных проблемах в Java была целая статья в журнале Overload, "Handling Exceptions in finally" (Tony Barret-Powell). В on-line, к сожалению, найти не могу...

Исключения при закрытии ресурсов тема всегда очень щекотливая, независимо от языка

Здравствуйте, Павел Кузнецов, Вы писали:

Понятно, что не стоит допускать ситуаций, когда при необработанном исключении генерируется еще одно. Но раз уж такое случается, то надо с этим как-то жить, и нетовский подход представляется мне более цельным, чем С++овый.

Этот код

A a;
throw "exception";

можно представить так без автоматического вызова конструкторов/деструкторов

A a; // только выделение памяти на стеке
a.ctor();
try {
  throw "exception";
} catch(...) {
  a.dtor();
  throw;
}
a.dtor();

разница только в одном — если деструктор A бросает исключение, то в первом примере получим terminate(), а во втором дальше полетит исключение, выброшенное деструктором.

В этом отличии и заключается нелогичность. Было бы логичнее предъявлять к деструкторам не более жесткие требования, чем к любым функциям, которые могут быть вызваны из catch.
Из catch может быть выброшено как "неожиданное" исключение (например пытаемся выделить память в обработчике и получаем bad_alloc), так и "ожидаемое" (специально выбрасываем новое исключение). Оба эти варианта справедливы и для деструкторов, а значит исключения из деструкторов (при уже активном исключении) должны приводить к тому же — замене старого исключения на новое, а не к terminate().

Самое обидное, что в реализации net-подхода нет никакой net-специфики, на плюсах все это замечательно бы заработало. Имхо, здесь комитетчики приняли неверное решение и не стоит их оправдывать.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Соответственно, в основном все будет хорошо, но периодически, при запуске уборки поколения 1, кадры будут выпадать, а иногда, при запуске уборки поколения 2, будут паузы, заметные пользвователю. Периодичность этих явлений будет сильно зависить от сценариев работы с памятью. И, в принципе, если реализовать все критичные действия по работе с памятью вручную, как, например, это сделано в Quake, то можно эти эффекты свести к минимуму. Вопрос только в стоимости разработки с ручным управлением памятью на системе, для этого не предназначенной.
Выход в создании своего менеджера памяти с использованием валуе типов (массивов байт). Все зависит от задачи и нормально решаемо.

Serginio1,

>>> ПК> если реализовать все критичные действия по работе с памятью вручную, как, например, это сделано в Quake, то можно эти эффекты свести к минимуму. Вопрос только в стоимости разработки с ручным управлением памятью на системе, для этого не предназначенной.

>>> Выход в создании своего менеджера памяти с использованием валуе типов (массивов байт). Все зависит от задачи и нормально решаемо.

> ПК>Гм... В чем здесь противоречие с выделенным?

> В Том, что в Net вполне для этого пригодна правда с ограничениями на ссылочные типы.

А как будет происходить создание/удаление объектов? Через MyAllocator.new()/MyAllocator.delete()? IMHO, без детерминированных деструкторов и возможности перегрузки operator new "ручная" работа с памятью значительно осложняется...

Здравствуйте, AndrewVK, Вы писали:

AVK>Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.

Ну вот! Это уже вполне разумные величины. Всего-то надо было померить. И никаких Urban Legends про 10 ms.

Здравствуйте, AndrewVK, Вы писали:

AVK>Фреймворк 1.1, янус в стабильном состоянии, AthlonXP 2.1ГГц. Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.

А как меряешь?

Здравствуйте, VladD2, Вы писали:


VD>Ну, проблемы неграмотного кода никто устронять не собирался. Диспоз вообще по идее не должнен генерировать исключений. И уж если ты работаешь с ресурсами в диспозе, то ставь using или try/catch|finally защищающие код.
Гы, а что мешает делать то же самое в С++?

Здравствуйте, VladD2, Вы писали:

VD>Утверждал. Я незнаю, что ты под этим имеш ввиду, но тут ПК вот утверждает, что это делать нельзя,
Честно говоря, не замечал за ним таких утверждений... Он вроде бы говорил только о применимости конкретно ГЦ, а не платформы вцелом.
И вообще, тот факт, что есть игра на С# сам по себе еще ни о чем не говорит. Потому, что:
1) стратегии — это такой жанр игр, в которых не требуется постоянный высокий фпс. Он может падать хоть до 10, и при этом пользователь не заметит особого дискомфорта. Более показательны в этом смысле были бы, например, шутер, или автосимулятор.
2) мы не знаем, как она работает, а именно — исползуется ли активно там ГЦ во время игрового процесса. Может там "operator new" вызывается только во время загрузки?

V>>P.S.: А ты знаешь, что объем рынка игр для PC уже сейчас составляет около семи процентов и с каждым годом он неумолимо падает?
VD>7% чего?
От общего объема рынка компьютерных игр. Ну про 7 процентов я, наверное, загнул , но процентов 10 есть...

VD>Ты бы привел хоать какие-то ссылки подтверждающие свои слова.
А вот со ссылками трабл. Дело в том, что подобная информация стоит много денег . Но кое-что все-таки нашлось:
1)Вот эта картинка: http://www.jiad.org/vol4/no1/chou/chou_files/table1.gif
из статьи http://www.jiad.org/vol4/no1/chou/#AUnified

Ну и общая информация:
2) http://www.gamespot.com/all/news/news_6085583.html
3) http://www.release.ru/soft/newslog/2003/12/17/000820.html?m=comments

VD>Я вот припоминаю информацию из Игромании... там вроде бы говорилось, что рынок PC-игр постоянно растет. И что миллионы стали срывать даже игры второго эшелона.
Ты, наверное, путаешь рынок PC-игр, с рынком игр вообще, который, действительно сильно растет, и обогнал уже, кстати, рынок киноиндустрии!!!

VD>К тому, же почти все игры выходящие на ХБоксе выходят и на PC. Так что закат этому рынку не грозит.
Правильно, но замечу, что, даже, на ХБоксе игры пишутся совсем не на шарпе

VD>Размеры рынка неимеют никакого отношения к возможности или невозможности создания игр на том же C#.
Влад, на С# МОЖНО делать игры, и на VB их тоже делать можно, и, даже, на JScript. Но разговор не об этом...

Здравствуйте, AndrewVK, Вы писали:

ГВ>>А сколько штук объектов обрабатывается в этом цикле?
AVK> Я ж говорю — реальное работающее приложение в стабильном состоянии.

Тогда этот замер ничем не поможет в оценке произаодительности.

McSeem2,

> AVK> Сборка нулевого поколения 100-130 микросекунд. Сборка в самом тяжелом состоянии — 240 микросекунд.

> Ну вот! Это уже вполне разумные величины. Всего-то надо было померить. И никаких Urban Legends про 10 ms.

Это время сборки нулевого поколения. О 10 миллисекундах речь шла для первого.

Извини, Влад. Споры из серии "опять за рыбу деньги" мне не интересны.

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

> VD>Пока. Как видишь первые ласточки уже есть.

> Какие? В мире еще не было создано ни одной коммерчески-успешной игры, ориентированной на .NET. Или я что-то пропустил?

Есть даже не на .Net, а на Java. Ил-штурмовик. Правда, куски там на C++, плюс не могу сказать, что игра требует мало ресурсов по сравнению с аналогами... Коммерчески успешной ее, по-моему, более чем можно назвать. Полагаю, какая-то часть разработчиков со временем может использовать C# и для более-менее серьезных игр для PC. Но вот утверждать о поголовном переходе на C# в разработке игр в более-менее обозримом будущем, имхо, точно не приходится.

VladD2,

> V> Это цифры только по восточной Азии (Япония, Корея и пр.)

> Тоже не верю, так как я видил как минимум одну японскую игрушку с более чем двух миллионным тиражом (Хало что ли...). Даже при цене в 2 бакса она уже перекрывает эту цифру.

По-моему, ты путаешь объем продаж одной фирмы в одном регионе с деньгами, вырученными другой фирмой из того же региона, но в результате продаж по всему миру.

> V>Что-то я не улавливаю связи между C#2 и приставками

> Ты много чего не улавливашь.

Фи

> Думаю среди сильных мира сего дело будет развиваться так. Сначала дотнет появится в виде скриптовых движков и дополнительных средств. А со временем вытеснит нэтив код. Случится это по моим прикидкам году эдак к 2010-2015.

В том числе на приставках, где пирог намного лакомее, чем на PC, и где не ю?

Здравствуйте, Shady, Вы писали:

S>Помню слышал те же слова от явовщиков...

А я вот не помню.

S>Ну и как, Java заменила С++?

В создании ПО для бизнеса — полностью.

Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Здесь обсуждался вопрос неприемлемости использования Шарпа в 3D-играх. По этому поводу какие-нибудь аргументы есть? Или признаем все попытки признать это мнение обычной инсинуацией?
ГВ>Так и признаем.

Ну, раз аргументов нет, то и ладно.

Здравствуйте, Glоbus, Вы писали:

G>Истерика какая-то.

У кого?

G> Сам же сказал, что что в деструкторах, что в диспозе исключения кидаться не должны. А насчет дизигна языка — а можно конкрено описать, как дизайн языка мешает мне как разраюотчику писать try/catch в деструкторе и не выпускать оттуда исключения?

Ничего не мешат. Как и обходить все остальные заботливо уложенные грабли.

G>Мы их видим не потому, что они на плюсах. Мыих видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.

Правильно. Так и есть. Все беды из-за того, что руки из задницы растут. Но это же не мы?! Правда?! А те кто считает иначе они невменяемые уроды. Надо закрывать тему и идти учить ассэблер и машинные коды.

G>Все обертки давно наклеины

Расскажи это тем кто матерится на лики памяти и вылеты программ. Или... ах, да. Эти программы же пишутся криворукими уродами, а не нами.

G> Ваще долго тут читал ваши споры, много интересных мыслейЮ, но блин не смог сдержаться Тебя послушать, так до появляения .нет писалово программ было сущим адом — и обертки приклей, и лики лови годами, и надежности никакой, и сплошной AV. жуть... как же жыли то раньше...

Писать хорошие программы и после появления дотнета, и еще очень долго-долго после его смерти будет сущим адом. Мне искренне жаль тех кто этого не осознает. Я могу придумать интересную программу в считанные минуты (ну, максимум дни), а на ее реализацию мне нужны годы. И не просто мне. Годы нужны огромным коолективам. При этом очень часто получается так, что по прошествии многих лет от того плана, не побоюсь этого слова, от той изначальной светлой мечты, остается бледная тень. В итоге мы имеем глючный ворд и никуда не годных конкурентов. Мы имеем 10 лет назад марально устаревшие РСУБД вместо ООБД и ХМЛБД. Имеем игры интеллект ботов в которых ниже интеллекта таракана на кухне. В обещм, имеем полную задницу.

Поэтому даже малейший шаг на встречу облечению этого сущего ада должно приветствоваться как приветствуются глоток воздука после трехминутной задержки дыхания.

G>Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась

Видимо те кто ввели ее в свои языки небыли знакомы с твоей передавой практикой.

G>Да не должен он ничего избегать — все мощные возможности в его распоряжении. Покажи мне пожалуйста пример того, как программисту на с++ приходится отказываться от какой-нить мощной возможности, чтоб не наступить на грабли?

Так и вижу себе архитектора системы планирующего места размещения грабель и благодарного программиста обнаруживающего их своим лбом.

Если серьезно, то ты действительно думашь, что чтобы наступить на грабли, нужно их искать?

G>Насчет времени готов спорить...

Спорь.

G> Все очень зависит от задачи. Действительно, есть класс задач, в которых шарп выиграет по скорости разработки. Это задачи, которые не обладают сколь-нибудь значимой алгоритмической сложностью, а являются просто компоновкой тех или иных фич, типа там файлик открыли, прочитали, в мемо в окошке содержимое вывели, закрыли.

Есть мнение, что решение любых задачь программирования — это процесс компоновки тех или иных паттернов и алгоритмов. И чем проще их компоновать, тем проще решать задачи.

G> Всякий там бухучет, который некритичен по времени исполнения, и который есть просто нагромождение кучи возможностей по выгребалову данных из юазы и их отображению, то есть где по сути все сводится к функциональностям типа add/delete/update/print report.

Ну, да. Бесспорно! Задачи бухучета — это тупой последовательный вызов методов add/delete/update/print. Мы то с тобой как архитекторы это знаем. Не правда ли?

G> Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени,

Скажи, так почему все таки бухгалтерские системы далеть на Шарпе проще? Ну, должно же быть этому логическое объяснение? Ну, не могия же это? Или магия?

И почему эта магия, по-твоему, не срабатывает на других задачах?

Да, и за одно ответь:
1. Почему авиасимулятор Ил2 использует Яву, а не написан целиком на С++? Он что бухгалтерию считает?

2. Почему я даже не мог подумать о создании собственного парсера на С++, а на Шарпе взялся и успешно его делаю?

3. Почему МС предпочел дотнет для реализации большей части АПИ Авалона? Ведь это же графика нового поколения. Что же они совсем дебилы выбрать ничего не дающие технологии? А ведь им еще и людей переучивать пришлось. Ведь у них раньше были одни С++-ники.

Не кажется все это странным?

G> что выигрышь в собственно кодировании будет весьма условный.

Понимаш ли. Выгрыш в скорости реализации проектов создаваемых на базе дотнета определяется совершенно прагматическими соображениями. И выбор Шарпа в качестве основного языка тоже.

Все очень просто. Дотнет позволяет сократить объем ошибок, а это значит меньше времени на отладку и экономия денег. Шарп позволяет не заморачиваться на поддржку разных паттернов, и больше сосредоточиться на процессе проектирования и идее/фичах программы. Вот такие банальные предпосылки. Но самое смешно, они работают. Чтобы убедиться в этом достаточно попробовать.

G> Тут уже не в языке дело по сути, потому что что в плюсах, что в шарпе — везде есть свои нюансы — тамследишь за памятью, там завызовами диспозов — и все зависит от задачи.

Бесспорно нюансы есть везде. Вот только объем этих нюаносв и их уровень совершенно разный. Это как при сравненнии ассемблера и С. Вроде возможностей у асма даже больше. И нюансы есть у обоих. Но вот объем и характер нюансов совершенно разный.

G> Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте.

Используют. Что с того? МС даже С во всю использует. Ворд говорят в основном на С написан. (Видимо от того и глючит так безбожно .) Но тем неменее, в МС понимают, что деньги нужно экономить и уже переводит гору разработок на тот же Шарп. Сан тоже многое делает на Яве. Ну, да ява к сожалению не очень то притендует на универсальность.

G> почему так?

А ты помнишь сколько писали приложений на С++ в 1987 году? А ведь С++-у было как раз 2 года от роду. Как раз как сейчас дотнету. МС начал переходить с С на С++ только в 90-ых. С момента появления С++, к тому моменту, прошло почти 10 лет.

G> Наверное потому что плюсы их устраивают. То есть (как мне лично кажется) не имеет смысла переходить на новую технологию с уже обкатанной, если производственный процесс укладывается в установленные рамки.

Ну, судя по Авалону и Индиге все же стоит.

G> А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.

Слава богу у менеджеров из МС хватило разума, чтобы понять, что успех продвижение новых технологий на 90% зависит от маркетинга. Ну, не умеют люди с благодарностью принимать плоды прогресса. Не отказыватья же от них по этому поводу? Мы так бы и сидели в командной строке запуская бач-файлы если бы не маркетологи из Эпла.

VD>>Остается только один вопрос... Нафига козе баян?

G>Глубоко философский вопрос...

Выходит так, раз такая куча народу не понимает стольк простых истин.

Здравствуйте, VladD2, Вы писали:


VD>У кого?

У тебя, старичек

VD>Ничего не мешат. Как и обходить все остальные заботливо уложенные грабли.

А Dispose спасает нас от этого?

G>>Мы их видим не потому, что они на плюсах. Мы их видим потому что руки из задницы у кого-то растут. Языка ваще играет очень тертью роль во многих случаях.

VD>Правильно. Так и есть. Все беды из-за того, что руки из задницы растут. Но это же не мы?! Правда?! А те кто считает иначе они невменяемые уроды. Надо закрывать тему и идти учить ассэблер и машинные коды.

Не понимаю ваще о ком ты — какие невменяемые уроды, че это за твари такие невиданные? Я говорю о том, что ошибки в программах и всякие андефайнед-поведения от языка не зависят.


VD>Расскажи это тем кто матерится на лики памяти и вылеты программ. Или... ах, да. Эти программы же пишутся криворукими уродами, а не нами.

Не знаю, о чем ты — кто же такие криворукие уроды?
Насчет мемори ликов — ну так будут у тебя не мемори лики, а какая-нить другая лажа, не знаю какая и гадать не буду. Если у человека как программера уровень низкий, он напортачит на любом языке — что с гц что без. Серебрянной пули-то нету, понимаешь.. Язык с примочками не спасает от всех несчастий — он просто пытается заткнуть дыры насколько это возмжно. А насчет учить асм — очччень бы не помешало многим из тех, то себя называет прогарммером — не для того чтобы писать на нем все че ни попадя, а для того, чтобы выработался определенный способ мышелния.


VD>Писать хорошие программы и после появления дотнета, и еще очень долго-долго после его смерти будет сущим адом. Мне искренне жаль тех кто этого не осознает. Я могу придумать интересную программу в считанные минуты (ну, максимум дни), а на ее реализацию мне нужны годы. И не просто мне. Годы нужны огромным коолективам. При этом очень часто получается так, что по прошествии многих лет от того плана, не побоюсь этого слова, от той изначальной светлой мечты, остается бледная тень. В итоге мы имеем глючный ворд и никуда не годных конкурентов. Мы имеем 10 лет назад марально устаревшие РСУБД вместо ООБД и ХМЛБД. Имеем игры интеллект ботов в которых ниже интеллекта таракана на кухне. В обещм, имеем полную задницу.

Ну и какое отношение языки программирования имеют к ообд и интеллекту ботов? Не путай прогресс в науке и прогресс в инструментарии. А язык программирвоания — это не более чем инструмент решения задачи.

VD>Поэтому даже малейший шаг на встречу облечению этого сущего ада должно приветствоваться как приветствуются глоток воздука после трехминутной задержки дыхания.

Я приветствую Писал на шарпе сам, знаю че это такое — да, приятная вещь, то только как я уже сказал для определенного круга задач.

G>>Да не сказать, что прям такая уж необходимая и незаменимая вещь. Мож чегол-то не знаю конечно, но в моей практике ни разу на плюсах не понадобилась

VD>Видимо те кто ввели ее в свои языки небыли знакомы с твоей передавой практикой.

А к чему это тысказал?


VD>Так и вижу себе архитектора системы планирующего места размещения грабель и благодарного программиста обнаруживающего их своим лбом.

Давай ты будешь предметный разговор вести. А то "грабли!грабли!" а сказать ничего толком не хочешь.

VD>Если серьезно, то ты действительно думашь, что чтобы наступить на грабли, нужно их искать?

См. про грабли выше

G>>Насчет времени готов спорить...

VD>Спорь.


VD>Есть мнение, что решение любых задачь программирования — это процесс компоновки тех или иных паттернов и алгоритмов. И чем проще их компоновать, тем проще решать задачи.

Есть много разных мнений...



VD>Ну, да. Бесспорно! Задачи бухучета — это тупой последовательный вызов методов add/delete/update/print. Мы то с тобой как архитекторы это знаем. Не правда ли?

Да, мы калачи тертые... Раскинь-ка мне, почему такие сложные системы бухучета пишутся всеми кому ни лень — любая контора размером около 20 человек, не имеющих даже порой законченого высшего образования, с радостью берется слобать такой прожектец, чтоб на своем сайтиле в портфолио гордо вписать "системы бух. учета".

G>> Да, тут писать быстрее на шарпе, спору нет. Но как мне лично кажется на более/менее серъезной задаче (авиасимуляторы, компиляторы, сложные системы управления оборудованием, математические программы, графика) время проектирования, разработки алгоритмов и тому подобные вещи занимают настолько много времени,

VD>Скажи, так почему все таки бухгалтерские системы далеть на Шарпе проще? Ну, должно же быть этому логическое объяснение? Ну, не могия же это? Или магия?

Читаешь плохо? Я ж сказал — потому что бух. системы по своей сути не несут никакой тяжелой алгоритмичесмкой нагрузки — с точки зрения разработки 80% времени уходит именно на кодирование (которое на шарпе конечно быстрее чем на плюсах, но далеко не намного ) — то есть: нет никакого ресерча, зачастую не присутсвует оптимизация по скорости и данным (память и все такое — оно ведь не ресурс), то есть главное на что обращаем внимание — кодирование. Да, на шарпе оно проще — все-таки синтаксис попроще будет, за ресурсами следить не надо — то есть по времени процентов 10-15 будет выигрышь по сравнению с теми же плюсами. Для прожекта где, 80% — это то самое кодирование — это приличный плюс.

VD>И почему эта магия, по-твоему, не срабатывает на других задачах?

VD>Да, и за одно ответь:
VD>1. Почему авиасимулятор Ил2 использует Яву, а не написан целиком на С++? Он что бухгалтерию считает?

Могу ошибаться, но на жабе писаны некритичные по сокрости его части.
Вопрос встречный: почему борланд ЖБульдер такой тормозный?

VD>2. Почему я даже не мог подумать о создании собственного парсера на С++, а на Шарпе взялся и успешно его делаю?

Это твои маленькие интимные трудности о чем ты там думал Я честно говоря не могу даже представить, что тебя сдерживало от написалова парсера на плюсах — если на такой задче язык играет для тебя настолько важную роль, то уменя есть сомнения относительно твоего проф. урвня — ты уж прости. Такая задача как написалово парсера от языка не зависит — можно хоть на бейсике сделать. Я вот прекрасно делал и делаю парсер на плюсах. Я могу и на шарпе написать без проблем. Могу и на паскакале (если вспомню его).

VD>3. Почему МС предпочел дотнет для реализации большей части АПИ Авалона? Ведь это же графика нового поколения. Что же они совсем дебилы выбрать ничего не дающие технологии? А ведь им еще и людей переучивать пришлось. Ведь у них раньше были одни С++-ники.

Что такое авалон, где применяется, какие системные требования? Если минимум на 3ГГц + 128 м видео — тада смело отвечу — мс предпочел дотнет для писалова апи для авалона шоб лучше продавались новые процы от интела

Насчет ничего не дающих технологий ты это зря... Я ж говорил, что понимаю достоинства .нета, но в то же время я вижу грань их применимости. а ты вот похоже не очень.

VD>Не кажется все это странным?

Нет.

G>> что выигрышь в собственно кодировании будет весьма условный.

VD>Понимаш ли. Выгрыш в скорости реализации проектов создаваемых на базе дотнета определяется совершенно прагматическими соображениями. И выбор Шарпа в качестве основного языка тоже.

Повторюсь в тридцатый раз. Если мы с тобой, мы вдвоем, как два реальных пацана, Влад, (понимаешь, без лишних людей, шоб это было нашей маленькой тайной), выйдем за пределы прожектов, которые делаются в 90% контор на просторах снг, то увидим, что в подавляющем большенстве случаев язык реализации есть третье дело. В наших с тобой странах специфика другая — в основном требуется просто кодинг, где да — шарп дает преимущество в 10%, которого вполне достаточно, чтоюбы контора, регшающая задачи на .нете обошла контору решающую точно такие же задачи на плюсах. Но как имне видется так будет не всегда.

VD>Все очень просто. Дотнет позволяет сократить объем ошибок, а это значит меньше времени на отладку и экономия денег. Шарп позволяет не заморачиваться на поддржку разных паттернов, и больше сосредоточиться на процессе проектирования и идее/фичах программы. Вот такие банальные предпосылки. Но самое смешно, они работают. Чтобы убедиться в этом достаточно попробовать.

Каких ошибок? Синтаксических? Может быть. Но синтаксические ошибки не критичны — они отлавливаются мгновенно на этапе компиляции и не увеличивают время разработки. Логические? Но тут тебе уже язык не поможет. Если дизайн приложения крив, или у программиста квалификация недостаточно высокая, то на каком языке не делай, а его тока могила исправит.
Далее. Инетерсная фраза

Шарп позволяет не заморачиваться на поддржку разных паттернов

О чем это было сказано — какие паттерны? кто на что замарачивается? Ну хоть один пример приведи граблей или там заморочек.

Далее. Насчет сосредоточится на процессе проектирования. Не играет рояли на каком языке ты пишешь. Если ты реально сосредотачиваешся на проектировании, то тебе должно быть очень параллельно, на каком языке будет реализована система. Во многих случаях с этим определяются уже после разработки структуры системы и детального его планирования.



VD>Бесспорно нюансы есть везде. Вот только объем этих нюаносв и их уровень совершенно разный. Это как при сравненнии ассемблера и С. Вроде возможностей у асма даже больше. И нюансы есть у обоих. Но вот объем и характер нюансов совершенно разный.

Как я уже упоминал, это не играет рояли — человек с хорошим уровнем как программер способен писать на любом языке — язык эт овсего лишь инструмент. Например. У знакомого в конторе работал человек-глыба по плюсам. Но его какого-то хрена засадили лобать на жабаскрипте минюшки и всякую подобеную лабуду. Он уже через неделю мог написать на жабаскрипте такой код, который работал и нормально отображался под любые браузеры, со всякими выплывающими фигнями и тп. Все-таки уровень знаешь ли...

G>> Но все таки в защиту моих плюсов могу сказать что пока что, насколько мне известно, такие монстры как МС, EA, Adobe, Sun и т.д. весьма активно пользуют плюсы — можно судить хотя бы по требованиям к вакансиям на их сайте.

VD>Используют. Что с того? МС даже С во всю использует. Ворд говорят в основном на С написан. (Видимо от того и глючит так безбожно .) Но тем неменее, в МС понимают, что деньги нужно экономить и уже переводит гору разработок на тот же Шарп. Сан тоже многое делает на Яве. Ну, да ява к сожалению не очень то притендует на универсальность.

Не с целью поспорить — а откуда инфа, что мс переводит своих разработчиков на шарп?
А то что ява не претендует на универсальность — дык правильно делает. И плюсы не претендуют кстати тоже. И шарпу того же желаю


VD>А ты помнишь сколько писали приложений на С++ в 1987 году? А ведь С++-у было как раз 2 года от роду. Как раз как сейчас дотнету. МС начал переходить с С на С++ только в 90-ых. С момента появления С++, к тому моменту, прошло почти 10 лет.

Ну и что? То есть думаешь что через 10 лет они перейдут на шарп? Сомневаюсь. Хотя бы просто потому что щас конторы намного больше чем щас, а занчит более инертные. Это как минимум. А в реале как я уже сказал, то потому что для таких контор вопросы моды на новое не играет рояль. Играет рояль эффективность. А эффективность зависит в данном случае далеко не от языка. Если бы они писали на коболе и имели такой же успех как щас используя плюсы то вопрос — зачем переводить такие большие конторы на другие, новые, необкатанные рельсы, если учесть что выгоды сомнительны — качественного скачка не будет точно, а убчтки будут однозначно.

VD>Ну, судя по Авалону и Индиге все же стоит.

А что такое авалон и индига?

G>> А то что мы видим сейчас в области .НЕТ — это чистый маркетинг. То есть не продукт подгоняется под рынок, а во многих случаях рынок подгноняется под продукт. Ваще это очень модный подход, и не только в ИТ — всякие там кока-колы и т.п., да практически все крупные компании, так делают. С точки зрения бизнеса конечно очень эффективно.

VD>Слава богу у менеджеров из МС хватило разума, чтобы понять, что успех продвижение новых технологий на 90% зависит от маркетинга. Ну, не умеют люди с благодарностью принимать плоды прогресса. Не отказыватья же от них по этому поводу? Мы так бы и сидели в командной строке запуская бач-файлы если бы не маркетологи из Эпла.

Тут обеими за. Маркетинг это хорошо и я очень мс за эт оуважаю (ваще за многое их уважаю). Но опять же как в случае с кока-колой — во многом рынок был создан искуственно.
..

VD>Выходит так, раз такая куча народу не понимает стольк простых истин.

Каких истин. Ни одной не было. Были рассуждения на тему...

Здравствуйте, slegkapjan, Вы писали:

VD>>История скоро изменится (с) Назад в будущее.
S>Это далеко еще не факт.

Имеющий уши да увидит.

Здравствуйте, slegkapjan, Вы писали:

VD>>История скоро изменится (с) Назад в будущее.
S>Это далеко еще не факт.

Имеющий уши да увидит.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, slegkapjan, Вы писали:
S>>Зачем запрещать что-то? Между C++ и C# есть разница в философии построения языка.
S>А, ну то есть вместо доказательства "на с++ можно все" мы переходим к опровержению необходимости этого "всего". Все же почитай про CAS. Вкратце: это делается для того, чтобы вредоносный код не мог вызвать нехорошую вещь. Например, вирус, который ты выкачал из интернета под видом видеокодека, не сможет полезть управлять сервисами. Потому, что ему не дано такого разрешения. И это несмотря на то, что вирус выполняется под твоими пользовательскими привилегиями. На C# я помечаю опасный метод атрибутом, который говорит "здесь нужен специальный пермишшн". И код, которому не выдан пермишшн, не сможет вызвать этот метод.
А что может помешать вирусу модифицировать фреймворк и вызывать любые методы которые ему только вздумаются? Или же эта защита работает только для вриусов, написанных под .NET? При желании и для C++ можно придумать подобную защиту, и гораздо более действенную.

S>>Для большиства операционок небольшая часть кода написана на ассемблере, остальное на C++. Опять же C# использовать вместо C++ в этой связке невозможно.
S>Почему?
А потому, что нельзя определить что-то через него же самого. Нельзя написать фреймворк для C# на C#!

S>Ты написал, что любую C# программу ты сможешь заменить эквивалентной программой на С++, которая будет более быстрой. Тебе все еще неочевидно, что ты гонишь?
Скажи пожалуйста, а почему такое не может быть возможным?
Только воздержись пожалуйства от доказательств, содержащих такие гениальные идеи как неоптимизируемый код, самоускоряющиеся программы и проч. и проч.

S>>А скажи пожалуйста, ты думаешь что можно в принципе написать фреймворк C# для любой платформы?
S>Естественно! А что нам может помешать? Скажи пожалуйста, какие особенности C# могут помешать написать фреймворк на любой платформе?
Т.е. ты утверждаещь, что, положим, можно написать фреймворк для PIC? Или для палмы с 300 килобайтами хипа?

S>Ну самое простое — есть приложение. К нему динамически подцепляются сборки (библиотеки). По команде пользователя создается инстанс произвольного класса из этой сборки, и вызывается произвольный метод по имени. Впрочем, зачем далеко ходить: давайте взглянем на .Net Explorer

Автор(ы): Андрей Мартынов
Дата: 24.12.2002

. Не мог бы ты воспроизвести его поведение средствами С++? Я подожду — в ближайшие год-два я не планирую уходить в оффлайн.
Знаешь, есть такая функция GetProcAddress() Вполне можно сделать нечто подобное и для классов.

S>>Я просто как раз-то и не понимаю сути вопроса. Ты можешь сказать конкретно что тебя интересует?
S>Вижу, что не понимаешь. Ты просто смотришь на C# через замочную скважину С++. Поэтому ты не видишь в нем почти что нихрена. Впрочем, именно про это была статья Пола Грэма. Это то же самое, как если бы чистый басик девелопер задавался вопросом "а нахрена нужен С++, если в нем нет даже номеров строк?!!"
Обязательно прочитаю.

D>Гуд. Рассуждаем дальше. Например, написание операционных систем — этот класс задач намного уже (читай, этим занимаются намного меньше людей) чем обычные бизнес системы.
D>Это значит, что ниша С++ должна стать и становится узкой за счет отбирание данной огромной области. Т.е. никто не говорит что С++ отстой. Просто в бизнесе ему делать нечего. Вот и все.
И с этим тоже согласен.

S>>>Попробуй. Можешь хотя бы на пальцах объяснить, как ты на С++ реализуешь код, принимающий решение о возможности вызова в зависимости от того, откуда сделан вызов?
S>>См. выше. Просто поддержка будет не со стороны языка, а со стороны ОС -- что гораздо правильнее.
S>Не вижу выше никаких идей про то, как это можно было бы реализовать со стороны ОС. При этом так, чтобы можно было управлять этим из С++, не изменяя языка.
Что конкретно вызывает твои сомнения?

S>Ага, ну что ж, идея ясна. Возможно, это действительно доказательство утверждения номер 1. Хотя я бы не стал утверждать этого категорично — вдруг найдется опровержение этого доказательства .
Ну это я просто так придумал, первое что пришло в голову.
В принципе, большую разницу дает то, что C++ более низкоуровневый язык, плюс всякие надстройки фреймворка тормозят.
Но C# не позиционируется как язык для реализации каких-то алгоримтически сложных задач, так что это вряд ли можно считать большим минусом.

Здравствуйте, VladD2, Вы писали:

VD>С каких пор коллектив стал состоять из объектов, а не субъктов. Я привел список современных языков которые по мнению очень большого количества народа считаются очень стройно спроектированными и я даже сказал бы лидерами отросли. Довольно характерно, дизайнеры этих языков все как один выбрали "порочный" путь. И довольно характерно, что результат значительно превосходит предшественников. Люди создававшие все эти языки сделали свой выбор совершенно осознанно. Опты того же С++ ими учитывался. И к сожалению для С++ во многом опыт С++ был признан негативным.

Странно, но пока что ничего серьезного не было написано не на С++.
Приведи хоть одну серьезную (или коммерчески успешную) систему на дотнете или питоне?

Здравствуйте, vdimas, Вы писали:

V>Странно, но пока что ничего серьезного не было написано не на С++.
V>Приведи хоть одну серьезную (или коммерчески успешную) систему на дотнете или питоне?

Таких море. Просто понятие комерческого успеха сильно растяжимо. Есть и игры, и системы автоматизации, и море сайтав (хотел бы я посмотреть на сайт на С++). И не стоит забывать, что дотнету два года. На той же Яве на сегодня уже половина индустрии учетно-управленческого софта сидит. А вот С++ в этой области вообще не видно.

Что касается конкретных ссылок... я их не коллекционирую. На этом форуме они не раз пробегали. Можешь глянуть.

Ну, и глянь за одно на подпись в моем сообщении.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, vdimas, Вы писали:

V>>Странно, но пока что ничего серьезного не было написано не на С++.
V>>Приведи хоть одну серьезную (или коммерчески успешную) систему на дотнете или питоне?

VD>Таких море. Просто понятие комерческого успеха сильно растяжимо. Есть и игры,
Нет коммерчески успешных игр и не предвидится еще ооочень долго. Цикл разработки современной игрухи ныне 2-3 года, пока мы не слышали анонсов о том, что кто-то из заметных игроков на этом рынке начал писать на дотнете современный 3D-движок.

VD>и системы автоматизации
ИМХО, дотнет тут не у С++ рынок отбирает, а у VB (у них) и у Дельфи и 1С у нас


VD>, и море сайтав (хотел бы я посмотреть на сайт на С++). И не стоит забывать, что дотнету два года. На той же Яве на сегодня уже половина индустрии учетно-управленческого софта сидит. А вот С++ в этой области вообще не видно.
Правильно, сайты это да...
Тут дотнет отнимает рынок у ASP и PHP, опять же, не у С++, ибо на С сайты были, на С++ наверно уже нет (из-за того, что perl поспел одновременно с С++)

VD>Ну, и глянь за одно на подпись в моем сообщении.
Кстати, а что это? И где можно посмотреть?

---------
Да я и сам участвовал в разработке учетной системы на дотнете для штатовских магазинов мобильников, но не могу считать это "серьезным". Axapta — то да, но разве она целиком на дотнете?

Здравствуйте, vdimas, Вы писали:

V>Нет коммерчески успешных игр и не предвидится еще ооочень долго. Цикл разработки современной игрухи ныне 2-3 года, пока мы не слышали анонсов о том, что кто-то из заметных игроков на этом рынке начал писать на дотнете современный 3D-движок.

Видимо проблемы со слухом, так как уже даже есть вполне успешные проекты. Вот поищи в гугле ArenaWarsDemoEnglishAndGerman.exe, например.

Вот скриншотик:


VD>>и системы автоматизации
V>ИМХО, дотнет тут не у С++ рынок отбирает, а у VB (у них) и у Дельфи и 1С у нас

И у С++ в том числе.


V>Правильно, сайты это да...

А что ж так? Такой виликий языки и вдруг сайты не тяент? Не уж-то надежности не хватет?

V>Тут дотнет отнимает рынок у ASP и PHP, опять же, не у С++, ибо на С сайты были, на С++ наверно уже нет (из-за того, что perl поспел одновременно с С++)

Ага. Потому-что даже дохлые скрипты вроде ASP и PHP и те смогли у С++ тут рынок отнять. А ведь первые динамические сайты писались как раз на С/С++. CGI помнишь?

VD>>Ну, и глянь за одно на подпись в моем сообщении.
V>Кстати, а что это? И где можно посмотреть?

http://gzip.rsdn.ru/janus/article/article.xml

V>---------
V>Да я и сам участвовал в разработке учетной системы на дотнете для штатовских магазинов мобильников, но не могу считать это "серьезным". Axapta — то да, но разве она целиком на дотнете?

Погоди немного и код на С++ будешь искать в красной книге.