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

V>> Во всей этой ветке речь не шла о том, что дотнет не имеет будущего.
VD>Да нет. Она тут идет подспудно постоянно.
Хм. Подспудно, говоришь... учтём.

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

V>> Это же очевидно, что имеет и еще как. Речь шла о том, что ты сильно заблуждаешься, считая что дотнет легко вытеснит С++ из всех областей (ты приводил то качество стандарта как аргумент, то тот факт что в системных областях С лучше С++, то вот конструкции всякие).
VD>Э... как говорится, стоять Зорька!
VD>Где это я такое утверждал? Где я говорил, что легко, да и вытеснит.
Э... "подспудно" тобой именно это и утверждается на протяжении, чтобы не соврать... лет, эдак, примерно двух.

Про конкретно "все области" мне найти не удалось. Вот, накопал в локальной базе:

Re[8]: С++ и .NET

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

V>И еще — из компьютерных игр шарпу не вытеснить С++.
Гы. Очень даже вытеснить.(выделено мной — ГВ.) Не сразу конечно. Но через несколько лет народ прийдет к пониманию, что писать игры на Шарпе быстрее и удобнее. Примеры уже есть. Я вроде бы уже говорил. Тут Оранж давал ссылку на 3D RTS. Очень неплохо работает. А по архитектуре на порядок делает разные там именитые WarCraft-ы.

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

VD>Мне кажется это очевидным, хотя и с этим очень многие поспорят с пеной у рта.
Если я не ошибаюсь, то до недавнего времени в мире 50% программистов программировали на VB, тогда как C++-ников что-то там чуть ли не на порядок меньше. Только вот численность community трудно притянуть к оценке "способностей" средства. Аргумент коллективом, извините... Или как там, про миллион леммингов-то...

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

V>> Мне даже трудно представить, до какой степени неэффективный код можно будет налепить, обойдясь несколькими строчками рекурсивных итераторов.
VD>А мне очень жаль людей не понимающих, что технические аспекты ничто супратив архитектурных. Ну, да надоело повторяться.
Проблемы проявляются в комплексе, а не в отдельных аспектах. Знаешь, как бывает: все Левши, а блоха не прыгает...

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

VD>>Ты уверен что полностью понимашь, что такое итераторы C# 2.0?
WH>Ты меня с Губановым не путаешь?
WH>Итераторами C# можно пробежатся от начала и до конца контейнера (не обязательно контейнера) при этом только читая значения из него. Единственное чем он отличяется от инпут итератора это тем что можно вернутся в начало последовательности.

И все же похоже ты действительно не очень понимашь о чем идет речь. Речь идет не об энумераторах, а об итераторах — новой концепци реализации тех самх энумераторов. см. http://gzip.rsdn.ru/article/csharp/newincsharp.xml#EJA

Автор(ы): Владислав Чистяков (VladD2)
Дата: 24.06.2004
В статье рассказывается о новшествах, которые должны появиться в новой версии языка C#

раздел "Итераторы".

WH>Тоже относится и к C#. Вот например так я вешаю курсор песочные часы на форму.
WH>

WH>            using(WaitCursor waitCursor = owner.WaitCursor())
WH>            {
WH>            //тут гора тормозного кода который может кинуть исключение итп
WH>            }
WH>

WH>Ладно что хоть с try/finnaly возится не приходится... А все почему? А по тому что в C# нет автоматических деструкторов. И их приходится эмулировать.

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

А твою проблему можно решить намного проще и элегантрее. Например, так:

partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    void UseWaitCursor()
    {
        if (Form.ActiveForm != null)
        {
            Form currForm = Form.ActiveForm;
            currForm.Cursor = Cursors.WaitCursor;
            Application.Idle += delegate(object sender, System.EventArgs e)
            {
                currForm.Cursor = Cursors.Default;
            };
        }
    }

    private void button1_Click(object sender, EventArgs e)
    {
        // Test!
        UseWaitCursor();
        for (int i = 0; i < int.MaxValue; i++)
        {
        }
    }
}

VD>>Так делегаты в общем-то можно заменить объемистыми классами Буста или Локи,
WH>И надо сказать очень не плохо эмулируются...

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

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

Это сказка для не посвященных. Я как бы сам плавал с 25-минутной компиляцией проекта со всем инкриментами и прекомпайлами.

WH>Ну жертв эффективности я чегото не заметил , а вот совместимость это да... Это они погорячились.

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

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

Это реально если этим заниматься. Вот C++/CLI содают же. И "гигабайты" вроде не страдают.

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

VD>И все же похоже ты действительно не очень понимашь о чем идет речь. Речь идет не об энумераторах, а об итераторах — новой концепци реализации тех самх энумераторов. см. http://gzip.rsdn.ru/article/csharp/newincsharp.xml#EJA

Автор(ы): Владислав Чистяков (VladD2)
Дата: 24.06.2004
В статье рассказывается о новшествах, которые должны появиться в новой версии языка C#

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

Кстати а как там с

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

VD>Дык, как видишь ты с успехом обошелся без деструктора.
Ну и в С++ я прекрасно обхожусь без делегатов.
VD>При грамотном подходе потребоность в них появляется очень редко.
Что есть грамотное проектирование вопрос очень сложный и очень сильно зависит от решаемых задач.
VD>Я уже забыл когда мне они были нужны.
using'ом давно пользовался? А это и есть кастыль для хоть какойто эмуляции автоматических деструкторов. Чтобы не приходилось мудить с try/finnaly как это делается в жабе и дельфе...
VD>Нужно только придерживаться идеи занятия ресурсов на минимально возможный период времени.
Да все так и делают. Но вот только когда это поддержывается языком это делать удобней. using конечно тоже не худшее решение но деструкторы лучше.

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

VD>Надо сказать, что припахабно.
А по моему вполне нормально.
VD>Кмпиляцию тормозя,
Миф
VD>с полиморфизмом проблемы,
В смысле
VD>между процессами не передаш,
Ну это проблемы несколько иного порядка и решать их надо на несколько другом уровне.
VD>интерграция с разными компонентными технологиями вроде COM фиговая и т.п.
Ну не знаю. У меня проблем небыло.

VD>Это сказка для не посвященных. Я как бы сам плавал с 25-минутной компиляцией проекта со всем инкриментами и прекомпайлами.
Я какбы сам компилировал.

VD>Проблемы с вызовом деструкторов у суперклассов не имеющих виртуального деструктор тебе знакомы?
Я тебя умоляю... Ты уже устраивал флейм на эту тему. Результаты на лицо... тебя никто не поддержал ибо это не проблема.
VD>А размер int-а?
А что размер инта? У тебя хоть раз с ним были проблемы?
VD>Все это выбор скорости в ущерб стройности дизайна языка и простоте его использования. Примеров таких море.
А валью типы в шарпе? Нафига еще одна сущность?

это выбор скорости в ущерб стройности дизайна языка и простоте его использования

VD>Это реально если этим заниматься.
Твои предложения на счет деструкторов точно не реально.
VD>Вот C++/CLI содают же. И "гигабайты" вроде не страдают.
Тебе самому не смешно? Это чудо можно использовать только для интеграции мендежет и анменеджед кода.
К томуже проблемы то они и не решают.

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

VD>>И все же похоже ты действительно не очень понимашь о чем идет речь. Речь идет не об энумераторах, а об итераторах — новой концепци реализации тех самх энумераторов. см. http://gzip.rsdn.ru/article/csharp/newincsharp.xml#EJA

Автор(ы): Владислав Чистяков (VladD2)
Дата: 24.06.2004
В статье рассказывается о новшествах, которые должны появиться в новой версии языка C#

раздел "Итераторы".
WH>Ты меня точно с кемто путаешь. Про этот синтаксический сахар я прекрасно знаю. Но он не добавляет никакой функциональности.

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

WH>Кстати а как там с
WH>

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

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

WH>Да все так и делают.

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

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

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

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

WH>Я бы не сказал что это проще и элегантней.

Не думать всегда проще чем думать.

WH>К томуже у меня есть чувство что будут проблемы.

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

Однако сам подход действительно более выгоден. Его основная идея — стараться устранить сам факт зависимости, а не упрощать ее отслеживание.

VD>>Кмпиляцию тормозя,
WH>Миф

Я с этого мифа несколько лет начинал свой рабочий день.

VD>>с полиморфизмом проблемы,
WH>В смысле

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

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

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

VD>>интерграция с разными компонентными технологиями вроде COM фиговая и т.п.
WH>Ну не знаю. У меня проблем небыло.

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

VD>>Это сказка для не посвященных. Я как бы сам плавал с 25-минутной компиляцией проекта со всем инкриментами и прекомпайлами.
WH>Я какбы сам компилировал.

Значит объемы у тебя были не те. Или по счастливому стечению обстоятельств небыло нужны в переодической полной перекомпиляции.

Сейчас в R#-е и объемы немаленькие, и перекомпиляция полная происходит переодически, а проблем нет, так как вся перекомпиляция занимает несколько секунд.

VD>>Проблемы с вызовом деструкторов у суперклассов не имеющих виртуального деструктор тебе знакомы?
WH>Я тебя умоляю... Ты уже устраивал флейм на эту тему. Результаты на лицо... тебя никто не поддержал ибо это не проблема.

А ты не умаляй. Грабли есть? Люди на них переодически наступают? А то, что большинство плюсовиков бревна в глазу своего любимого языка незаметят — это и так ясно. Да и разговор этот показал, что дело именно в оптимизации.

VD>>А размер int-а?
WH>А что размер инта? У тебя хоть раз с ним были проблемы?

Они есть у всех кто пишет код для платформ где он разный. Так как я писал код для ДОС-а и Вынь16, то естественно поимел пролем и я. МС вон, в Вынь64 так и оставил его 32-разрядным от греха подальше. А то ведь такая мелочь может создать столько проблем, что охринеешь. И все это именно для оптимизации. А нужна она тому кто язык использует или нет никто не спрашивает.

WH>А валью типы в шарпе? Нафига еще одна сущность?

это выбор скорости в ущерб стройности дизайна языка и простоте его использования

Видимо ты имел в виду струкутры, а не вэлью типы. Так как энумы и простые типы тоже вэлью-типы. Тут, согласен. В Яве так и аргументировли их отсуствие. Более того, я лично зачемчаю, что использую их очень редко. На весь парсер R#-а их ровно две штуки Location и Modifiers. Оба влэлью-типы по своему смыслу.

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

WH>Твои предложения на счет деструкторов точно не реально.

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

WH>Тебе самому не смешно? Это чудо можно использовать только для интеграции мендежет и анменеджед кода.

Отнюдь.

WH>К томуже проблемы то они и не решают.

Они демонстрируют пути решения. Этого достаточно.

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

WH>>Тоже относится и к C#. Вот например так я вешаю курсор песочные часы на форму.
WH>>

WH>>            using(WaitCursor waitCursor = owner.WaitCursor())
WH>>            {
WH>>            //тут гора тормозного кода который может кинуть исключение итп
WH>>            }
WH>>

WH>>Ладно что хоть с try/finnaly возится не приходится... А все почему? А по тому что в C# нет автоматических деструкторов. И их приходится эмулировать.

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

VD>А твою проблему можно решить намного проще и элегантрее. Например, так:
VD>

VD>partial class Form1 : Form
VD>{
VD>    public Form1()
VD>    {
VD>        InitializeComponent();
VD>    }

VD>    void UseWaitCursor()
VD>    {
VD>        if (Form.ActiveForm != null)
VD>        {
VD>            Form currForm = Form.ActiveForm;
VD>            currForm.Cursor = Cursors.WaitCursor;
VD>            Application.Idle += delegate(object sender, System.EventArgs e)
VD>            {
VD>                currForm.Cursor = Cursors.Default;
VD>            };
VD>        }
VD>    }

VD>    private void button1_Click(object sender, EventArgs e)
VD>    {
VD>        // Test!
VD>        UseWaitCursor();
VD>        for (int i = 0; i < int.MaxValue; i++)
VD>        {
VD>        }
VD>    }
VD>}
VD>

[Offtop]
Не, этак не пойдёт — нехорошо будет, если внутри цикла вызывать что-то, тоже использующее UseWaitCursor().
А если в цикле ещё и Application.DoEvents() дёргать периодически

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

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

_FR>[Offtop]
_FR>Не, этак не пойдёт — нехорошо будет, если внутри цикла вызывать что-то, тоже использующее UseWaitCursor().

Это не рабочий код! Это приблизительное решение, описывающее общую идею.

_FR>А если в цикле ещё и Application.DoEvents() дёргать периодически

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

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

WH>Вот именно? Почему Микрософтовци не сдлелали поддержку MVC? Почему мне пришлось это избретать самому?

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

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

VD>А твою проблему можно решить намного проще и элегантрее. Например, так:
VD>

VD>partial class Form1 : Form
VD>{
VD>    public Form1()
VD>    {
VD>        InitializeComponent();
VD>    }

VD>    void UseWaitCursor()
VD>    {
VD>        if (Form.ActiveForm != null)
VD>        {
VD>            Form currForm = Form.ActiveForm;
VD>            currForm.Cursor = Cursors.WaitCursor;
VD>            Application.Idle += delegate(object sender, System.EventArgs e)
VD>            {
VD>                currForm.Cursor = Cursors.Default;

Отписаться забыл.

VD>            };
VD>        }
VD>    }

VD>    private void button1_Click(object sender, EventArgs e)
VD>    {
VD>        // Test!
VD>        UseWaitCursor();
VD>        for (int i = 0; i < int.MaxValue; i++)
VD>        {
VD>        }
VD>    }
VD>}
VD>

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

AVK>Отписаться забыл.
Я в курсе. Это как всегда. Я этот код вообще не запускал.

Надо бы запрос на фичу подать... автоматическая отписка от событий.

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

WH>1)STL-Like итераторы в С++ это совсем не те итераторы что в C#
WH>2)Если приминить мозги то реализация STL-Like итератора дело не такое уж и напряжное
WH>Например реализация итератора для двусвязного списка
WH>

WH>    struct iterator
WH>        :iterator_facade_t
WH>            < iterator
WH>            , value_type
WH>            , std::bidirectional_iterator_tag
WH>            >
WH>    {
WH>      ...
WH>    };
WH>

Что-то на boost::iterator_facade сильно похоже . Слизал, понимаешь, и даже ссылку не дал. Нехорошо