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

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

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

M.NET>>>>>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>>>>>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

S>>>>Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

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

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

W>Есть вам хочется, чтобы exe'шник сам оптимально подстраивался под конкреныю систему? Причем говорится, что с помощью C++

Небольшое уточнение — не exe'шник, а дистрибутив.

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

Именно это, как утверждает Mishka.NET, теоретически возможно в .NET. В том, что это качественно будет реализовано на практике, я сильно сомневаюсь.
Ну а для C/C++ нечто подобное реализуется с незапамятных времен — клиенту поставляется исходный код программы и набор скриптов, который эти исходники компилит. Компилятор поставляется, разумеется, вместе с ОС. Специфика платформы учитывается в основном в конфигурационных скриптах.

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

W>Есть вам хочется, чтобы exe'шник сам оптимально подстраивался под конкреныю систему? Причем говорится, что с помощью C++ компиляторов, такую программу не скомпилировать. Я, конечно, много не знаю, но хочу задать вопрос, а где и каким образом такое вообще можно осуществить. Что бы код, специально не проектированный в расчете на поддержку конкретных платформы, при компиляции неким образом(хотелось бы знать каким, для меня это учень актуально) удовлетворял условию "учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться".

Вот с этого и надо было начинать
.NET тем и отличается, что позволяет это делать. Прога хранится в виде IL (Intermediate Language), а перед выполнением компилируется в native code того процессора, который ты сейчас используешь (вот тебе и оптимизация). Недостаток этого метода — прога стартует слишком медленно.

Ладно, оставим этот спор. Автор вопроса написал, что его интересут не техническая, а эстеттическая сторона дела. Всего хорошего.

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

M.NET>Поток — это stream, а не thread.

Я в курсе. Я это и имел ввиду.

А ты знаешь что такое архитектурный паттерн Pipes and Filters? Он декларирует построение приложений таким образом, чтобы каждое из них имело входной поток и выходной поток (ну, и из-за того, что это на самом деле не идеально, нужен ещё отдельный поток для ошибок). Так вот Windows NT построен на основе другого паттерна — Microkernel. Там нет такого понятия как iostream, оно просто эмулируется (и во всём С++ виноват).

Хм. Помоему они там есть во всяком случае Windows NT
появилось когда Microsoft попыталась сделать windows
совместимым с posix. Правда им это надоело достиаточно быстро.

А микроядро у них появилось на сколько я помню в XP
Win2000 еще не микроядерная.

M.NET>э-э-э ... как бы тебе объяснить... аспекты приложения. Вот в объектно-ориентированном мире есть объекты, а в аспектно-ориентированном к объектам добавляют ещё некие аспекты (например, аспект безопасности, аспект записи в лог и пр.)

Хм. переназванные объекты ядра? Или весь смысл в том что как
раз не ядра?

M.NET>>э-э-э ... как бы тебе объяснить... аспекты приложения. Вот в объектно-ориентированном мире есть объекты, а в аспектно-ориентированном к объектам добавляют ещё некие аспекты (например, аспект безопасности, аспект записи в лог и пр.)

A>Хм. переназванные объекты ядра? Или весь смысл в том что как
A>раз не ядра?

Короче, над тобой издеваются Нет бы пояснить
Давай я тебе, как полный ламер в этом вопросе, поясню. За неточности не отвечаю

Ты написал объект и он работает в middletier звене каком-то. А другой кто-то (может, MS, а может Вася) написал...хм...как называется-то? аспект? — и теперь есть возможность применения на административном уровне к твоему объекту некоторой функциональности. Админ это может настроить.

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

COM+ короче.

Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.

>Недостаток этого метода — прога стартует слишком медленно.

Для этого есть ngen и кеш нативных имаджей (кажется есть).

M.NET>Никак Просто NGen был упомянут в противопоставление того, что С++ компилирует программы.

Кстати, об NGen. Как я понял, при работе ngen генерится нативный код, но исходный IL не выкидывается. А почему??? Отпала бы нужда во всяких обфускаторах и других подобных извращениях?

Может, дело в обеспечении целостности сборки, контролируемой цифровой подписью?

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

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

Тут народ в дебри ушел технические


Для меня это:
1. Красивый и лаконичный язык. Классический пример с копированием элементов массива это показывает
2. Язык с шаблонами. Насколько я знаю, их боьлше нет нигде. (Если не прав — поправьте)
3. Универсальное средство для решения почти любых задач. Об этом уже писали.
4. Стандартный язык для выражения идей. Примеры в книгах по проектированию и прочим теоретическим вещам как правило приводятся на С/С++

Вот, ИМХО...

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

S>13. За программирование на С++ мне платят деньги.

Остальные аргумены здесь были явно лишними.

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

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

IT>И .net врядли будет панацеей.

Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем.

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

M.NET>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

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

Ты попробуй скомпилировать одну версию для Первого пня, Третьего пня, Атлона и Пня четвертого. Я уже не говорю о разных 64-битных приблудах. Ну, а Интел тут вообще в данном случае не пременим будет. Технологии с джит-компиляциией это позволяют. Жаль что пока что только теоритически. Но MS и Sun-у нужно зарабатывать на жизнь, так что в следующих версиях все это точно воплатится в жизнь.

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

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

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

PS

Ну, и на счет супер скорости Интеловского компилятора. В основном это плод некорректного сравнения. Самая мощьная оптимизация доступная современным компиляторам — это банальный автоматический инлайнинг функций. Так вот у интела опция -O3 врубает эту фичу. У MS же ее нужно включать отдельно (опцией -Ob2). Так вот большинство тестов где Инетел впереди планеты всей не включали -Ob2 для компиляторов от MS. Интел безспорно хороший оптимизирущий компилятор. Но ДИКО медленный и все же не дающий реальных приимуществ на обыйденных алгоритмах. Ну, а когда его используют для получения кода совместимого с P1, то рекордов там точно не добьешся.

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

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

>>Недостаток этого метода — прога стартует слишком медленно.

IT>Для этого есть ngen и кеш нативных имаджей (кажется есть).

Ага. В бете было даже ощютимое ускорение. Жаль тольк к релизу оно исчезло.

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

S>А на кой нужна эта самая генерация классов в рантайме, если не секрет? Что-то ни одной задачи соответствующей не попадалось.

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

S>А C# под *nix вообще нет. И будет ли, не понятно.

Уже месяца два как есть. Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

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

S>

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

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

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

Вот из-за этой гибкости обычные люди и избегают Линуксы. Ну, и еще эта гибкость приводит к тому что появляются разные COM-ы и CORBA-ы. Мегабайты кода в которых закрывают отсталость языка и пытаются приклеить к нему компонентно-ориентированные посылы.

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

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

IT>>И .net врядли будет панацеей.

VD>Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем.

Я говорю, что

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

и говорю, что мне кажется, что проблемы "языковых войн" до конца .net не решит, потому что сам язык приходится менять (см. MC++, VB/NET, Delphi.NET) чтобы он годился в .NET. Хотя, могу ошибаться.

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

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

1. На нём пишут много людей. А значит не я один такой, кому этот язык нравится.
2. На нём пишут много умных людей, т.е. есть с кем посоветоваться.
3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
5. Объектная ориентированность.
6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.
8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.
9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

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

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

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

Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

E>8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.

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

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

S>>А на кой нужна эта самая генерация классов в рантайме, если не секрет? Что-то ни одной задачи соответствующей не попадалось.

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

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

S>>А C# под *nix вообще нет. И будет ли, не понятно.

VD>Уже месяца два как есть. :) Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

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

S>>

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

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

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

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

VD>Вот из-за этой гибкости обычные люди и избегают Линуксы. :( Ну, и еще эта гибкость приводит к тому что появляются разные COM-ы и CORBA-ы. Мегабайты кода в которых закрывают отсталость языка и пытаются приклеить к нему компонентно-ориентированные посылы.

Как раз философский разговор пошел... Лично меня от компонентного подхода воротит. Но это уже тема для другого топика. Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...
Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

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

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

Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора. И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

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

IT>Ты написал объект и он работает в middletier звене каком-то. А другой кто-то (может, MS, а может Вася) написал...хм...как называется-то? аспект? — и теперь есть возможность применения на административном уровне к твоему объекту некоторой функциональности. Админ это может настроить.

На самом деле не админ, а программер. Создаём аспект, говорим в нём, что если кто-то, например, вызвал метод с такой сигнатурой, то надо выполнить такой-то код. Или, куда интереснее, если произошло исключение в таких-то методах, то выполнить то-то и то-то. То бишь — один чел пишет прогу не думая об обработке исключений, security и пр. А другие пишут к его коду соответствующие аспекты.

IT>COM+ короче.
COM+ поддерживает только зачатки аспектной ориентации.

IT>Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.
Ну-ка ткни пальцем где такое написано, я это уже давно ищу — не знал что в .NET это есть.