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

ГВ>Свежо предание... По идее, такую подстановку можно делать только при уверенности, что модуль, откуда инлайнирована функция, — никогда не будет заменён. А как эту уверенность создать?

Дык комиляция же производится прямо перед первым выполнением. Побочным эффектом явялется то, что модуль можно выгрузить только вместе с AppDoman-ом (с виртуальным приложением).

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

S>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?

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

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

E>1. На нём пишут много людей. А значит не я один такой, кому этот язык нравится.
Ну, вот я на русском пишу. Это же не значит, что он мне нравится.
E>2. На нём пишут много умных людей, т.е. есть с кем посоветоваться.
А сколько умных людей пишит на хинди...
E>3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
Всё? Ну, а где тогда искуственный интелект?
E>4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
Ой ли? И что проходов по памяти днями никогда не искал?
E>5. Объектная ориентированность.
Эка невидаль. Где ее сегодня нет?
E>6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
Ты мне лучще вот эту кострукцию объясни:

...
IItf2 pItf2 = NULL;
pItf1->QueryInterface(IID_pItf2, (void**)&pItf1);

Если С++ так безупречин, то зачем люди придумали такой варварский способ приведения типов? И вообще зачем нужен void* в таком строгом и красивом языке?

E>7. Windows (по крайней мере начиная с 2000) написана на этом языке.

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

E> По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

"Родной язык" — это круто! Но тогда ух переходи на С.

E>8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.
От чего же "даже"?
E>9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

E>Конечно, у этого языка (как и у других) есть недостатки. Но на мой взгляд преимущества все же перевешивают. Возьмите для сравнения так называемый Object Pascal (на самом деле — Delphi). Нигде в мире, кроме как в Delphi этот язык не используется (насколько я знаю, хотя могу ошибаться). В тоже время язык C++ очень распространен и существует практически на всех платформах.

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

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

SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?

Для меня лично — это свобода! Это возможность выражать свои мысли непосредственно на языке, не думая о том, как нужно преобразовать понятия в конструкции кода или как обойти искусственные ограничения, наложенные автором языка "чтобы новичкам было проще изучать". C++ — единственный известный мне высокоуровневый язык, написанный "программистом для программистов" в стиле хакерства начала 60-х прошлого века в MIT. Этот язык дает в твои руки неограниченную мощность, которой, если правильно пользоваться, можно воротить горы. И при этом всем он еще и элегантен, в отличие от других мощных языков типа языков ассемблера.

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

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

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

E>>3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
VD>Всё? Ну, а где тогда искуственный интелект?
Все, для чего известны эффективные алгоритмы.

E>>4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
VD>Ой ли? И что проходов по памяти днями никогда не искал?
А никто не говорит, что управлять памятью вручную нужно путем явного вызова new и delete.
Существует большое количество решений типа аллокаторов, которые безо всяких накладных расходов позволяют реализовать надежную и эффективную модель распределения памяти.

E>>6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
VD>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
А как насчет PERL?

/* Думаешь, тут люди что такое NLP не знают? */

VD>Ты мне лучще вот эту кострукцию объясни:
VD>

VD>...
VD>IItf2 pItf2 = NULL;
pItf1->>QueryInterface(IID_pItf2, (void**)&pItf1);
VD>

VD>Если С++ так безупречин, то зачем люди придумали такой варварский способ приведения типов? И вообще зачем нужен void* в таком строгом и красивом языке?

Это проблемы не C++, а COM, который к C++ отношения не имеет. Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель. И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

E>>9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

VD>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

Ну, хотя бы вышеупомянутый SOM.

E>>Конечно, у этого языка (как и у других) есть недостатки. Но на мой взгляд преимущества все же перевешивают. Возьмите для сравнения так называемый Object Pascal (на самом деле — Delphi). Нигде в мире, кроме как в Delphi этот язык не используется (насколько я знаю, хотя могу ошибаться). В тоже время язык C++ очень распространен и существует практически на всех платформах.

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

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

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

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

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

При этом обязательно наличие компилятора. Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

S>>Например, вот такие конструкции могут сильно облегчить жизнь:

S>>

S>>    _bitmap.~Bitmap();
S>>    new(&_bitmap) Bitmap;
S>>    _bitmap.Create(w, h, depth);
S>>

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

Это если мозгов хватает только на то, чтобы на C# писать.

S>>Ты будешь смеяться, но на *nix установка программы (написанной на С++) очень часто включает в себя компиляцию. Так что гибкость у C++ в этом отношении больше .

VD>Вот из-за этой гибкости обычные люди и избегают Линуксы.

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

S>>При желании — легко учитывается. Контрвопрос — а написанная на чем программа (автоматически) учитывает объем памяти и тип процессора? и как она это делает? И что в данном контексте означает "пр." (прочее)?

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

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

Здравствуйте m.a.g., Вы писали:

mag>Все, для чего известны эффективные алгоритмы.

Значит все таки не всё... :)

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

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

VD>>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
mag>А как насчет PERL?

На счет Перла все в порядке. Его на пять минут посмеяться родили, а он возьми да выживи. :) Это своего рада приложение к регэкспам.

mag>/* Думаешь, тут люди что такое NLP не знают? */

Дык я и сам пока не пойму о чем ты? :)

mag>Это проблемы не C++, а COM

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

mag>, который к C++ отношения не имеет.

Надо мужикам рассказать... До тебя все думали, что COM писали на C++ и, что у C++ было взято очень многое.

mag>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель.

Ты бы ссылку дал, что ли...

mag>И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

Да вот Линх другое дело... одна элентщина. :)

VD>>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

mag>Ну, хотя бы вышеупомянутый SOM.

Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?

Здравствуйте m.a.g., Вы писали:

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

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

mag>При этом обязательно наличие компилятора.

Кто тебе сказал? В .NET есть специльный нэймспэйс Emit, позволяющий генерировать код. Можно конечно и компилировать, но... К тому же есть еще такая штука — CODDOM. С ее попощью можно генерировать код не зависящий от языка и реинжинирить его. VS.NET сериализует контролы прямо в код по средствам CODDOM-а.

mag> Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

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

mag>Это если мозгов хватает только на то, чтобы на C# писать.

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

mag>Просто люди боятся линуксов — надо же, надо еще и учить команды консоли! А виндах все приятно и все можно мышкой делатью

После этой фразы нужно пальцы веером делать.

mag>А чем принципиально хранение программы в промежуточном коде отличается от хранения программы в исходном коде?

1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.
2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.
3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.
4. В сборках присутствует информация о типах которую можно легко читать в рантайме (и не талько).

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

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

S>>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

VD>А если создаь код, то разбирать нужно будет намного меньше.

Нет. Однохренственно.

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

Я уже устал повторять, что при поиске регулярного выражения нечего интерпретировать — это всего лишь поиск.

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

ГВ>Здравствуйте Igor Trofimov, Вы писали:

IT>>а) языка, приятного всем — не придумать
IT>>б) .net — отчасти это попытка "примирить" языки за счет объединения на низком уровне.

ГВ>ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:

сам-то понял, чё написал?

опять сказки про злого Дядю Билла, который всех "причесывает"...

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

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

S>>>Например, вот такие конструкции могут сильно облегчить жизнь:

S>>>

S>>>    _bitmap.~Bitmap();
S>>>    new(&_bitmap) Bitmap;
S>>>    _bitmap.Create(w, h, depth);
S>>>

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

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

это пример что назывется "некачественного кода". Если это не приложение типа "намалякал-забыл", то подобный "самый простой способ" приведет к головной боли читающего/пишущего в будущем. Для серъезных долгоживущих и эволюционирующих проектов такая практика в чем-то катастрофична. Это хаки. Хакеры не строят, хакеры ломают...

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

S>>А потом разбирайся, какую битмапу использовать. Нафиг.

VD>Я обычно разбираюсь сначало. ;)

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

S>>Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

VD>Ты случаем на VB или Дельфи не переписал? Забыли не забыли... добавь и живи спокойно дальше. :)

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

VD>>>А хелперы — это просто обертки. Они не обязательно являются умными и указателями. ;)

S>>Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

VD>Они обычно используется для временных объектов. Их время жизни определяет время жизни обертываемого объекта. Ну, а если нужно порулить вручную, то для этого и делают разные Attach-и, Detach-и и Clear-ы.

Объект не временный. Clear'а у него нет. Ы?

S>>Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++ :)

VD>Ну, это уже демогогия. Тебе шашечки или ехать? Этот компилятор один из самых популярных. 99% созданного кода на нем компилируется.

Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?


S>>Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

VD>Так из мсила как раз украсть все очень легко. Там такое тайпинфо... :)

VD>>>Да? А мы как-то ими пользуемся. :-\ В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

S>>С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

VD>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

Вот и я о том же.

VD>Ну, а компонентами чужими пользуемся. Не все же с нуля писать. Попробуй например на досуге web-броузер написать... а ведь в виде ActiveX-а его подцепить ничего не стоит.

Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

VD>Ну, или тот же сриптинг...

Что такое "сриптинг"? Если это встроенный в программу язык, то меня этим не запугать.

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

S>>Само собой, но в основном они дают повышенную падучесть :) Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

VD>Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок.

Угу, только 99% этих компонентов написаны одной фирмой. Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

VD>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

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

S>>Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

VD>Видимо по этому это он медленнее всех рендерит конечные сцены. :)

VD>Если он что-то и учитывает, то это реализовано на компонентной основе. Это конечно лучше чем ничего, но по сравнению с полной оптимизацией все же не так здорово.

Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

S>>Многопроцессорность тривиально обрабатывается и в программах на C++.

VD>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

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

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

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

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

И что, в .Net есть средства, поддерживающие это? В программе на C++ я просто узнаю количество процессоров и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)? ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

S>> Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

VD>Дык с ними уже и сейчас все не так плохо. Я вот перестал. :)

VD>>>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

S>>Да мне по барабану, кто там кодогенерацией занимается и какое внутренне представление данных использует связка компилятор+линкер.

VD>Ты спросил "почему такие технологии в компиляторах не используют?". Я ответил что пытаются...

S>> Если же кодогенератор у них общий, с какого перепугу джит обгонит машинный код?

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

Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

S>> А начсет DLL'к под разные процы, так это уже есть.

VD>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

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

VD>>>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись. :) Пущай мучаются...

S>>Динамическая — это когда? В рантайме?

VD>Да. Джит работает сразу после запуска приложения.

S>> А она что, бесплатная?

VD>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

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

S>>>>

S>>>>    _bitmap.~Bitmap();
S>>>>    new(&_bitmap) Bitmap;
S>>>>    _bitmap.Create(w, h, depth);
S>>>>

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

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

А>это пример что назывется "некачественного кода". Если это не приложение типа "намалякал-забыл", то подобный "самый простой способ" приведет к головной боли читающего/пишущего в будущем. Для серъезных долгоживущих и эволюционирующих проектов такая практика в чем-то катастрофична.

Ты хочешь сказать, что этот код хуже, чем

 delete _bitmap;
 _bitmap = new Bitmap;
 _bitmap->Create(w, h, depth)

Тогда уж будь добр, обоснуй :) Только отмазки насчет того, что ты или человек, который будет править этот код, не знает C++ в достаточном для понимания этого кода объеме, не принимаются.

А>Это хаки. Хакеры не строят, хакеры ломают...

Где тут хак, блин? Все в соответствии со стандартом — 12.4.12 и 18.4.1.3

Здравствуйте VladD2, Вы писали:
mag>>При этом обязательно наличие компилятора.

VD>Кто тебе сказал? В .NET есть специльный нэймспэйс Emit, позволяющий генерировать код. Можно конечно и компилировать, но... К тому же есть еще такая штука — CODDOM. С ее попощью можно генерировать код не зависящий от языка и реинжинирить его. VS.NET сериализует контролы прямо в код по средствам CODDOM-а.

А что есть Emit, как не компилятор? Тольк по-другому назван...

mag>> Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

VD>Несравнимо более быстрая компиляция.

Данные в студию, плз.

VD>Ну и тем что очень многое уже сделано. Т.е. есть большая начальная база.

Опять-таки, данные в студию. Под юниксы пишут уже 20 лет. Написано явно больше

mag>>Это если мозгов хватает только на то, чтобы на C# писать.

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

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

mag>>Просто люди боятся линуксов — надо же, надо еще и учить команды консоли! А виндах все приятно и все можно мышкой делатью

VD>После этой фразы нужно пальцы веером делать.

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

mag>>А чем принципиально хранение программы в промежуточном коде отличается от хранения программы в исходном коде?

VD>1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.

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

VD>2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.

А что насчем большого количества информации о типах (или как там она называется)? В .NET я с этим не сталкивался, но ту же java можно диз... не дизассемблировать... можно восстановить исходный текст.

VD>3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.

Можно чуть поподробнее?

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

mag>>Все, для чего известны эффективные алгоритмы.
VD>Значит все таки не всё...
Все, что можно реализовать на C# — точно

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

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

А для этого есть Bounds Checker и прочее. Для профилактики разок запустить раз в день — все отлавливается превосходно.

VD>>>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
mag>>А как насчет PERL?

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

mag>>/* Думаешь, тут люди что такое NLP не знают? */
VD>Дык я и сам пока не пойму о чем ты?
О резкой смене темы. В исходном сообщении было про бейсик и перл, про бейсик сказал, а вот про перл умолчал, вроде бы ненамеренно...

mag>>Это проблемы не C++, а COM
VD>Аааа. Я то думал — это попытки обойти проблемы C++ связанные с тем что язык вообще не ориентирован на связь с рантаймом.

Не понял фразу. Что есть "связь с рантаймом"?

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

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

mag>>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель.
VD>Ты бы ссылку дал, что ли...

Да загнулся он, из-за плохого менеджмента

mag>>И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

VD>Да вот Линх другое дело... одна элентщина.

Да там до последнего времени тоже C++ не пахло. pure c, вообще-то везде юзался.

VD>>>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

mag>>Ну, хотя бы вышеупомянутый SOM.

VD>Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?

Почему никто не знает — см. выше.
Поддерживает она все, на что есть маппинг OMG IDL.
В метаклассах.

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

S>Ты всерьез считаешь, что добавить функцию к одному из классов кроссплатформенной библиотеки существенно проще, чем написать две строчки кода? Для добавления функции у меня дня три только на переписку с разработчиками библиотеки уйдет.

S>Объект не временный. Clear'а у него нет. Ы?

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

S>Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?

У вас прсто не правильный подход. Пистаь нужно на VC, а уж потом портировать (делать код совместимым с...) на другие компиляторы. В других компиляторах тоже есть свои проблемы. Это специфика бумажного стандарта (нет эталона).

VD>>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

S>Вот и я о том же.

О чем? До фига не до фига. Есть же! В другом виде вообще нет.

S>Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

Ну-ну. После этого проблемы с поддержкой продукта конечно кончатся... вместе с клиентами. :)

S>Угу, только 99% этих компонентов написаны одной фирмой.

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

S> Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

VD>>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>Ты отрицаешь, что применение разных парадигм программирования приводит к разному среднему количеству ошибок в программах?

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

S>Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

Добавь к длл-кам описание и введи понятие класс/компонент (нечто объеденяющее данные и методы их обработки) и получится компонентная технология. Собственно COM тоже на длл-ках от части основан.

VD>>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

S>Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

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

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

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

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

S>И что, в .Net есть средства, поддерживающие это?

Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.

S>В программе на C++ я просто узнаю количество процессоров...

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

S> и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)?

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

S> ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

Вот только не пойму почему ИИ должен мешать. Если его зачатки есть в программе, то это же просто здорово!

S>Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

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

VD>>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

S>Я уже говорил — то же делается на C++ компиляцией программы на машине конечного пользователя. А плохого то, что дав не много (оптимизацию на конечной машине и т.д.), .NET отбирает куда больше.

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

VD>>Да. Джит работает сразу после запуска приложения.

S>>> А она что, бесплатная?

VD>>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

S>Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

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

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

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

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

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

CBitmap bmp(...);
...
bmp.Clear();
bmp.Create(w, h, depth);

Кто виноват, что у тебя библиотеки кривые?

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

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

S>>Тогда уж будь добр, обоснуй :) Только отмазки насчет того, что ты или человек, который будет править этот код, не знает C++ в достаточном для понимания этого кода объеме, не принимаются.

VD>Тебе уже сказали, что по человечески это выглядело бы примерно так:
VD>

VD>CBitmap bmp(...);
VD>...
VD>bmp.Clear();
VD>bmp.Create(w, h, depth);
VD>

VD>Кто виноват, что у тебя библиотеки кривые?

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

А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

Здравствуйте m.a.g., Вы писали:

mag>А что есть Emit, как не компилятор? Тольк по-другому назван...

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

VD>>Несравнимо более быстрая компиляция.

mag>Данные в студию, плз.

У нас проекты на С++ компилируются 20 синут на Атлоне 2000+. Джит же на той же машине проходит в доли секунд. В .NET все лежит в сборках. У сборок свои способы импрта/экспорта расчитанные на динамическую загрузку. Никаких инклюдов. Все разобрано и сложено в пи-код. Компиляция в таких условиях впревращается в контекстную замену. Только оптимизация время и отнимает. Если тебе нечего делать, найди код по больше и проверь. У меня еще дел хватает.

VD>>Ну и тем что очень многое уже сделано. Т.е. есть большая начальная база.

mag>Опять-таки, данные в студию. Под юниксы пишут уже 20 лет. Написано явно больше ;)

Данные чего? Того что есть огромный нэймспэйс Emit и не меньший CODDOM? В Юниксах этого от родясь небыло. В Яве разве что, да и то... К тому же юникс был создан где-то 30 лет назад. Винды и те уже 15 лет насчитывают. Но толку от этого никакого. Вон гляди, выбросили к чертям архитектуру микроядра и наклепали популистский Линукс. :-/

mag>Прошу прощения у всех, кого оскорбил вышеотквоченной фразой. Вышел из себя, что было не хорошо,

Не надо так. Мы же тут тебя не пытаемся оскорбить. Не хочишь спорить просто отойдит.

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

Ну, так и люди разные бывают и развите идет вперед. То что было нормальным 5 лет назад. На сегодня уже может оказаться устаревшим. К С++ не даром претензии предявляют. Многие кто сейчас смотрит в сторону .NET проффесионально писали (пишут) на С++. И я в том числе. Проблемы и достоинства этого языка эти люди знают не по наслышке. Я, например, не понимаю зачем защищать недостатки? И почему их нельзя исправлять?

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

Ну, а на счет конкретной конструкции... Я высказал свое мнение. Не согласен? Ну, значит мы остались при своих мнениях. Не бить же по этому поводу друг-другу морды? :) Я тебе показал, как бы тоже код написал бы я. И попытался обяснить почему...

mag>Назови мне пять главных причин, по которым люди не переходят под Линукс. Уверен, что там будет "слишком там все сложно".

Обязательно! А так хочешь? Согласись кода в Windows не меньше чем Linux, а значит и сложность систем одинаково велика. Но простой смертный спакойно начинает работать с виндами и мучиется в линуксе. От части это связано просто с отсуствием софта, от части с маркетингом, но в сумме получатся выбор. И выбор получатся не в сторону линукс.

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

VD>>1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.

mag>А какой смысл оптимизировать одноразовую операцию? Ведь речь шла о тюнинге программы на конкретной машине.

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

VD>>2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.

mag>А что насчем большого количества информации о типах (или как там она называется)? В .NET я с этим не сталкивался, но ту же java можно диз... не дизассемблировать... можно восстановить исходный текст.

С Явой для этого придумали обфускаторы (они уродуют все так чтобы обратный инжениринг не дал нормального кода). С .NET вроде что-то должно было встроено в систему, но что я не знаю. В любом случае это не исходный код.

VD>>3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.

mag>Можно чуть поподробнее?

Код можно грузить из разных мест. Так на сервер его можно потавить с диска. На клиента же код может поподать и из Инета. Верификация может гарантировать клиенту, что код полученый из ненадежного источника не содержит опастных системных вызовов или опасной работы с памятью (мсил ведь ничем не отличается по возможностям от ассемблера). Делая .NET MS хотел полностью вытеснить Яву с клиента. А аплеты были некоторым приемуществом Явы.

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

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

S>>Ты всерьез считаешь, что добавить функцию к одному из классов кроссплатформенной библиотеки существенно проще, чем написать две строчки кода? Для добавления функции у меня дня три только на переписку с разработчиками библиотеки уйдет.

S>>Объект не временный. Clear'а у него нет. Ы?

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

Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного
кода на С++, я не пойму.

S>>Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?

VD>У вас прсто не правильный подход. Пистаь нужно на VC, а уж потом портировать (делать код совместимым с...) на другие компиляторы. В других компиляторах тоже есть свои проблемы. Это специфика бумажного стандарта (нет эталона).

Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :)) Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...

VD>>>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

S>>Вот и я о том же.

VD>О чем? До фига не до фига. Есть же! В другом виде вообще нет.

Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.

S>>Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

VD>Ну-ну. После этого проблемы с поддержкой продукта конечно кончатся... вместе с клиентами. :)

Посмотрим. Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...

S>>Угу, только 99% этих компонентов написаны одной фирмой.

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

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

S>> Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

VD>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :) И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.

VD>>>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>>Ты отрицаешь, что применение разных парадигм программирования приводит к разному среднему количеству ошибок в программах?

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

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

S>>Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

VD>Добавь к длл-кам описание и введи понятие класс/компонент (нечто объеденяющее данные и методы их обработки) и получится компонентная технология. Собственно COM тоже на длл-ках от части основан.

Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

VD>>>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

S>>Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

VD>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?

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

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

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

Для одного qsort'а — не надо. А если одновременно с qsort'ом выполняются другие вычисления (еще один qsort, а процессоров всего 2), то очень даже не вредно будет знать, кто из них будет считать дольше и чьи результаты первее понадобяться.

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

S>>И что, в .Net есть средства, поддерживающие это?

VD>Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.

Что именно? И правда интересно.

S>>В программе на C++ я просто узнаю количество процессоров...

VD>Во-во. Просто попытаешься все сделать сам. Таких как ты много было. Но вот программы которые маштабируются на SMP-системах можно по пальцам сосчитать. Речь идет о том, что потоки будут частично контролироваться рантаймом, и о том, что рабоать с ними станет на порядки проще. В С++ нет даже самого понятия потока. В crt есть кое какие функции, но все это фигня на послом масле.

Есть в posix и boost, этого почти достаточно.

S>> и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)?

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

Не верю.

S>> ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

VD>Вот только не пойму почему ИИ должен мешать. Если его зачатки есть в программе, то это же просто здорово!

S>>Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

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

VD>>>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

S>>Я уже говорил — то же делается на C++ компиляцией программы на машине конечного пользователя. А плохого то, что дав не много (оптимизацию на конечной машине и т.д.), .NET отбирает куда больше.

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

VD>>>Да. Джит работает сразу после запуска приложения.

S>>>> А она что, бесплатная?

VD>>>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

S>>Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

VD>А... Ну, вот ты и сравни... Сколько твоя программа будет загружаться и сколько работать. Если ты пишишь утилиту командной строки выполняющую одно-два действия, то время джита для тебя может оказаться критичным. Но если ты пишишь серверное- или GUI-приложение, то компяляция всего лишь замедлит загрузку такого приложения. Для серверного приложения — это вообще не критично. Для клиентского — медленная загрузка. Решение в случае консоли и гуи является ngen (пре джит).

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