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

K>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

Не вдаваясь в технические детали: разработка с С# в три раза быстрее идет чем с С++, прикинь сколько баблища можно съэкономить...!!! не знаю как чистый С++, но MFC точно в ауте

Здравствуйте, <Аноним>, Вы писали:

А>нахрен выпускают книги по c++ если в скором времени подавляющее большинство софта на C# и java писаться будет? и мне как новичку забыть о с++ и начать сразу с C#?

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

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

__>а ссылочки можно на 3D движки на шарпе.

Сколько угодно

Axiom

The Axiom Engine Project is a fully object oriented game engine development effort using C# and the Microsoft.NET platform to create an easy to use, flexible, extendable, and powerful engine that allows for rapid development of games for various genres. By using the .Net framework as the target platform, developers can focus more on core functionality and logic, rather than dealing with the complexities of languages like C++. The core of Axiom is a port of the very popular OGRE graphics engine, which was chosen based on its clean object-oriented design, powerful features, and flexibilty.

http://axiomengine.sourceforge.net/

Входит в десятку лучших Open Source движков.

Irrlicht Engine

The Irrlicht Engine is a cross-platform high performance real-time 3D engine written in C++. It is a powerful high-level API for creating complete 3D and 2D applications like games or scientific visualizations. It comes with documentation and integrates all the state-of-the-art features for visual representation like dynamic shadows, particle systems, character animation, indoor and outdoor technology, and collision detection. All this is accessible through a well designed C++ interface, which is easy to use.

http://irrlicht.sourceforge.net/

Входит в десятку лучших Open Source движков.

Ovorp

Ovorp is more of a client server development framework than an engine. Supports only 2D out of the box, but a 3D client could be put on the front of it easily. The game engine is designed to be scalable, from the simplest version of Pong to a fully persistent MMPOG.

http://ovorp.bryanlivingston.com/

Purple#

Purple# is one of the first full blown game engines for .NET concentrating on flexibility, simpleness, performance and quality by using the newest technology.

http://www.punchncrunch.com/

RealmForge

The RealmForge GDK is a cross-platform game development framework and toolkit written in Mono/C# and powered by the Axiom 3D engine. It will allow for the rapid development of cutting-edge software and MMORPGs with advanced graphics, audio, and networking capabilities.

http://xeonxstudios.com/

Revolution3D

http://www.revolution3d.de/postNuke/

TV3D SDK

http://www.truevision3d.com/


Коммерческая стратегия реального времени + экшен, полностью написанная на C#.

http://arenawars.krawall.de/eng/news.html

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

V>>>Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически.
K>>А это почему ?
V>Ну а как ты себе это представляешь? Фреймворк внутри фреймворка?

На любом языке програаммирования (в проть до машинных кодов) пишется JIT и минимальный загрузчик. Далее на любом высокоуровневом языке (например, Яве, очень близкой к Шарпу) пишется компилятор. Далее компилятор переписывается на Шарпе же. Все остальное пишется на Шарпе.

Собственно, почти так и поступили в Моно. Только они писали все сразу на Шарпе, так как была доступна реализация от МС. В Моно процент нэйтив-кода минимален.

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

_U>Ну вы как маленьие дети... C# нужен там где требуется качесво кода и бытстрота разработки. За языками с автоматической сборкой мусора будущее. И в не зависомти будете ли вы топать ногами и кричать что C#, Java отстой они будут двигаться вперед. Ни куму уже не интересно при разработке прикладных задач иметь геморой с указателями и утечками памяти, всем требуется реализация бизнеслогики, а не поиски что же произошло с указателем на указатель .

Мемори лик: Злое, мифическое существо по мнению дтнетчиков обитающие в каждой программе на С++.

(С) WolfHound

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

VD>Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.
VD>Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.

Вы все правильно говорите, и когда речь идет о разработке ПО для Windows, спорить тяжело. НО! Не стоит забывать про многие другие платформы, а так же про множество программ для, например, DSP ориентированных устройств. Пока я еще не видел не одного компилятора C# или Java для DSP.
Один из моих университетских преподавателей рассказал как-то историю, спорил он как-то с американцем каким-то (тоже преподавателем) по поводу обучения студентов, типа с чего надо начинать с низкоуровневых языков и наверх (мнение нашего преподавателя) или сосредоточиться на обучении Java-подобных языков и ООП. Они все таки пришли к общему мнению, решили, что
наш (Россия-чемпион!) преподаватель был прав. Как они пришли к этому? Да, посчитали (как считали не рассказывал) количество кода написанного для ПК (и пусть он весь написан хоть на C#) и количество кода написанного для DSP (тут и сотовые телефоны и умный дом, и сигнализации, и поворачиващееся зеркало, когда по среди ночи какой-нибудь урод сзади дальним светит, и авиация, и т.д.), для множества других микропроцессоров и микроконтроллеров (тут все от промышленных установок до наручных часов).
Резюме: есть множество областей, где не только C# не применяют и скорее всего и не будут применять, но и не знают о нем, это для них пустой звук.

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

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

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

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


VD>То что ты считаешь приемуществом С++ на самом деле является его недостатком. Та же раздельная декларация — это убогость доставщеяся в наследство от С. Необходимость предварительной декларазции вынуждает разделять код на декларазию и реализацию. В шарпе совершенно все равно где и кода встретися некий тип. Это позволяет думать об алгоритме и структурах данных, а не о расположении кода в файлах. Что значитель облегчает работу и упрощает дизайн.
Кстати да. С появлением современных технологий требование от новичка понимания отличий модели памяти compact от модели памяти small выглядит несколько нелепым. В этом смысле шарп — значительно более академичный язык. Ну и вообще дотнет как платформа. Там даже ассемблер можно читать, он не намного сложнее форта. Программисты на плюсах как правило восторгаются красивыми конструкциями (большая часть которых, кстати, появилась в языке относительно недавно), совершенно забывая о том ужасе, который можно увидеть, просто опустив глаза. Чудеса линковки и раздельной компиляции как раз относятся к тому мусору, который болтается у плюсов под ногами с самого рождения.

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

K>Дык квалификации не хватит

Вот так всегда. А как появляется квалификация, так сразу же начинаются проблемы с религией.

Hello, Ts_Rus!

TR> Народ, простите за оффтоп, но ОДИН вопрос: неужели можно на .net
TR> создать GUIкомпонент, который можно будет использовать на web-странице
TR> как ActiveX или как Java-апплет??? Если, да, то напишите плз на мыло
TR> хотя бы.....

тут
http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx

WBR, Igor Evgrafov.

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

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

VD>>Что касается С++, то весь кай дотнета, что в нем очень легко интегрировать в проект сразу несколько языков. Без проблем можно интегрировать и С++. А будет Питон для дотнета, то и его тоже. Хоть функцинальные языки.

FR>Питон для дотнета уже есть, но сильно коммерческий.

Как насчет http://ironpython.com/ ?

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

VD>Да-да. Давно не флэймили по поводу C# vs. С++.

VD>Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.

VD>Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.

2. Движки баз данных

3. Игры

4. Любая область, где требуется выжать максимум из имеющихся ресурсов (проц и память).

---------
То, что многие С++ программисты умудряются писать программы, сопоставимые по скорости с аналогичными на C#, говорит о том, что им срочно надо переходить на C#, и начать, наконец, приносить человечеству пользу.

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

Честно говоря статья меня немножко расстроила =( С++/CLI только как язык низкого уровня.

А ведь должно быть в свое время, какой-нибудь матерый ассемблерщик: "Блин, ну дожили! На асме только драйвера пишутся и то только критичные по скорости. А так куда ни ткни — С или С++". Эволюция...

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

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

FR>>Часто командная строка интерпретатора удобнее всего что ты описал

VD>Возможно, но это каким же аутотренингом нужно заниматься?

просто ты не работал с интерпретаторами, я тоже так думал

VD>>>5. Куча форумов с очень высоким уровнем.

FR>>тоже самое

VD>А ссылки можно?

http://www.python-in-business.org/
http://www.python.org/pycon/
http://www.europython.org/
comp.lang.python


FR>>ну у Питона как и у си тоже вся сила в библиотеках

VD>Вот только у С этих библиотек в общем-то практически нет. Если только в их список записать Вынь АПИ.

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

VD>>>Очень и очень страно. Я своими глазами видел, что скорость у них идентична.

FR>>сейчас еще раз проверил 30% отставание точно есть, на некторых до двух раз.

VD>Ну, вот видишь 20% уже ты сократил. Еще ару раз перемерить и дойдешь до 0.001.
VD>Я вот запускал и у меня ФПС был просто идентичным.

Ладно это все фигня, надо на реальных задачах смотреть.

FR>>да я скачал еще этот портированный на шарп OGRE, вообще интересно их сайт читать,
FR>>практически твоими словами описывают преимущества шарпа

VD>Дык это слова тех кто уже использует это дело и кое что в нем понимает.

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

FR>>и там же заявляют
FR>>что портированная версия быстрее чем плюсовый оригинал,

VD>Ну, этого я что-то не видел. Наоборот процентах о 10-20 проигрыша речь шала. Может просто чуть-чуть движок подлатали. Ну, да это оптимизация, а не приемущество Шарпа и дотнета. Тут надо все трезво воспринимать. Быстрее Шарп быть не может. Но на уровне очень даже. Главное не делать некоторых ошибок.

Я там по форумам немного лазил, писали что быстрее.
Да и насчет простоты написания объем-то исходников практически одинаков с плюсами

FR>> в общем потестировал,
FR>>шарп отстает на те же 30% — 50%, так что доверие к их рекламе сильно подорвано

VD>А вот это уже выдумки.

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

FR>>На питоне кода тоже в разы меньше чем на плюсах. И автодокументация встроенна в язык

VD>Дык ни кто и не спорит, что Питон со временем может стать неплохой альтернативой Шарпу. Чем выше конкуренция, тем лучше.

У C# папа слишком богатый

FR>>скорее всего нет, но его более чем достаточно для скрипта.

VD>Дык а кому нужны скрипты если есть язык и рантайм не чем им не уступающем, но при этом мало чем отличающимся от С++ по производительности?

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

VD>Тут или скрипты перестанут быть скриптами, или они станут польностью не конкурентно способными. Ведь любая интерпретация на порядок медленнее компиляции.

FR>>если честно я отношусь к таким тестам с большим недоверием, но если будет свободное время сделаю.

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

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

FR>>Питон как и java и C# использует виртуальную машину. То есть компиляция в байт код и потом исполнение.

VD>Шарп не исполняет байткод. В дотнете всегда происходит компиляция в исполняемый код. От того и высокая скорость работы. Ява тоже имет джит, но он предполагает и интерпретацию.

FR>>А проверки да большей частью в runtime (мне это тоже не нравится)

VD>Дык именно их минимизация и сделала дотнет таким шустрым. Если в код С++ встроить все те проврки что есть в дотнете, то он проиграет очень серьезно. Там целая куча оптимизаций делается. Те же проверки на выход за пределы массивов выносятся из циклов как инварианты. При таком контроле 10% проигрыша, то не поражение, а победа.

Продолжаем рекламу

FR>>А на питоне import MyModule
FR>>все грузится дмнамически, притом можно переопределить механизм загрузки

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

Ты преувеличиваешь сложности. Реально для модов не нужна особо навороченная модульность.

VD>Тут же чистая реализация. И основной код, и плагин живут в одной среде.

FR>>вроде нет, хотя я не сильно интересовался.

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

Посмотрю может триал появился.

Ребята, вы подумайте головой, а потом говорите
1. Что будет с вашей ДЛЛ на машине, где нет фреймворка ?
2. тот пример, что вы показываете, я видел, вернее другой вариант, но он чото у меня не заработал. Вы когда ссылки кидаете, их просто находите или сами проверяете?

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

VD>Не совсем новичек — это что-то из серии чуть-чуть беременная?
Не смешно. Дело в том что берменность это вполне конкретное состояние, а профессиональный уровень постоянно меняется.

VD>К сожалению, без базовых понятий новичек скорее столкнется с уровой действительностью находящейстя чуть ниже пояса, чем с нужным лицом.
Ну это если начинать без книжки или с не правильной книжки (например с Шилдта или подобной ереси типа "С++ за 21 день" ). На пример посмотри "Эффективное программирование на С++" Кёниг, Му ИМХО очень правильная книжка по С++ для новичков.(описание есть на сайте)
Хотя без мозгоправа всеравно не обойтись. Например мне в форуме по С++ очень не плохо мозги вправили. Пусть не в один день но результат на лицо.

VD>Это если не изучить после него ничего путного и не приучиться писать код.
Увы и ах... но таких много... И такие "программисты" взрощенные на .НЕТ уже начинают появляться
VD>Шарп тем и хорош, что в нем можно гормонично программировать так как он сам подвигает к использованию ОО-парадигмы.
Не больше чем дельфя. Дизайнеры форм один в один, функциональность языков схожа... ИМХО теже яйца только лучше.

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

VD>Ты не напоминай. Ты перечисляй. А то под другие ведь можно записать 99% всег ПО, а можно 0.0001%.
Не знаю как в процентах, но вот конкретно сейчас я занимаюсь разработкой SMTP сервера под линукс. И что-то шарпа в округе не видно

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

V>Ну с этим тоже врядли кто-то будет спорить...

Ох споря... и еще как?!

VD>>Возможно ее удастся притормозить с помощью C++/CLI, но это уже тоже ведь не С++.
V>По аналогии: а С#_2 — это уже не C#?

C++/CLI — это стандарт который вряд ли будет принят С++-сообщетсвом. Оно довольно сильно консервативно. Максимум сможет немного повлиять. Но это годы...

V>Но, как минимум, одно это уже свидетельствует о будущем долголетии языка.

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

VD>>По большому счету сегодня из серьезных на рынке только дотнет и Ява.
V>А С++ один такой...

А причем тут С++. Ты же про фрэймворки говорил. Да и не один он. Много чего еще есть. Просто он один из самых поуплярных... пока...

VD>>К тому же большая часть таких рантаймов может быть с успкхом написана на дотнете. Например, тот же компилятор Шарпа без проблем пишится на Шарпе же.
V>Так то оно так, но это ИМХО всеравно, что разрабатывать GUI на С++. То есть, конечно, можно, но не удобно...

Ну, вот в этом ты сильно заблуждаешся. Я как бы имею опыт созадния парсера на Шарпе. К тмоу же есть компилятор Моно. Никаких особых проблем нет. Все очень удобно и более чем работоспосбно. Так что это неверный стереотип.

V>А есть еще всяческие real-time задачи, мимо которых С# пролетает на значительном отдалении.

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

V>И еще — из компьютерных игр шарпу не вытеснить С++.

Гы. Очень даже вытеснить. Не сразу конечно. Но через несколько лет народ прийдет к пониманию, что писать игры на Шарпе быстрее и удобнее. Примеры уже есть. Я вроде бы уже говорил. Тут Оранж давал ссылку на 3D RTS. Очень неплохо работает. А по архитектуре на порядок делает разные там именитые WarCraft-ы.

V> Ссылку не помню, но читал, как даже сама Microsoft позиционирует шарп в играх (PC) в качестве скриптового языка.

Я не знаю что ты там читал. Но я видел реально работающий проект.

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

V> То есть на С++ пишется движок, а на шарпе высокоуровневая логика. Далее. Напомню, что самые популярные игровые платформы — это консоли. А тут C# совсем идет лесом.

Уже есть и 3D движки на Шарпе. И полноценные игры испльзующие D3D. Так что можно их скачать и убедиться в неверности данной догмы.

V>2. Движки баз данных

V>3. Игры

V>4. Любая область, где требуется выжать максимум из имеющихся ресурсов (проц и память).

V>---------
V>То, что многие С++ программисты умудряются писать программы, сопоставимые по скорости с аналогичными на C#, говорит о том, что им срочно надо переходить на C#, и начать, наконец, приносить человечеству пользу.

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


Ну вы как маленьие дети... C# нужен там где требуется качесво кода и бытстрота разработки. За языками с автоматической сборкой мусора будущее. И в не зависомти будете ли вы топать ногами и кричать что C#, Java отстой они будут двигаться вперед. Ни куму уже не интересно при разработке прикладных задач иметь геморой с указателями и утечками памяти, всем требуется реализация бизнеслогики, а не поиски что же произошло с указателем на указатель .

C++ нужен там где требуется производительность и затарата минимум ресурсов. Это уже и так обсудили не один раз.

Давайте поставим точку, а то такой флейм можно продолжать очень долго.

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

FR>>>тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же
FR>>>плюсовых.

VD>>Очень и очень страно. Я своими глазами видел, что скорость у них идентична.

FR>сейчас еще раз проверил 30% отставание точно есть, на некторых до двух раз.
FR>да я скачал еще этот портированный на шарп OGRE, вообще интересно их сайт читать,
FR>практически твоими словами описывают преимущества шарпа и там же заявляют
FR>что портированная версия быстрее чем плюсовый оригинал, в общем потестировал,
FR>шарп отстает на те же 30% — 50%, так что доверие к их рекламе сильно подорвано

Использую:

Retail версии DirectX 9.0c (Summer 2004) и Managed DirectX v9.02.3900.
Radeon 9550 (VS & PS 2.0), Athlon 2000+, 3DNow!

Пример:                 C# 1.1    VC++ 7.1

BasicHLSL.exe           363 f/s   365 f/s
CustomUI.exe            223 f/s   200 f/s
EnhancedMesh.exe         76 f/s    77 f/s
HDRCubeMap.exe           44 f/s    45 f/s
HLSLwithoutEffects.exe  314 f/s   317 f/s

Я всё равно не делал бы выводов о производительности, на основе этих тестов...

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

S>Здравствуйте, Kluev, Вы писали:
K>>Вот куски функций по которым можно оценииь скорость работы:
S>Я правильно понимаю, что ты умеешь работать исключительно с блоками фиксированного размера? В таком случае действительно не имеет смысла говорить о фрагментации.

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

З.Ы. Сейчас у хипов одна из главных проблем нехватка адрессного пространства, именно адрессов, а не физической памяти. С переходом на 64 бита когда адрессов будет очень много, можно за счет резервирования адрессного пространства получить очень мощные оптимизации, такие что new-delete приблизятся к распределению на стеке. У меня уже руки чешутся написать 64-битный распределитель

Здравствуйте, prVovik, Вы писали:
V>Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически. У C# и сейчас существует серьезный конкурент в лице Java
V>Короче говоря, все очень неоднозначно...

??? написать компилятор для С++ на С++ не имея самого компилятора С++ невозможно если быть чесным до конца , а не брать те "тонны нароботок которые имеются на данный момент и прочее" ... Реализовать Framework на C# думаю немного не верный подход , C# это одни из языков для .NET Framework , так что не верный "упрек" на мой взгляд
А то что есть конкурент , нам как потребителям это даже хорошо , для M$ есть стимул делать лучше

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

K>P.S. Если надо могу подбросить, в С++ форуме уже выкладывал


ну... аллокатор блочного типа — это обычно первый аллокатор, который пишут.

Проблема в том, что:

1. он предназначен для выделения кусков памяти определенного размера (скажем, нам сначала понадобилось очень много памяти под мелкие объекты, потом мы эти объекты освобождаем и более их вообще не используем, но память операционке не возвращаем )

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

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

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

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

V>>2. Движки баз данных

VD>Легко.

V>>3. Игры

VD>Легко.

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


V>>4. Любая область, где требуется выжать максимум из имеющихся ресурсов (проц и память).

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

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

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


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

Нет не в этом дело, дошейдерные 3D API представляют собой реально конечный автомат(state machine) так вот OpenGL достаточно красиво и лаконично реализует эту машину, и псевдообъектность Direct3D никаких преимуществ для описания такой машины не дает.

VD>Может он даже был и прав. Но по факту прелесть D3D не в том, что с ним красивее работать, а в том, что он обеспечивает значительно более высокий уровень абстракции от железа. И тут Кармак явно поставил не на ту лошадку. Хотя учитывая любовь Кармака выкладывать старые движки под ГНУтой лицензией, и то что D3D вряд ли появится под тем же Линуксом можно считать OpenGL единственны выбором определенным судьбой.

Реально Direct3D тогда (да и сейчас) не обеспечивал более высокий уровень абстракции.
Кармак не мог предвидеть, что на восьмой версии у D3D наконец то появится нормальная архитектура, а OpenGL расползется стараниями компаний производителей железа.

FR>>Но сейчас Dx лучше. А разницу между картами приходится и в Dx учитывать, но это проще чем мучатсяс несовместимыми расширениями.

VD>Ну, Кармак мужик крутой. На сегодня Дум 3 действительно самый крутой движок. Он и самый быстрый среди крутых, и самый навороченый. По крайней мере визуально дум рвет все что я видел до этого. Их ад просто изумителен. При этом он таки дет на топовом железе во всей красе. Так что может он и поставил не на ту лошадку, но вложенные усилия позволили ему приехать первым и на хромой кобыле.

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

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

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

VD>Я в свое время делал сравнение скорости родного Квака и портом http://gzip.rsdn.ru/Forum/Message.aspx?mid=325529&amp;only=1

Автор: VladD2
Дата: 16.07.03

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

Открываю солюшен, нахожу проект "ref_soft" — софтверный рендеринг.
В проекте 22 файла на С, 9 файлов на ассемблере и один на C++, плюс в сишных файлах много ассемблерных вставок.
У меня тот самый порт от Vertigo Software.

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

FR>>>comp.lang.python
VD>>Это все на английском. Да и не море это. А на русском по дотнету форумов хватает, а по питону я даже и не видел.
Dog>Каких ещё кошерных форумов по дотнету можно почитать ?

У нас тут есть раздел ссылок там их хватает. Из самых извесных www.gotdotnet.ru .

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

K>MFC тускай отмирает, давно пора =) а С++ мой любимый язык и не хотелось бы расставаться с ним в скором будущем, но думаю придется =(

Ну если вы пишите только desktop-приложения, то конечно. Странно только, почему вы до этого пользовались C++ — есть более удобные платформы разработки: Java, Delphi, VB etc. Но ИМХО C++ не умрет, т.к. есть много унаследованного кода, и если в России еще можно на все плюнуть, и переписать все с нуля, только потому что такая прихоть программиста, то в Америке оооочень осторожно относятся к нововведениям — там до сих пор многие крупные конторы используют MS VC 6.

Есть задачи, которые на фреймворке даже теоретически по-моему не решить например написание Интернет ActiveX компонент, для встраивания на странички тегом <OBJECT>. Не знаю как они правильно называются

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

T>Есть задачи, которые на фреймворке даже теоретически по-моему не решить например написание Интернет ActiveX компонент, для встраивания на странички тегом <OBJECT>. Не знаю как они правильно называются

Как раз именно это на .NET без проблем и гораздо быстрее чем на C++ Только это не ActiveX естественно, но смысл тот же.

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

А>Честно говоря статья меня немножко расстроила =( С++/CLI только как язык низкого уровня.
А>
А> А ведь должно быть в свое время, какой-нибудь матерый ассемблерщик: "Блин, ну дожили! На асме только драйвера пишутся и то только критичные по скорости. А так куда ни ткни — С или С++". Эволюция...


Да уж, скоро C# можно будет для написания драйверов только использовать ...

пример в "студию"

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

VD>Да-да. Давно не флэймили по поводу C# vs. С++.
Дак яж говорил о другом! Я говорил, что С++ живее всех живых и помирать у него даже в отдаленных планах нет. Это, кстати, НЕ на тему "C# vs C++"!

VD>Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.
Ну, как минимум, написание фреймворков

VD>Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.
Ну вот ты и сам все знаешь

А еще напомню, что помимо майкрософтовских осей существуют и другие. Вот на них полноценное пришествие .NET'а ИМХО невозможно. И никакие роторы, моны и дотгнуты тут, увы, не помогут

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

V>Дак яж говорил о другом! Я говорил, что С++ живее всех живых и помирать у него даже в отдаленных планах нет. Это, кстати, НЕ на тему "C# vs C++"!

Дык это почти никто и не утвреждает. Нужно быть просто таки фанатиком чтобы это говорить. Друго дело, что С++ уже сдает позиции. А в будущем эта тенденция только увеличится. Возможно ее удастся притормозить с помощью C++/CLI, но это уже тоже ведь не С++.

VD>>Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.
V>Ну, как минимум, написание фреймворков

Фрэймворк понятие аморфное. Например, Линглво переводит это слова как: остов, корпус, каркас; структура, строение; система взглядов, точка отсчета, рамки; ферма; стропила. Так что нужно точно уточнять что имеется в виду. Если низкоуровневая часть рантайма для самого дотнета, то несомненно. Но об этом я уже говорил. И таких продуктов нужны еденицы. По большому счету сегодня из серьезных на рынке только дотнет и Ява. К тому же большая часть таких рантаймов может быть с успкхом написана на дотнете. Например, тот же компилятор Шарпа без проблем пишится на Шарпе же. Причем даже проще выйдет. Тот же Моно имеет очень мало С-шного кода. 98% Моно написано на шарпе же. Думаю МС не сдела тоже самое потму, что у них просто небыло этого самого дотнета, чтобы сделать его на нем же .

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

VD>>Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.
V>Ну вот ты и сам все знаешь

Дык это очень усзка область разработки ПО. Ею занимаются еденицы во всем мире. Так что можно смело утверждать, что дотнет в общем, и Шарп в частности — это универсальные средства разработки.

V>А еще напомню, что помимо майкрософтовских осей существуют и другие. Вот на них полноценное пришествие .NET'а ИМХО невозможно. И никакие роторы, моны и дотгнуты тут, увы, не помогут

Ты не напоминай. Ты перечисляй. А то под другие ведь можно записать 99% всег ПО, а можно 0.0001%.

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

VD>>Ну, как новичку я бы точно советовал начать с Шарпа.
WH>Нуесли только совсем новичку то пожалуй согласен.

Не совсем новичек — это что-то из серии чуть-чуть беременная?

WH>Проблема С++ в том что он многолик но если иметь дело с правильным лицом то и чувство прекрасного ни куда не денется и воспринимается С++ не хуже шарпа.

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

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

Это если не изучить после него ничего путного и не приучиться писать код. Шарп тем и хорош, что в нем можно гормонично программировать так как он сам подвигает к использованию ОО-парадигмы.

А>нахрен выпускают книги по c++ если в скором времени подавляющее большинство софта на C# и java писаться будет? и мне как новичку забыть о с++ и начать сразу с C#?
Как можно забыть то чего не знаешь
Вы сначала ответьте себе на вопрос Зачем я занимаюсь\хочу заняться программированием?
А то развели тут флейм, только перья летятъ

Hello, WolfHound!

VD>> Вот Шарп — это как раз позволяет изучить СП и ООП без надобности в
VD>> разных мозгоправах.
W> Уверен? А я нет. Ибо опыт общения с дельфисами которые ни чего
W> кроме дельфи не видили говорит об обратном. А дельфя и шарп всетки очень
W> похожи.

Мне нравится ход вашей мысли Продолжим "логическую" цепочку. А еще Шарп похож на Java следовательно и программисты Java тоже нифига не понимают в ООП. Кто-ж тогда в энтом ООП разбирается?

VD>> Дык еще есть те кто вообще программировать не умеет. Не списывать же
VD>> это на язык? Многие кто сейчас пишет на совершенно разных языках
VD>> начинал на Бэйсике. Причем не на Васике, а на ужасном и убогом его
VD>> диалекте.
W> Ну я тоже начинал с васика... точно тебе говорю без мозгоправов
W> никуда... вспомни меня образца 2002 года... ну ламер последний... самому
W> сейчас стыдно.

Да ладно, все мы когда то были ламерами. Независимо от того на чем писали.

VD>> В общем, для обучения на сегодна Шарп, по-моему, самое оно.
W> Ну если рядом будет стоять мозгоправ то пожалу да. А если мозгоправа не
W> будет то FCL может легко развратить не окрепший ум. Огромная бибилиотека
W> которую легко использовать в промышленном программирование не сомненно
W> большой плюс. Но для новичка это может быть если не фатальным то потом
W> выходить из состояния "если нет компонента то задача не решается" будет
W> очень сложно.

Мне кажется не FCL дело тут а в множестве всяческих визардов, которые генерят код ни разу не подталкивающий к написанию правильных с точки зрения архитектуры программ. Все эти драг н дропы OleDbConnection'ов на форму ни разу не нужны при правильном подходе к делу. А во всех туториалах MS именно так учит...

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

Если в какой-то книжке про С++ написано просто, значит они умалчивают о половине возможностей языка и сопуствующим им граблей. Я вот почитываю местную конфу по С++, так многопостовые обсуждения о том, что именно делает написанная конструкция и какие ее side effects не редкость. Язык очень сложен и противоречив. Недаром Страуструп признает, что сам до конца не знает С++ Что уж говорить про новичков.

Про C# я ни разу такого, слава богу не видел. Все всегда однозначно и понятно. Именно это и позволяет уделать больше внимания именно организации программ...

Да и к примеру исходники FCL (даже через Reflector) читаются не в пример легче чем исходники STL и BOOST. Там я без бутылки мало чего понимаю.

WBR, Igor Evgrafov.

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

VD>>Скачай Моно и увидишь.
V>Можешь назвать рерьезные проекты, сделанные под Моно?

Конечно. Моно! Очень серьезный проект.

А вообще, моно официально зарелизен с месяц назад. К тому же глупо делать подукт под моно. Имеет смысл использовать Моно в качестве средства переноса на другие платформы.

M>движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой)
Таких движков на PC нет: все общаются с карточкой только через DirectX и/или OpenGL.
А движок игры — это далеко не только работа с карточкой.

M>>>движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой)
__>>Таких движков на PC нет: все общаются с карточкой только через DirectX и/или OpenGL.

LSL>А как же Software rasterization ? Кажется, в Q2 такое есть...

Так когда этот движок писали еще и ускорителей толком не было.
Мы же говорим о настоящем моменте (и C#): сейчас для комерческих 3D-игр для PC это уже давно не актуально — железо порвет любой
Software rasterization.

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

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


VD>В общем, для обучения на сегодна Шарп, по-моему, самое оно. А плюсы всегда были сложноваты.

Да вообщем профессия "программист" — не обещает легких путей... Если боишься трудностей, то
тогда, ИМХО, в мир программирования лучше не соваться.

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

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

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

FR>>Вот не верю я про разы(хотя много раз уже слышал), в общем придется самому всеръез
FR>>изучать C# для проверки.

VD>Да, уж. Только открою один сикрет. Нужно пережить первые несколько месяцев когда все непревычано. Кстати, ту по теме вчера появилось Первый месяц с .Net :)

Автор: trial
Дата: 11.10.04

.

Это с любым новым языком так, я вот ocaml уже пару раз пытался освоить,
но не идет и все. А тот же питон почти сразу пошел.

FR>>насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.

VD>Точно проще. Тут опять таки складываются несколько факторов:
VD>1. Очень неплохая документация интегрированная в МСДН.

У питона тоже хорошая документация.

VD>2. Куча книг от очень хороших авторов (Рихтер, Дон Бокс).

Аналогично, в последнее время стало немало и переведенных книг.

VD>3. Одна из лучших IDE (да и не одна). Обеспечивающая кучу визардов, комплит ворд, описание функций илассов, рефакторинг и т.п.

Часто командная строка интерпретатора удобнее всего что ты описал

VD>4. Очень быстрый компилятор шарпа (да и плюсы заметно быстрее компилировать начинают).

Что-то я не заметил что VC7.1 быстрее компилирует чем VC6

VD>5. Куча форумов с очень высоким уровнем.

тоже самое

VD>6. Куча статей (я лично штук 10 написал ).

тоже хватает

VD>7. Очень легкая в освоении библиотека.

ну у Питона как и у си тоже вся сила в библиотеках

VD>6. Похожесть на многие передовые средства разработки (Дельфисы и плюсовики частенько спорят о конрях).

VD>В общем, всего и не перечислишь.

FR>>тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же
FR>>плюсовых.

VD>Очень и очень страно. Я своими глазами видел, что скорость у них идентична.

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

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

FR>>не понимаю почему проще.

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

На питоне кода тоже в разы меньше чем на плюсах. И автодокументация встроенна в язык
Да и на плюсах тот же doxygen отлично все документирует.

FR>>Ну все не так плохо, один jit для питона уже появился.

VD>Ну, ты сам как считашь, может этот джит потягаться по скорости создаваемого кода с тем же VC 7.x?

скорее всего нет, но его более чем достаточно для скрипта.

VD>Кстати, у нас тут на сайте лежат тесты. Если не влом, воспроизведи на Питоне и померяем его относительную производительность.

если честно я отношусь к таким тестам с большим недоверием, но если будет свободное время
сделаю.

FR>>К тому же питон типизированный язык, но не со статической а с динамической типизацией.

VD>Динамическая — это в рантайме? Если так, то для скорости это приговор. Это неменуемо выливается в интерпретацию (проверку типов в рантайме). А она принципиально медленее. Конечно отдельные операции можно оптимизировать, но в общем производительность получается не ахти. Хотя, повторюсь, нужно мерить.

Питон как и java и C# использует виртуальную машину. То есть компиляция в байт код и потом исполнение.
А проверки да большей частью в runtime (мне это тоже не нравится)

FR>>Ты в рекламном агенстве раньше не работал

VD>Нет.
VD>Просто делюсь тем что мне самому нравится.

FR>>А ссылку можно?
FR>>Интересно посмотреть.

VD>Ёлы, палы, какждый второй ссылки требует. Я уже задолбался. Вот минут 10 искал: Re: Частые вычисления по неопределенной формуле!!!

Автор: VladD2
Дата: 07.05.04

.

смотрю

FR>>Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?

VD>Объем кода требуемый для этого. На том же С++ для динамического подключения модулей нужно создать свой фрэймворк. Учитывая, что в С++ вообще нет ничего по работе с исполняемыми модулями, то такой фрэймворк для каждой платформы прийдется писать занова. Можно конечно воспльзоваться COM-ом. Но сним один фиг траха на порядок больше. А на шарпе подключение модуля будет выглядеть примерно так:

А на питоне import MyModule
все грузится дмнамически, притом можно переопределить механизм загрузки

FR>>Питон для дотнета уже есть, но сильно коммерческий.

VD>Здорово звучит "Сильно коммерческий".
VD>Интересно, а какой-нить версии для некомерческого использования у них нет?

вроде нет, хотя я не сильно интересовался.

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

FR>Реально в то время когда Кармак критиковал, Direct3D был просто убожищем по сравнению с OpenGL.

Ну, анрыл на нем таки работал. Да и критиковал Кармак его не за убогсть функциональности, а за принципы организации интерйейса. Мол как прикрасно выглядит:

НачатьИнифиализациюЧегототам();
ЗабитьНекиеДанныеВЭтоЧегототам(1);
ЗабитьНекиеДанныеВЭтоЧегототам(2);
ЗабитьНекиеДанныеВЭтоЧегототам(3);
ЗакончитьИнифиализациюЧегототам();

а в D3D это же будет выглядеть как:

ххх->ЗапроситьНекийСерсис(ууу);
НЕКАЯ_СТРУКТУРА zzz;
zzz.ЧтотоТам = некоеЗначение;
zzz->ВыполнитьИнициализациюЧегототам(&zzz);

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

Может он даже был и прав. Но по факту прелесть D3D не в том, что с ним красивее работать, а в том, что он обеспечивает значительно более высокий уровень абстракции от железа. И тут Кармак явно поставил не на ту лошадку. Хотя учитывая любовь Кармака выкладывать старые движки под ГНУтой лицензией, и то что D3D вряд ли появится под тем же Линуксом можно считать OpenGL единственны выбором определенным судьбой.

FR>Но сейчас Dx лучше. А разницу между картами приходится и в Dx учитывать, но это проще чем мучатсяс несовместимыми расширениями.

Ну, Кармак мужик крутой. На сегодня Дум 3 действительно самый крутой движок. Он и самый быстрый среди крутых, и самый навороченый. По крайней мере визуально дум рвет все что я видел до этого. Их ад просто изумителен. При этом он таки дет на топовом железе во всей красе. Так что может он и поставил не на ту лошадку, но вложенные усилия позволили ему приехать первым и на хромой кобыле.

Здравствуйте, Kluev, Вы писали:
K>Никто и не спорит, что плюсам хорошо бы кровь сменить и органы пересадить. ИМХО пора забить на синкасическую совместимость с С, и провести радикальный рефакторинг.
Ну... провели. Получилась Java. Через восемь лет еще раз провели. Получился C#.
Видишь ли, из песни-то слова не выкинешь. Чтобы забыть о моделях памяти, надо избавиться от указателей. Чтобы забыть о хидерах, надо сделать полноценную компонентную модель. Как только мы это сделали, встает вопрос времени жизни.

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

FR>из командной строки интерпретатора?

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

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

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

FR>У питона тоже прозрачная интеграция с C/C++ а учитывая SWIG то вообще просто пишешь нужные расширения на плюсах, а все остальное делается автоматом.

Гы. Плюсы идут лесом! Расширять дотнет можно прямо на Шарпе. Описал функцию в шарпе и вперед.

FR>Ну судя по абзацу ниже все-таки религиозная

Не. Ошибашся. Это может и пропаганда, но на основе фактов и личного опыта. Тут веры никакой. А в религии вера — это главное.

FR>ну так я про что и говорил все время, классика ядро плюсы, верхний уровень скрипт.

Зачем? Чтобы было медленнее и ненадежнее? Конечно можно ядро на плюсах... Но зачем скрипты то? Хотя и ядно смысла не много. Разве что особо критичные ко времени участки вынести в плюсы.

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

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

FR>Вообще то строка и список в питоне тоже объекты, от них даже наследоватся можно.

Вопрос не в этом. Вопрос в том, что универасльные фунции на Питоне будут в те смамые 10 раз медленнее чем аналогичные на Шарпе.

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

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

VD>>Не должен. Это вещественные числа и при вычислениях они не совсем 0.

FR>Да ну, по любому переполнение будет.

Если будет — будет исключение. К тому же сравнивались результаты. В общем, махни на единицу. Ровным счетом ничего не должно измениться.

FR>Я проверил скорсть та же остается.

Ну, о чем я и говорю.

FR>Похоже старый баг (некоторые говорят фича) VC и в шарп перешел, заключается в игнорировании ошибок с плавающей точкой.

Это не баг. Это особенности препроцессора. 0 в вещественном виде сильно отличается от целочисленного.

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

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

T>Ребята, вы подумайте головой, а потом говорите
T>1. Что будет с вашей ДЛЛ на машине, где нет фреймворка ?

Ты даже не представляешь, но говорят (сам я не пробовал) что Microsoft Office 2003 на Microsoft Windows 98SE не устанавливается. Чем программисты Office Team думали? Точно не головой! Это ж надо было такой огромный парк компьютеров оставить без Office.

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

VD>У тебя с религией все ОК? Займись. По сути нужно реализовать реструктуризатор так чтобы он поддерживал этот сервер. Если получится, то дальше там уже фигня останется. Хотя перед работой хорошо бы тесты сделать.

Дык квалификации не хватит

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

VD>Скорость же дотнетного кода очень близка к лучшим компиляторам С++.
Тесты скорости исполнения C# vs ICC в студию!

VD>И даже превышает некоторые компиляторы.
ага, BС например

Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

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

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

K>>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

V>Не вдаваясь в технические детали: разработка с С# в три раза быстрее идет чем с С++, прикинь сколько баблища можно съэкономить...!!! не знаю как чистый С++, но MFC точно в ауте

MFC тускай отмирает, давно пора =) а С++ мой любимый язык и не хотелось бы расставаться с ним в скором будущем, но думаю придется =(

K>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/vs05cplus.asp

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

K>>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

AC>http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/vs05cplus.asp

Честно говоря статья меня немножко расстроила =( С++/CLI только как язык низкого уровня.

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

T>Есть задачи, которые на фреймворке даже теоретически по-моему не решить например написание Интернет ActiveX компонент, для встраивания на странички тегом <OBJECT>. Не знаю как они правильно называются

Правда это как раз делается очень даже легко. Но торетически конечно можно все.

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

W>Как раз именно это на .NET без проблем и гораздо быстрее чем на C++ Только это не ActiveX естественно, но смысл тот же.

Собственно регистрируется практически как ActiveX.

Народ, простите за оффтоп, но ОДИН вопрос: неужели можно на .net создать GUIкомпонент, который можно будет использовать на web-странице как ActiveX или как Java-апплет??? Если, да, то напишите плз на мыло хотя бы.....

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

T>Ребята, вы подумайте головой, а потом говорите
T>1. Что будет с вашей ДЛЛ на машине, где нет фреймворка ?
T>2. тот пример, что вы показываете, я видел, вернее другой вариант, но он чото у меня не заработал. Вы когда ссылки кидаете, их просто находите или сами проверяете?

Сдается мне, что дело тут не в голове, а в руках.

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

S>А ведь должно быть в свое время, какой-нибудь матерый ассемблерщик: "Блин, ну дожили! На асме только драйвера пишутся и то только критичные по скорости. А так куда ни ткни — С или С++". Эволюция...
Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически. У C# и сейчас существует серьезный конкурент в лице Java и неизвестно, что еще Microsoft придумает в будущем. С другой стороны, есть достаточно моного областей, в которых С/С++ незаменимы и конкурентов у них не видно даже на горизонте и даже с высокого места. В связи с этим, я абсолютно не удивлюсь, С# умрет раньше, чем С/С++...

Короче говоря, все очень неоднозначно...

Также напомню, что будет развиваться сам язык, будут выходить новые версии компиляторов (в т.ч. и от Microsoft), будет продолжать накапливаться база исходных кодов на С/С++, так что смерть языку уж точно не грозит.

V>Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически.
А это почему ?

V>много областей, в которых С/С++ незаменимы
например ? мне кажется что С# может заменить С/С++ или это просто кажется ? =)

V>Короче говоря, все очень неоднозначно...
согласен =)

нахрен выпускают книги по c++ если в скором времени подавляющее большинство софта на C# и java писаться будет? и мне как новичку забыть о с++ и начать сразу с C#?

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

V>Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически. У C# и сейчас существует серьезный конкурент в лице Java и неизвестно, что еще Microsoft придумает в будущем. С другой стороны, есть достаточно моного областей, в которых С/С++ незаменимы и конкурентов у них не видно даже на горизонте и даже с высокого места. В связи с этим, я абсолютно не удивлюсь, С# умрет раньше, чем С/С++...

V>Короче говоря, все очень неоднозначно...

Да-да. Давно не флэймили по поводу C# vs. С++.

Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.

Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.

Здравствуйте, VladD2, Вы писали:
VD>Ну, давай выкладывай список областей где С++ вне конкуренции и где вообще не приминим C#.
VD>Моя версия — такая область одна — это создание низкоуровневого кода вроде ОС, драйверов и виртуальных машин.

С чем пришлось с толкнуться, или с чем собираюсь:

1. Воспроизведение звука, когда точность контроля позиции воспроизведения нужна повыше, чем позволяет ДиректИкс (хотя конечно, если голова есть то можно декодер и на шарпе написать, но сам не могу и ни одного ещё не видел)

2. Есть МФЦ\МДИ приложение, в котором у МДИ-фрейма два клиента, и дочерние окна открываются либо в одном, либо в другом, в зависимости от их вида, например. Догадываюсь, что с таким "чудой-юдой" мало кто знаком, но удобная вещь. У меня на шарпе подобное до конца не получилось... может и сам виноват.

3. Буду рад услышать, что возможно Определение разрыва TCP-соединения

Автор(ы): Андрей Елсуков
Дата: 03.10.2004
В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.

(хотя, наверное, здесь С++ и не причём, как посмотреть).

4. Расширение shell, свой аплет (cpl) в контрольной панеле... но и это можно обозначить как "ОС"...

В общем в 98% случаев шарпа хватит и за глаза и за уши

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

V>>Только есть один маленький нюанс: компилятор С/С++ можно написать на самом С/С++, а вот реализовать .NET framework на C# невозможно даже теоретически.
K>А это почему ?
Ну а как ты себе это представляешь? Фреймворк внутри фреймворка?

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

_FR>1. Воспроизведение звука, когда точность контроля позиции воспроизведения нужна повыше, чем позволяет ДиректИкс (хотя конечно, если голова есть то можно декодер и на шарпе написать, но сам не могу и ни одного ещё не видел)

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

_FR>2. Есть МФЦ\МДИ приложение, в котором у МДИ-фрейма два клиента, и дочерние окна открываются либо в одном, либо в другом, в зависимости от их вида, например. Догадываюсь, что с таким "чудой-юдой" мало кто знаком, но удобная вещь. У меня на шарпе подобное до конца не получилось... может и сам виноват.

Это вопрос решается на Шарпе ни чуть не хуже чем на МФЦ, думаю, что даже лучше.

_FR>3. Буду рад услышать, что возможно Определение разрыва TCP-соединения

Автор(ы): Андрей Елсуков
Дата: 03.10.2004
В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.

(хотя, наверное, здесь С++ и не причём, как посмотреть).

Я в этом не спец. Но думаю, что замечания по первому пункту умесны и тут.

_FR>4. Расширение shell, свой аплет (cpl) в контрольной панеле... но и это можно обозначить как "ОС"...

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

_FR>В общем в 98% случаев шарпа хватит и за глаза и за уши

Согласен.

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

VD>Дык это почти никто и не утвреждает. Нужно быть просто таки фанатиком чтобы это говорить. Друго дело, что С++ уже сдает позиции. А в будущем эта тенденция только увеличится.
Ну с этим тоже врядли кто-то будет спорить...

VD>Возможно ее удастся притормозить с помощью C++/CLI, но это уже тоже ведь не С++.
По аналогии: а С#_2 — это уже не C#?

VD>Фрэймворк понятие аморфное. Например, Линглво переводит это слова как: остов, корпус, каркас; структура, строение; система взглядов, точка отсчета, рамки; ферма; стропила. Так что нужно точно уточнять что имеется в виду. Если низкоуровневая часть рантайма для самого дотнета, то несомненно. Но об этом я уже говорил. И таких продуктов нужны еденицы.
Но, как минимум, одно это уже свидетельствует о будущем долголетии языка.

VD>По большому счету сегодня из серьезных на рынке только дотнет и Ява.
А С++ один такой...

VD>К тому же большая часть таких рантаймов может быть с успкхом написана на дотнете. Например, тот же компилятор Шарпа без проблем пишится на Шарпе же.
Так то оно так, но это ИМХО всеравно, что разрабатывать GUI на С++. То есть, конечно, можно, но не удобно...

VD>Дык это очень усзка область разработки ПО. Ею занимаются еденицы во всем мире. Так что можно смело утверждать, что дотнет в общем, и Шарп в частности — это универсальные средства разработки.

А есть еще всяческие real-time задачи, мимо которых С# пролетает на значительном отдалении.

И еще — из компьютерных игр шарпу не вытеснить С++. Ссылку не помню, но читал, как даже сама Microsoft позиционирует шарп в играх (PC) в качестве скриптового языка. То есть на С++ пишется движок, а на шарпе высокоуровневая логика. Далее. Напомню, что самые популярные игровые платформы — это консоли. А тут C# совсем идет лесом.

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

V>Не знаю как в процентах, но вот конкретно сейчас я занимаюсь разработкой SMTP сервера под линукс. И что-то шарпа в округе не видно

Скачай Моно и увидишь. Уж SMTP на шарпе как нечего делать пишется. Для таких задач он просто иделен.

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

VD>>Не совсем новичек — это что-то из серии чуть-чуть беременная?
WH>Не смешно. Дело в том что берменность это вполне конкретное состояние, а профессиональный уровень постоянно меняется.

Профессиональный уровень беременной?
Если серьезно, то или он новичек, или уже нет. Если человек уже знает ЯП, то говорить об изучении программирования глупо.

WH>Ну это если начинать без книжки или с не правильной книжки (например с Шилдта или подобной ереси типа "С++ за 21 день" ).

Хотя да... Если подсунуть новичку Александреску, то можно просто дать гарантию, что на С++ он уже никогда в жизни писать не будет.

WH> На пример посмотри "Эффективное программирование на С++" Кёниг, Му ИМХО очень правильная книжка по С++ для новичков.(описание есть на сайте)

Я ее не видел. Но уже слово "Эффективное" говорит само за себя. Человеку еще нужно понять что такое "программирование" (не говоря уже о С++), а ты ему "Эффективное" суешь.

WH>Хотя без мозгоправа всеравно не обойтись. Например мне в форуме по С++ очень не плохо мозги вправили. Пусть не в один день но результат на лицо.



Ужас какой.

Вот Шарп — это как раз позволяет изучить СП и ООП без надобности в разных мозгоправах.

WH>Увы и ах... но таких много... И такие "программисты" взрощенные на .НЕТ уже начинают появляться

Дык еще есть те кто вообще программировать не умеет. Не списывать же это на язык? Многие кто сейчас пишет на совершенно разных языках начинал на Бэйсике. Причем не на Васике, а на ужасном и убогом его диалекте.

WH>Не больше чем дельфя. Дизайнеры форм один в один, функциональность языков схожа... ИМХО теже яйца только лучше.

Больше. Хотя дельфи тут тоже не самый худший вариант. Просто в отличии от нее он не имет ряда ошибок и более целостен. Дельфи ведь было в каком-то смысле пробразом Шарпа.

В общем, для обучения на сегодна Шарп, по-моему, самое оно. А плюсы всегда были сложноваты.

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

V>Не вдаваясь в технические детали: разработка с С# в три раза быстрее идет чем с С++, прикинь сколько баблища можно съэкономить...!!! не знаю как чистый С++, но MFC точно в ауте

Не, ну, по разному конечно бывает. Бывает, что и 1:1, а бывает, что и в 20 раз быстрее. С Шарпом порой забываешь времена когда по три часа капался в МСДН чтобы ответить на простой вопрос.

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

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

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

во-во, т.е. надо остановиться на очень высоком (почти абстрактном) прикладном уровне...

в общем, прикладным программистам и шарп в руки

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


VD>Скачай Моно и увидишь.
Можешь назвать рерьезные проекты, сделанные под Моно?

ie>Вы все правильно говорите, и когда речь идет о разработке ПО для Windows, спорить тяжело. НО! Не стоит забывать про многие другие платформы, а так же про множество программ для, например, DSP ориентированных устройств. Пока я еще не видел не одного компилятора C# или Java для DSP.
ie>Один из моих университетских преподавателей рассказал как-то историю, спорил он как-то с американцем каким-то (тоже преподавателем) по поводу обучения студентов, типа с чего надо начинать с низкоуровневых языков и наверх (мнение нашего преподавателя) или сосредоточиться на обучении Java-подобных языков и ООП. Они все таки пришли к общему мнению, решили, что
ie>наш (Россия-чемпион!) преподаватель был прав. Как они пришли к этому? Да, посчитали (как считали не рассказывал) количество кода написанного для ПК (и пусть он весь написан хоть на C#) и количество кода написанного для DSP (тут и сотовые телефоны и умный дом, и сигнализации, и поворачиващееся зеркало, когда по среди ночи какой-нибудь урод сзади дальним светит, и авиация, и т.д.), для множества других микропроцессоров и микроконтроллеров (тут все от промышленных установок до наручных часов).
ie>Резюме: есть множество областей, где не только C# не применяют и скорее всего и не будут применять, но и не знают о нем, это для них пустой звук.

Большинство западных студентов заканчива университет ничего не знают о типах данных и как они обрабатываюся процессором и отделенно слышали о таких вещах как integer, float overflow. В любую программу обучения будущего программиста должна включаться история микропроцессоров и C/C++ или Asm. Это закон, но не везде это соблюдается особенно, на западе, где народ выбирает пердметы какие ему понравится Не обязательно начинать с асемблера или C — обычно если начинать с этих языков, то это отбивает всякий интерес к обучению или народ просто перестает видеть перспективы высокоуровневых языков.
Вот инетерсненькая статья на эту тему здесь

P.S. Вообще Java и .Net — это языки на которых можно хорошо изучить ООП и RUP.

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

VD>Если серьезно, то или он новичек, или уже нет. Если человек уже знает ЯП, то говорить об изучении программирования глупо.
Тут вопрос в том что значит знает ЯП? Если знает что делают операторы это одно, а если знает все и все тонкости то это совсем другое.

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

VD>Я ее не видел. Но уже слово "Эффективное" говорит само за себя. Человеку еще нужно понять что такое "программирование" (не говоря уже о С++), а ты ему "Эффективное" суешь.
Пастернака не читал но осуждаю...

VD>Вот Шарп — это как раз позволяет изучить СП и ООП без надобности в разных мозгоправах.
Уверен? А я нет. Ибо опыт общения с дельфисами которые ни чего кроме дельфи не видили говорит об обратном. А дельфя и шарп всетки очень похожи.

VD>Дык еще есть те кто вообще программировать не умеет. Не списывать же это на язык? Многие кто сейчас пишет на совершенно разных языках начинал на Бэйсике. Причем не на Васике, а на ужасном и убогом его диалекте.
Ну я тоже начинал с васика... точно тебе говорю без мозгоправов никуда... вспомни меня образца 2002 года... ну ламер последний... самому сейчас стыдно.

VD>Больше.
И чемже? Я на шарпе могу легко написать чисто процедурную программу. Для этого всеголишь надо сделать все функции и данные класса статическими. Или создать один экземпляр класса.
В любом случае от ООП и следа не останется.
VD>Хотя дельфи тут тоже не самый худший вариант. Просто в отличии от нее он не имет ряда ошибок и более целостен. Дельфи ведь было в каком-то смысле пробразом Шарпа.
С этим я вобщем и не спорю.

VD>В общем, для обучения на сегодна Шарп, по-моему, самое оно.
Ну если рядом будет стоять мозгоправ то пожалу да. А если мозгоправа не будет то FCL может легко развратить не окрепший ум. Огромная бибилиотека которую легко использовать в промышленном программирование не сомненно большой плюс. Но для новичка это может быть если не фатальным то потом выходить из состояния "если нет компонента то задача не решается" будет очень сложно.
VD>А плюсы всегда были сложноваты.
Ну это смотря с какой стороны их начать изучать. Я когда в следующий раз буду в Москве привезу эту книжку. Поверь мне там все просто и доходчиво.
Хотя конечно чтобы изучить все тонкости С++ придется приложить большие усилия. Но то что с него нельзя начинать обучение я не согласен.

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

WH>

Мемори лик: Злое, мифическое существо по мнению дтнетчиков обитающие в каждой программе на С++.

(С) WolfHound

Если бы это было не правдой, то тогда не было таких прогамм как Bounds Checker-ы

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

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

WH>>

Мемори лик: Злое, мифическое существо по мнению дтнетчиков обитающие в каждой программе на С++.

(С) WolfHound

M>Если бы это было не правдой, то тогда не было таких прогамм как Bounds Checker-ы

Bounds Checker просто имеет свой рынок

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

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

V>Bounds Checker просто имеет свой рынок

Это не едниственный инструмент подобного рода (что то было еще и от Борладн). Просто, я с этой программой работал, когда писал на С++.

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

Точно! Смарт Поинтеры. А чем они лучше тех же ссылок, которые сами освобождают область памяти?

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

T>Ребята, вы подумайте головой, а потом говорите
T>1. Что будет с вашей ДЛЛ на машине, где нет фреймворка ?
Гм. А что будет c апплетом на машине, где не стоит джава плугин?
T>2. тот пример, что вы показываете, я видел, вернее другой вариант, но он чото у меня не заработал. Вы когда ссылки кидаете, их просто находите или сами проверяете?
Для того, чтобы помочь заставить примеры работать, у нас есть более тематические форумы. Велкам

Здравствуйте, ie, Вы писали:
ie>Резюме: есть множество областей, где не только C# не применяют и скорее всего и не будут применять, но и не знают о нем, это для них пустой звук.
Ну ты насмешил. Кода для DSP написано бесконечно мало. Это очень узкий рынок.
З.Ы. Насколько мне известно, подавляющее большинство кода приложений, применяемых в данный момент, написано на Коболе.

V>> То есть на С++ пишется движок, а на шарпе высокоуровневая логика. Далее. Напомню, что самые популярные игровые платформы — это консоли. А тут C# совсем идет лесом.
не думаю, что Sony для своей PlayStation3 поставит фреймок .NET-а — они даже графический апи собрались для нее делать OpenGL-like

VD>Уже есть и 3D движки на Шарпе.
VD>Так что можно их скачать и убедиться в неверности данной догмы.
а ссылочки можно на 3D движки на шарпе.

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

V>2. Движки баз данных

Легко.

V>3. Игры

Легко.

V>4. Любая область, где требуется выжать максимум из имеющихся ресурсов (проц и память).

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

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

ie>Вы все правильно говорите, и когда речь идет о разработке ПО для Windows, спорить тяжело.

Дык это только вопрос времени. Уже есть Моно. Да и Ява разбивается очень даже неплохо.

ie> НО! Не стоит забывать про многие другие платформы, а так же про множество программ для, например, DSP ориентированных устройств. Пока я еще не видел не одного компилятора C# или Java для DSP.

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

ie>Резюме: есть множество областей, где не только C# не применяют и скорее всего и не будут применять, но и не знают о нем, это для них пустой звук.

Я бы сказал пока есть.

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

WH>...а если знает все и все тонкости то это совсем другое.

Это называется гуру. Не путай понятие не новичек и гуру/специалист.

VD>>Хотя да... Если подсунуть новичку Александреску, то можно просто дать гарантию, что на С++ он уже никогда в жизни писать не будет.
WH>Ты не понял. Шилдт и Александреску это совершенно разные явления. Если Шилдт просто ламер (извините другое слово подобрать не получается ) и его книги нельзя читать по тому что там очень много ошибок. То Александруску просто раказывает о не очевидных свойствах С++ которые новичку воспринять трудно. Так что почувствойте разницу.

Да все я понял. Собственно ты мои слова и подтверждаешь.

WH>Хотя конечно для обучения новичка не годятся оба автора.

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


VD>>Вот Шарп — это как раз позволяет изучить СП и ООП без надобности в разных мозгоправах.
WH>Уверен?

Да.

WH> А я нет. Ибо опыт общения с дельфисами которые ни чего кроме дельфи не видили говорит об обратном. А дельфя и шарп всетки очень похожи.

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

WH>Ну я тоже начинал с васика... точно тебе говорю без мозгоправов никуда... вспомни меня образца 2002 года... ну ламер последний... самому сейчас стыдно.

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

WH>Ну если рядом будет стоять мозгоправ то пожалу да.

Ненадо насилия.

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

V>во-во, т.е. надо остановиться на очень высоком (почти абстрактном) прикладном уровне...

V>в общем, прикладным программистам и шарп в руки

Себя уговаривашь?

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


V>>3. Игры

VD>Легко.

Вот игры меня интересуют, вернее ускорение их разработки, вот можешь мне объяснить преимущества C# для написания игр по сравнению со связкой C++/Python (или другой хороший скрипт)?
Я никаких не вижу.

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

K>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было. Хотелось бы узнать, неужели С++ не приживется в новой платформе ? А что будет если fw будет напрямую взаимодействовать с ядром, тогда С++ совсем отомрет ?

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

К списку ресурсоемких задач, для которых я бы не рискнул использовать C# (и вообще байт-код), я бы отнес еще шахматы, СУБД, движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой), возможно другие...

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

__>а ссылочки можно на 3D движки на шарпе.

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

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

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


M>Мне кажеться, что основная проблема C++ в том, что очень тяжело привлекать в проект программистов средней и невысокой квалификации. К тому же освоить C++ в полном объеме это достаточно нетривиальная задача. Я например, этого сделать не смог И вообще, пользуюсь только теми языками, для которых смогу написать компилятор

А такие языков много?
А то мне наверно по такому принципу придется перейти на Basic или Forth

M>К списку ресурсоемких задач, для которых я бы не рискнул использовать C# (и вообще байт-код), я бы отнес еще шахматы, СУБД, движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой), возможно другие...

Приведи пример хоть одной игры под Win, сделаной скажем за последние 5 лет, и которая напрямую общается с карточкой.
Я таких не знаю. И подозреваю у тебя неправильные представления о том что такое OGL и DX.

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

M>>Мне кажеться, что основная проблема C++ в том, что очень тяжело привлекать в проект программистов средней и невысокой квалификации. К тому же освоить C++ в полном объеме это достаточно нетривиальная задача. Я например, этого сделать не смог И вообще, пользуюсь только теми языками, для которых смогу написать компилятор

FR>А такие языков много?

Смогу <> написал.


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

DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)

M>DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)
OpenGL

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

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

__>>а ссылочки можно на 3D движки на шарпе.

LSL>Сколько угодно

вообще-то очень большое число игр сейчас используют скрипты, у некторых логика
практически целиком написана на java, lua или python, так что C# становится
просто одним из. Нижний уровень все равно на плюсах.

LSL>Axiom

LSL>http://axiomengine.sourceforge.net/

Как я понял это просто интерфейс к OGRE на C# а не полноценный порт.

LSL>Входит в десятку лучших Open Source движков.

можно ссылку на эту десятку?


LSL>http://irrlicht.sourceforge.net/

ну это довольно известная вещь, и написана на плюсах.
Вообще интересно, но дальше смотреть лень.

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

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

M>>>Мне кажеться, что основная проблема C++ в том, что очень тяжело привлекать в проект программистов средней и невысокой квалификации. К тому же освоить C++ в полном объеме это достаточно нетривиальная задача. Я например, этого сделать не смог И вообще, пользуюсь только теми языками, для которых смогу написать компилятор

FR>>А такие языков много?

M>Смогу <> написал.

Ну многие вещи кажутся простыми, пока не попробуешь

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

M>DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)

Кармак как подсел на OpenGL после Q2 так с него и не слазает

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

FR>Вот игры меня интересуют, вернее ускорение их разработки, вот можешь мне объяснить преимущества C# для написания игр по сравнению со связкой C++/Python (или другой хороший скрипт)?
FR>Я никаких не вижу.

Могу. Но чесно говоря это намного лучше было сделано теми кто этим занимается.

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

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

Достигается это тем что:
1. Имеется огромная библиотека.
2. Шапр более высокоуровневый и на нем банально проще писать и отлаживаться.
3. Не нужно делать многих рутинных действий вроде сериализации, контроля ссылок, и т.п.
4. Простота и скорость компиялции позволяют использовать в качестве скриптов тот же Шарп. По сути это означает что от скриптом можно отказаться вовсе. Ведь уровень Шрпа почти идентичен скриптам, а производительность намного выше.
5. Компонентая ориентация. В дотнете вообще нет проблем с динамической загрузкой. Это позволяет очень легко и красиво подключать внешние модули (плагины, энжыны и т.п.).
6. Метаданные позволяют автоматизировать многие процессы производства.

Если на пальцах то создание ОО-модели игрового мира на С++ связан с огромным количеством подготовительных действий. Там и сериализация, и контроль памяти и много чего еще. А на Шарпе все это уже есть. Можно сразу приступать к описанию нужных классов и использовать их.

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

M>К списку ресурсоемких задач, для которых я бы не рискнул использовать C# (и вообще байт-код), я бы отнес еще шахматы, СУБД, движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой), возможно другие...

Re[10]: С++ и .NET

Автор: LSL
Дата: 11.10.04

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

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

M>DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)



Дум 3 вообще нельзя установить на машину где не стоит DX и OpenGL-драйвер.

Последней игрой работабщей с железмо напрямую были Дум 2 и его клоны.

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

FR>вообще-то очень большое число игр сейчас используют скрипты, у некторых логика
FR>практически целиком написана на java, lua или python, так что C# становится
FR>просто одним из. Нижний уровень все равно на плюсах.

Это не всегда так.

LSL>>Axiom

LSL>>http://axiomengine.sourceforge.net/

FR>Как я понял это просто интерфейс к OGRE на C# а не полноценный порт.

Это полноценный порт.

LSL>>Входит в десятку лучших Open Source движков.

FR>можно ссылку на эту десятку?

Можно.

http://www.devmaster.net/engines/

LSL>>http://irrlicht.sourceforge.net/

FR>ну это довольно известная вещь, и написана на плюсах.
FR>Вообще интересно, но дальше смотреть лень.

Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !


Советую обратить особое внимание, на два следующих движка:

http://axiomengine.sourceforge.net/
http://www.punchncrunch.com/

Эти 100% — C#.

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

M>>движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой)
__>Таких движков на PC нет: все общаются с карточкой только через DirectX и/или OpenGL.

А как же Software rasterization ? Кажется, в Q2 такое есть...

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

M>>движки игр (не надстройки над DirectX и OpenGL, а общающиеся напрямую с карточкой)
__>Таких движков на PC нет: все общаются с карточкой только через DirectX и/или OpenGL.

А как же Software rasterization ? Кажется, в Q2 такое есть...

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

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

FR>>вообще-то очень большое число игр сейчас используют скрипты, у некторых логика
FR>>практически целиком написана на java, lua или python, так что C# становится
FR>>просто одним из. Нижний уровень все равно на плюсах.

LSL>Это не всегда так.

Я не спорю есть игры написаные на Delphi и VB, будут и на C#, но не
думаю что C# будет конкурентом в этой отрасли С++. Например Java ничем
ни хуже для этих целей чем C#, но для больших игр не прижилась.

LSL>>>Axiom

LSL>>>http://axiomengine.sourceforge.net/

FR>>Как я понял это просто интерфейс к OGRE на C# а не полноценный порт.

LSL>Это полноценный порт.

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

LSL>>>Входит в десятку лучших Open Source движков.

FR>>можно ссылку на эту десятку?

LSL>Можно.

LSL>http://www.devmaster.net/engines/

коммерческий топ вообще абсолютно несеръезен(Unreal похоже случайно затесался),
открытый если убрать OGRE и небулу похоже составлен по легкости освоения

LSL>>>http://irrlicht.sourceforge.net/

FR>>ну это довольно известная вещь, и написана на плюсах.
FR>>Вообще интересно, но дальше смотреть лень.

LSL>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !



LSL>Советую обратить особое внимание, на два следующих движка:

LSL>http://axiomengine.sourceforge.net/
LSL>http://www.punchncrunch.com/

нихт ферштейн по немецки

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

VD>Могу. Но чесно говоря это намного лучше было сделано теми кто этим занимается.

Не понял, тут есть люди которые пишут игры на C#?

VD>К тому есть несколько предпосылок. Приемущества по сравнению с питомном хотя бы то что результат получается намного быстрее. Если не забивать на производительность, то можно добиваться практически тех же результатов что и на плюсах. По оценкам тех что это уже делал проигрыш составляет 10-20% максимум.

Быстрее по скорости работы кода или скорости разработки? По скорости разработки вряд ли.
RAD тут не нужен, а уровень питона как ЯВУ думаю даже повыше чем C#
Если по коду то сомневаюсь что низкий уровень будет так мало проигрывать C++.

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

VD>Достигается это тем что:
VD>1. Имеется огромная библиотека.

Предназначенная по большей части для GUI?
По моему тут скорее преимущество у плюсов.

VD>2. Шапр более высокоуровневый и на нем банально проще писать и отлаживаться.

И сложнее за счет этого оптимизировать.
А на питоне тоже очень легко и писать и отлаживатся

VD>3. Не нужно делать многих рутинных действий вроде сериализации, контроля ссылок, и т.п.

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

VD>4. Простота и скорость компиялции позволяют использовать в качестве скриптов тот же Шарп. По сути это означает что от скриптом можно отказаться вовсе. Ведь уровень Шрпа почти идентичен скриптам, а производительность намного выше.

У скриптов тоже есть способы поднять скорость.

VD>5. Компонентая ориентация. В дотнете вообще нет проблем с динамической загрузкой. Это позволяет очень легко и красиво подключать внешние модули (плагины, энжыны и т.п.).

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

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

VD>Если на пальцах то создание ОО-модели игрового мира на С++ связан с огромным количеством подготовительных действий. Там и сериализация, и контроль памяти и много чего еще. А на Шарпе все это уже есть. Можно сразу приступать к описанию нужных классов и использовать их.

А вообще я думаю что C# вполне годится для написания игр, и в этом он ни чем ни хуже Java или
питона

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

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

VD>>Могу. Но чесно говоря это намного лучше было сделано теми кто этим занимается.

FR>Не понял, тут есть люди которые пишут игры на C#?

Тут не знаю. Но в Интернете я не раз встречал такие описания. Даже вроде какой-то специализированный сайт видел http://qsite.russia.webmatrixhosting.net/community_cs_sdk_1/default.aspx . И на www.gamedev.ru вроде видел дискуссию. Хотя уже не помню.

VD>>К тому есть несколько предпосылок. Приемущества по сравнению с питомном хотя бы то что результат получается намного быстрее. Если не забивать на производительность, то можно добиваться практически тех же результатов что и на плюсах. По оценкам тех что это уже делал проигрыш составляет 10-20% максимум.

FR>Быстрее по скорости работы кода или скорости разработки? По скорости разработки вряд ли.

Разработка быстрее в разы. Проигрыш в скорости кода в 10-20 процентов.

FR>RAD тут не нужен, а уровень питона как ЯВУ думаю даже повыше чем C#

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

FR>Если по коду то сомневаюсь что низкий уровень будет так мало проигрывать C++.

И зря. Скачай готовые игры и убедись сам. Или тесты из DX.

VD>>1. Имеется огромная библиотека.

FR>Предназначенная по большей части для GUI?

Это с чего же? ГУИ там конечно нехилый, но это только определенный процент.

FR>По моему тут скорее преимущество у плюсов.

У плюсов с библиотеками каша. Одних строк 10 видов. Там на выбор оптимального варианта и его адаптацию уйдет столько времени, что на Шарпе уже все работать будет.

VD>>2. Шапр более высокоуровневый и на нем банально проще писать и отлаживаться.

FR>И сложнее за счет этого оптимизировать.

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

FR>А на питоне тоже очень легко и писать и отлаживатся

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

VD>>3. Не нужно делать многих рутинных действий вроде сериализации, контроля ссылок, и т.п.

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

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

VD>>4. Простота и скорость компиялции позволяют использовать в качестве скриптов тот же Шарп. По сути это означает что от скриптом можно отказаться вовсе. Ведь уровень Шрпа почти идентичен скриптам, а производительность намного выше.

FR>У скриптов тоже есть способы поднять скорость.

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

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

VD>>5. Компонентая ориентация. В дотнете вообще нет проблем с динамической загрузкой. Это позволяет очень легко и красиво подключать внешние модули (плагины, энжыны и т.п.).

FR>Игры не относятся к программам нуждающимся в компонетной архитектуре, а с остальным питон хорошо справляется.

Еще как нужнаются. Сейчас игра без модов и плагинов уже и не игра. Разве что Пакмены разные... К тому же компонентный подход позволяет кроме этого еще и упростить интеграцию различных подсистем. Например, модуль рендеринга может подключаться через извесный интерфейс. Это поволяет развивать и отлаживать его пока другая часть команды работает над другими подсистемаии. Причем в отличии от разных КОМ-ов и доморощенных компонентных моделй используемых сейчас в пердовых продуктах компонентная модель дотнета обходится практически даром (и по потерям скорости, и по усилиям необходимым для ее использования).

FR>А вообще я думаю что C# вполне годится для написания игр, и в этом он ни чем ни хуже Java или
FR>питона

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

Что касается С++, то весь кай дотнета, что в нем очень легко интегрировать в проект сразу несколько языков. Без проблем можно интегрировать и С++. А будет Питон для дотнета, то и его тоже. Хоть функцинальные языки.

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

FR>Я не спорю есть игры написаные на Delphi и VB, будут и на C#,

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

FR>но не
FR>думаю что C# будет конкурентом в этой отрасли С++. Например Java ничем
FR>ни хуже для этих целей чем C#, но для больших игр не прижилась.

А я вот почти уверен, что Шарп займет нехилые позиции в этой области. Просто нужно время на преодаление консерватизма в умах разработчиков.

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

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

А может просто скачать и глянуть? Он вроде опенсорсный...

LSL>>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !

FR>

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

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

M>>DOOM III (насколько я читал обзоры этой игры и интервью с Кармаком)

FR>Кармак как подсел на OpenGL после Q2 так с него и не слазает

Оне не подсел. Он просто фанател с него. И на на Ку2, а еще на Ку1. Он в те времена целую обличительную оду для D3D написал. Правда ларчик открывался просто. Он просто С-шник. И плюсы не использует. А D3D — это ООП, хотя и кривоватый. Все было ОК, до третьего дума. К этому времени разница в ОпенЖЛ от АТИ и Нвидиа стала настолько большой, что он изматерился. Не удевлюсь если следующая игра будет на D3D. К тому же DX они один фиг вроде испльзуют.

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

LSL>А как же Software rasterization ? Кажется, в Q2 такое есть...

А он с железом тоже не общается. Насколько я понимаю он через Direct Draw графику выводит. Ну, а сам рендеринг в памяти.

Кстати, Q2 портирован под дотнет и показывает очень неплохие результаты. Правда сделано это простой перекомпиляцие на МС++, т.е. без шарпа.

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


VD>>>К тому есть несколько предпосылок. Приемущества по сравнению с питомном хотя бы то что результат получается намного быстрее. Если не забивать на производительность, то можно добиваться практически тех же результатов что и на плюсах. По оценкам тех что это уже делал проигрыш составляет 10-20% максимум.

FR>>Быстрее по скорости работы кода или скорости разработки? По скорости разработки вряд ли.

VD>Разработка быстрее в разы. Проигрыш в скорости кода в 10-20 процентов.

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

FR>>RAD тут не нужен, а уровень питона как ЯВУ думаю даже повыше чем C#

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

насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.

FR>>Если по коду то сомневаюсь что низкий уровень будет так мало проигрывать C++.

VD>И зря. Скачай готовые игры и убедись сам. Или тесты из DX.

тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же
плюсовых.

VD>>>2. Шапр более высокоуровневый и на нем банально проще писать и отлаживаться.

FR>>И сложнее за счет этого оптимизировать.

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

не понимаю почему проще.

FR>>А на питоне тоже очень легко и писать и отлаживатся

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

Ну все не так плохо, один jit для питона уже появился.
К тому же питон типизированный язык, но не со статической а с динамической типизацией.

VD>>>3. Не нужно делать многих рутинных действий вроде сериализации, контроля ссылок, и т.п.

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

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

Ты в рекламном агенстве раньше не работал


VD>>>4. Простота и скорость компиялции позволяют использовать в качестве скриптов тот же Шарп. По сути это означает что от скриптом можно отказаться вовсе. Ведь уровень Шрпа почти идентичен скриптам, а производительность намного выше.

FR>>У скриптов тоже есть способы поднять скорость.

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

А ссылку можно?
Интересно посмотреть.

VD>Скорость же дотнетного кода очень близка к лучшим компиляторам С++. И даже превышает некоторые компиляторы. Так что получается типизированный скрипт, с отличной IDE, отладчиком, и скоростью С++. По-моему, заманчиво. Не находишь?

VD>>>5. Компонентая ориентация. В дотнете вообще нет проблем с динамической загрузкой. Это позволяет очень легко и красиво подключать внешние модули (плагины, энжыны и т.п.).

FR>>Игры не относятся к программам нуждающимся в компонетной архитектуре, а с остальным питон хорошо справляется.

VD>Еще как нужнаются. Сейчас игра без модов и плагинов уже и не игра. Разве что Пакмены разные... К тому же компонентный подход позволяет кроме этого еще и упростить интеграцию различных подсистем. Например, модуль рендеринга может подключаться через извесный интерфейс. Это поволяет развивать и отлаживать его пока другая часть команды работает над другими подсистемаии. Причем в отличии от разных КОМ-ов и доморощенных компонентных моделй используемых сейчас в пердовых продуктах компонентная модель дотнета обходится практически даром (и по потерям скорости, и по усилиям необходимым для ее использования).

Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?

FR>>А вообще я думаю что C# вполне годится для написания игр, и в этом он ни чем ни хуже Java или
FR>>питона

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

VD>Что касается С++, то весь кай дотнета, что в нем очень легко интегрировать в проект сразу несколько языков. Без проблем можно интегрировать и С++. А будет Питон для дотнета, то и его тоже. Хоть функцинальные языки.

Питон для дотнета уже есть, но сильно коммерческий.

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

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

FR>>Я не спорю есть игры написаные на Delphi и VB, будут и на C#,

VD>Я что-то не слышал, чтобы на ВБ были портированы движки игр, или что на нем создавались бы дважки с нуля. Скорости у него явно нехватало.

про движки не знаю, но видел достаточно сложные игры.

FR>>но не
FR>>думаю что C# будет конкурентом в этой отрасли С++. Например Java ничем
FR>>ни хуже для этих целей чем C#, но для больших игр не прижилась.

VD>А я вот почти уверен, что Шарп займет нехилые позиции в этой области. Просто нужно время на преодаление консерватизма в умах разработчиков.

видно будет

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

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

VD>А может просто скачать и глянуть? Он вроде опенсорсный...

я в CVS залез, точно портировали.

LSL>>>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !

FR>>

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

да так, не понятно зачем отказыватся от почетного звания скриптового языка

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

VD>Re[10]: С++ и .NET

Автор: LSL
Дата: 11.10.04

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

Неожиданно для многих, Кармак также выступил в защиту обобщений сложных программных интерфейсов приложений, которые могут самостоятельно подвергать декомпозиции графические алгоритмы и оптимизировать себя под техническое обеспечение. Джон высказал свою горечь о присутствии на рынке стольких карт от различных производителей, ATi, nVidia, 3DLabs, Matrox и других, каждая из которых обладает своей уникальной архитектурой. Некотрые имеют 2 конвеера, некотрые – 4, а некотрые – 8. Ручная оптимизация движка под каждую из этих архитектур отнимает много времяни и отвлекает от разработки непосредственно движка и игры. Если бы движки писались с использованием програмных интерфейсов приложений, которые бы автоматически «декомпозировались» под конкретную технику, то можно было бы избежать гор монотонной работы. И пока многие с сожалением высказываются о недостаточной гибкости и широте низко-уровневых настроек и оптимизаций, Кармак проводит аналогию с разницей программирования на «assembly» и «С». Кто програмирует игры в «assembly» сегодня? Да, на «С» не добраться до столь мелких настроек, но зато в освободившееся время можно заняться более важными оптимизациями.

http://games.egomel.com/doom3_2.html

Значит в списке остаются игры вроде шахмат/шашек, СУБД (что еще на моих глазах кушало 100% процессора?)

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


FR>>Питон для дотнета уже есть, но сильно коммерческий.

A>Как насчет http://ironpython.com/ ?

интересно, жаль что очень раняя альфа.

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

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

M>Точно! Смарт Поинтеры. А чем они лучше тех же ссылок, которые сами освобождают область памяти?

Твои managed хендлеры (именно хендлеры, это не ссылки, просто им дали имя ссылок, чтобы легче понимать было), ничем не лучше. Это просто разные способы учета ресурсов.

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

Подход дотнета очень похож. В нем операция возврата памяти еще более длительная и сложная, но она очень удачно отложена.


------
принципы GC можно использовать и в С++ без проблем (давно есть open-source разработки на эту тему).
Правда, ВСЯ программа должна быть написана именно ориентируясь на этот GC, и мы в итоге получаем слабую связь (или сложности) с использованием унаследованного кода.

------
В отличие от дотнета, где у меня нет выбора, на С++ я могу произвольно выбирать способ слежения за ресурсами, и у меня есть шанс выбрать наиболее удачный для каждого конкретного случая. (использование разных стратегий менеджмента ресурсов для разных объектов в одной программе — обычное дело).

Я понимаю, что "когда я пишу на дотнете, я сосредоточен ТОЛЬКО на решаемой задаче", это похвально, разумеется. Но если учесть вышесказанное про задачу (!!! именно бывает такая задача) взять максимум от железки, то ты должен именно взять от нее максимум.

-----
Самое парадоксальное что ПОЧТИ ВСЕ задачи требуют взять максимум от железки, и гораздо проще перечислить задачи, где этого НЕ требуется.

Например:

— GUI (Forms или Веб), ибо ЛЮБАЯ современная система способна справится с той скоростью, с которой юзер кликает на устройства ввода.

— ORM, ибо область применения, где он ВОСТРЕБОВАН — это именно предыдущий пункт.

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

V>Я писал в разное время разные менеджеры памяти. Так вот что характерно, что легко удается получить очень большую скорость выделения памяти, быстрее даже, чем это делает дотнетовский менеджер. Однако, операция возврата памяти обратно менеджеру всегда получалась довольно долгой (я даже играл с такой вещью, как "отложенный возврат", т.е. просто ставил куски памяти в очередь на возврат, и вызывал периодически системную ф-ию для обработки этой очереди).

У меня есть менеджер памяти который и выделяет быстро и удаляет тоже. Более того не использует дополнительной памяти на выделяемый блок. Используется в реальном проекте (все летает). Причем задача может считать несколько суток выделяя и освобождая большие обьемы. Хип в таких условиях фрагментируется и начинает тормозить.

Вот куски функций по которым можно оценииь скорость работы:

// выделяет быстро
   block* alloc_() {
      block *p = cur_->free;
      if ( p ) {
         cur_->free = p->next;
         cur_->used_n++;
         return p;
      }

// сюда заходим редко
      chunk *c = first_;
      for ( ; c; c = c->next ) {
         p = c->free;
         if ( p ) {
            cur_ = c;
            cur_->free = p->next;
            cur_->used_n++;
            return p;
         }
      }
// сюда еще реже
      c = chunk_alloc_();
      if ( c ) {
         p = c->free;
         cur_ = c;
         cur_->free = p->next;
         cur_->used_n++;
         return p;
      }

      return (block*)Tr::out_of_mem();
   }
// а освобождает не-децки быстро
   void free_( void *p ) {
      block *pb = (block*)p;
      chunk *c = (chunk*)((size_t)p & (size_t)chunk_mask_);
      pb->next = c->free;
      c->free = pb;
      c->used_n--;
   }

P.S. Если надо могу подбросить, в С++ форуме уже выкладывал

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

FR>да так, не понятно зачем отказыватся от почетного звания скриптового языка

Дык можешь счить, что теперь на скриптовом языке стало можно писать сам движок.

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

FR>Вот не верю я про разы(хотя много раз уже слышал), в общем придется самому всеръез
FR>изучать C# для проверки.

Да, уж. Только открою один сикрет. Нужно пережить первые несколько месяцев когда все непревычано. Кстати, ту по теме вчера появилось Первый месяц с .Net :)

Автор: trial
Дата: 11.10.04

.

FR>насчет проще думаю это спорно, хотя спорить не буду, слишком плохо знаю шарп.

Точно проще. Тут опять таки складываются несколько факторов:
1. Очень неплохая документация интегрированная в МСДН.
2. Куча книг от очень хороших авторов (Рихтер, Дон Бокс).
3. Одна из лучших IDE (да и не одна). Обеспечивающая кучу визардов, комплит ворд, описание функций илассов, рефакторинг и т.п.
4. Очень быстрый компилятор шарпа (да и плюсы заметно быстрее компилировать начинают).
5. Куча форумов с очень высоким уровнем.
6. Куча статей (я лично штук 10 написал ).
7. Очень легкая в освоении библиотека.
6. Похожесть на многие передовые средства разработки (Дельфисы и плюсовики частенько спорят о конрях).

В общем, всего и не перечислишь.

FR>тесты из DX9SDK на шарпе у меня работают в среднем в полтора раза медленее таких же
FR>плюсовых.

Очень и очень страно. Я своими глазами видел, что скорость у них идентична.

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

FR>не понимаю почему проще.

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

FR>Ну все не так плохо, один jit для питона уже появился.

Ну, ты сам как считашь, может этот джит потягаться по скорости создаваемого кода с тем же VC 7.x?

Кстати, у нас тут на сайте лежат тесты. Если не влом, воспроизведи на Питоне и померяем его относительную производительность.

FR>К тому же питон типизированный язык, но не со статической а с динамической типизацией.

Динамическая — это в рантайме? Если так, то для скорости это приговор. Это неменуемо выливается в интерпретацию (проверку типов в рантайме). А она принципиально медленее. Конечно отдельные операции можно оптимизировать, но в общем производительность получается не ахти. Хотя, повторюсь, нужно мерить.

FR>Ты в рекламном агенстве раньше не работал

Нет.
Просто делюсь тем что мне самому нравится.

FR>А ссылку можно?
FR>Интересно посмотреть.

Ёлы, палы, какждый второй ссылки требует. Я уже задолбался. Вот минут 10 искал: Re: Частые вычисления по неопределенной формуле!!!

Автор: VladD2
Дата: 07.05.04

.

FR>Что мешает подключать на не шарпе модуль рендеринга через известный интерфейс?

Объем кода требуемый для этого. На том же С++ для динамического подключения модулей нужно создать свой фрэймворк. Учитывая, что в С++ вообще нет ничего по работе с исполняемыми модулями, то такой фрэймворк для каждой платформы прийдется писать занова. Можно конечно воспльзоваться COM-ом. Но сним один фиг траха на порядок больше. А на шарпе подключение модуля будет выглядеть примерно так:

// В основном модуля описываем интерфейс который 
// обязан реализовать плагин
interface IMyPlagin
{
    void DoWork();
}

И где-то при загрузке создаем объект и запрашиваем у него этот интерфейс:

...
// Загружаем длл-у (по дотнетовски - сборку).
Assembly assembly = Assembly.LoadFrom("имя сборки, например читаемое из ини-файла");
// Создаем тип. В принципе можно помечать нужные типы атрибутами 
// и создавать их все. Это позволит избежать завязки на конкретные имена.
IMyPlagin myPlagin = (IMyPlagin)assembly.CreateInstance("Некоторое имя класса");
// Вызываем метод плагина
myPlagin.DoWork();

FR>Питон для дотнета уже есть, но сильно коммерческий.

Здорово звучит "Сильно коммерческий".
Интересно, а какой-нить версии для некомерческого использования у них нет?

Здравствуйте, Kluev, Вы писали:
K>Вот куски функций по которым можно оценииь скорость работы:
Я правильно понимаю, что ты умеешь работать исключительно с блоками фиксированного размера? В таком случае действительно не имеет смысла говорить о фрагментации.

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


M>Точно! Смарт Поинтеры. А чем они лучше тех же ссылок, которые сами освобождают область памяти?

А чем они хуже???

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

LSL>http://axiomengine.sourceforge.net/
Тут даже документации нет, одни библиотеки =((( Или я просто не нашел, если кто найдет киньте ссылочку =)
LSL>http://irrlicht.sourceforge.net/
Вот эта вещь понравилась =)

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

LSL>>>Да, на плюсах. Вот тут как раз обёртка. Но не роль скриптового языка !

FR>>

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

Да. Managed DirectX — DirectX API для .NET, тоже обёртка (довольно тонкая) над Native DirectX...

Интересно, что будет дальше, в Longhorn, в WGF. Осталось ждать бета-версию.

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

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

LSL>>А как же Software rasterization ? Кажется, в Q2 такое есть...

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

Графика выводится через собственные алгоритмы на ассемблере. Т.е. сторонние API не используются.

VD>Кстати, Q2 портирован под дотнет и показывает очень неплохие результаты. Правда сделано это простой перекомпиляцие на МС++, т.е. без шарпа.

Смотрел...