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

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

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

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

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

Реально в то время когда Кармак критиковал, Direct3D был просто убожищем по сравнению с OpenGL.
Но сейчас Dx лучше. А разницу между картами приходится и в Dx учитывать, но это проще чем мучатся
с несовместимыми расширениями.

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

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

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

Посмотри оригинал, с которого портировали, там полно документации:

http://www.ogre3d.org

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

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

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

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

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

В любом случае её можно без проблем сгенерировать по XML комментариям.

Здравствуйте, 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

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

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

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

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

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

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

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

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

FR>тоже самое

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

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

FR>тоже хватает

Аналогично.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LSL>

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

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

Это все стандартные тесты? Могу попробывать прогнать на более мощном железе. AMD 64 3500+ ATI 9800 Pro и P4 3.0 Nvidia 6800 GT.

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

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

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

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

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


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

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

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

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

Именно по этому я против изучение С++ на ранних стадиях обучения. А Шарп как раз для этих стадий более чем приемлем.

Оданоко С++ действительно является неплохой гимнастикой для ума. И изучать его точно следует. Это позволит сделать мозг блее гибким. Но опять таки делать это нужно когда уже программист освоил основные концепции структурного и объектно ориентированного программирования.

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

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

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

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

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

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

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

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

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

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

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

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

И куда она выводится? В GDI что ли? К тому же втом самом порте весь асм был похерен (переписан обратно на С) и вроде все работает. По медленнее, но вполне приемлемо.

Все же DD там вроде был. Иначе бы на разрешениях 1280*1024 и выше был бы смертельный тормоз. А он вроде как ничего так себе бегает.

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

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

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

Здравствуйте, 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 действительно самый крутой движок. Он и самый быстрый среди крутых, и самый навороченый. По крайней мере визуально дум рвет все что я видел до этого. Их ад просто изумителен. При этом он таки дет на топовом железе во всей красе. Так что может он и поставил не на ту лошадку, но вложенные усилия позволили ему приехать первым и на хромой кобыле.

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

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


LSL>Использую:

LSL>Retail версии DirectX 9.0c (Summer 2004) и Managed DirectX v9.02.3900.

похоже в 9.0с что-то связанное с манаджет подкрутили, у меня 9.0b

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

Я тоже, там процессор вообще не грузится, да и AGP не задействован.

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

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

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

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

K>С набором размеров. Одна часть выделяет большие блоки, которые затем "режутся" под конкретные размеры.

Плагиат из библиотеки Loki от Александреску ?

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

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

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

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

K>Вот все часто в форуме проскальзывает инфа о том что MC++ официально мертва, и С++/CLI тоже без будущего, помню даже голосование на эту тему было.
Да, верно. Бестолковыые трансформации C++ под нужды .Net. Java тоже начинала с проивопоставления "C++ vs Java". Оба — живее всех живых.

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

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

Кроме того, ты неправильно ставишь вопрос. Вопрос ставить нужно по-другому: приживётся ли новая платформа у C++-ников? Я сказал — C++-ников. Я имел ввиду — квалифицированных. Я знаю очень мало людей, которые хорошо владели C++ и предпочли ему Java. С .Net будет та же история. Я не имею ничего против .Net, просто так получилось.

Подумай и сделай вывод из таких посылок:
"Мемори лик — мифическое существо, по мнению дотнетчиков, обитающее в каждой программе на C++"
"Квалифицированные C++-ники не имеют проблем мемори ликов".