AndreiF wrote:
> C>Я вот заявляю, что Оффис без VB в принципе не написать. Иначе как на нем
> C>макросы писать?
> Ну во первых, не VB, а VBA — это очень разные вещи.
Мне это можно не говорить, я в свой проект встраивал VBA из VBA SDK.

> Во вторых, интерпретатор VBA — это одна из составных частей офиса,
> написанная тем же производителем что и офис.
Ты утверждаешь, что оффис невозможен без VBA в принципе?

> Так что ты доказать то хотел?
Это я про невозможность Q4 без скриптов.

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

IT>>Попробуй записать на C++ что-нибудь в порт под виндой, а я посмотрю

N>Запускаю драйвер GiveIO.sys и пишу (inp, outp). Более того, мы даже на C++/CLI это делали

Вот! Что и требовалось доказать.

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

IT>Вот! Что и требовалось доказать.

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

internal static unsafe int modopt(CallConvThiscall) InteropHelper.UnmanagedHardwareAccessor.InPort(UnmanagedHardwareAccessor* modopt(IsConst) modopt(IsConst), ushort portAddress)
{
     int num1 = _inp(portAddress);
     return (int modopt(CallConvThiscall)) num1;
}

А inp декларируется как:

[MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity, DllImport("", EntryPoint="", CallingConvention=CallingConvention.Cdecl, SetLastError=true)]
public static extern int modopt(CallConvCdecl) _inp(ushort);

P.S. Не хочу, чтобы это воспринималось как защита дотнета, у меня после нескольких лет работы с ним он не вызывает других эмоций, кроме отрицательных, впрочем как и другие поделки от мелкомягких типа MFC и ATL, но выбора особого нет, серебряной пули нет

VD>Попробуй, например, с его помощью прочитать что-то из внешнего файла.

Попробуй с его помощью разобрать SQL-запрос в виде строки и добавить в класс поля,
соответствующие его колонкам.

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

J>С++ вполне соответствовал состоянию индустрии на момент его создания.
J>Тогда позарез нужен был язык с ООП.

А чем не устроила, скажем, ADA? Она к моменту выхода обладала интересными фичами, например, generics. Ну уж точно мощнее C++ образца 80-х.

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

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

J>>С++ вполне соответствовал состоянию индустрии на момент его создания.
J>>Тогда позарез нужен был язык с ООП.

K>А чем не устроила, скажем, ADA? Она к моменту выхода обладала интересными фичами, например, generics. Ну уж точно мощнее C++ образца 80-х.

Ну если верить этой странице (http://en.wikipedia.org/wiki/Timeline_of_programming_languages), то Ада и С++ — ровесники: 1983 год.

А вот на этой странице (http://en.wikipedia.org/wiki/Ada_programming_language) вот что написано:

Ada 95 added support for object-oriented programming, including dynamic dispatch.

С++ был объектно-ориентированным с самого начала,
а в 95-м году в нем уже было практически все, что мы имеем в нем сейчас (у меня издание ARM как раз 95-го года и там есть тогдашние ANSI/ISO resolutions с новыми кастами, пространствами имен и т.п.) и язык двигался полным ходом к стандартизации, которая произошла в 98-м, включив в С++ STL (кстати, если кто не знает, STL изначально разрабатывалась для Ады, причем начал он работать над STL, когда С++ еще и в помине не существовало).

You will always get what you always got
  If you always do  what you always did

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

C>Мне это можно не говорить, я в свой проект встраивал VBA из VBA SDK.

Тогда удивительно, что ты их путаешь.

C>Ты утверждаешь, что оффис невозможен без VBA в принципе?

Скрипты в офисе — для пользователя, а не для программистов офиса. А скрипты в играх — для программистов игр.

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

АХ>И некоторые уже так и делают — вот например в небезызвестной игре Second Life для скриптов потихоньку пытаются встроить рантайм Mono:здесь.

Кстати говоря, беглая проверка показала наличие dotnetfx.exe в дистрибутивах целого ряда новых игр — Titan Quest, Half-Life 2 Episode One, Flatout 2. Неясно правда, в каких объемах там используется .NET.

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

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

И усилению самомнения программиста, который продравшись через горы проблем и заморочек, добирается наконец до решения задачи
Никакой другой язык не дает такого удовлетворения — там слишком просто всё делается

AndreiF wrote:
> C>Мне это можно не говорить, я в свой проект встраивал VBA из VBA SDK.
> Тогда удивительно, что ты их путаешь.
Не путаю. Просто привык называет его просто VB.

> C>Ты утверждаешь, что оффис невозможен без VBA в принципе?
> Скрипты в офисе — для пользователя, а не для программистов офиса. А
> скрипты в играх — для программистов игр.
В Doom скриптов, например, не было. И что?

Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и
шейдеры или текстуры.

AndreiF wrote:
> Кстати говоря, беглая проверка показала наличие dotnetfx.exe в
> дистрибутивах целого ряда новых игр — Titan Quest, Half-Life 2 Episode
> One, Flatout 2. Неясно правда, в каких объемах там используется .NET.
Скорее всего, для сопутствующих утиллит. Так как тот же HL2 будет
портирован на PS3.

Depends не показавает зависимостей в HL2E1 от .NET, во время работы игры
— тоже не обнаружено.

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

C>В Doom скриптов, например, не было. И что?

А то, что Doom 1 — это далеко не Quake 4

C>Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и
C>шейдеры или текстуры.

Что значит "просто входные данные"?

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

J>Скажем (может, сейчас Сергей Губанов подтянется), почему следующая версия Паскаля называлась Object Pascal, а не Meta Pascal?

Я не Сергей, но вообще-то следующая версия паскаля называлась Modula.

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

VD>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет. Стандартные библиотеки должны быть переносимы, в противном случае это не кроссплатформенность а геморрой с бантиком. Так что претензия ИМХО мимо кассы...

VD>А в Моно есть поддержка GTK.
GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...

VD>Ребяты (с) Моно прекрасно переносим. Есть только две беды. Первая — моно значительно уступает дотнету в некоторых аспектах. Так он медленее, имеет больше багов, имеет меньше библиотек (например, того же WPF).
VD>Однако это никак не мешает переносимости программ если они изначально создавались в рассчете на запуск под Моно.
Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое? Если отдельное то при чем тут вообще Моно к портируемости .NET? То, что моно переносим — отдельная песТня. Речь изначально шла исключительно про кроссплатформенность .NET

VD>Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности.
Т.е. все утверждения что гипотетическая кроссплатформенность .NET это ее бааальшой плюс можно сразу отправлять в void, уже по причине полной ненужности этой самой кроссплатформенности.

VD>Собственно точно так же дела обстоят и с С++. С++ от МС отличается от стандарта С++ и от других его реализаций. И если писать программы только в рассчете на С++, то непереносимая прграмма получается сама сабой в автоматическом режиме.
Более правильным было бы сказать "только в рассчете на один из компиляторов С++, то непереносимая прграмма получается сама сабой в автоматическом режиме".
Реализация VM для дотнета только одна. Компилеров С++ же много, они бинарно несовместимы в большинстве своем. Пиши под один GCC на все нужные тебе платформы и будет тебе щасте!

VD>И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее.
Гм. x86, PS2, XBOX — наше двигло вроде нормально на них работало, Один код, только разделение по hardware dependent уровню и все.

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

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

FR>>Так BrainFuck очень простой язык.

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

VD>Все это разные вещи. И все это можно понимать под простатой.
VD>Брэйнфак прост синтаксически и семантически, но не интуитивен и не понятен.

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

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

АХ>Хм, MS так не думает.
Открою тебе страшную тайну: микрософт думает только о том, как продать свои творения и подсадить на них еще больше народу.

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

FR>А лисп и форт системы не чистые?

А вот пускай лисперы и фортисты это и расскажут. Я за них их работу делать не буду.

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

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

J>>Скажем (может, сейчас Сергей Губанов подтянется), почему следующая версия Паскаля называлась Object Pascal, а не Meta Pascal?

К>Я не Сергей, но вообще-то следующая версия паскаля называлась Modula.

Модула — это не новая версия Паскаля, это отдельный язык, как и Оберон (равно как и С++ — это не следующая версия С, а java — это не следующая версия С++).

Например, цитата из википедии (из статьи про Паскаль):

Pascal is based on the ALGOL programming language and named in honor of mathematician and philosopher Blaise Pascal. Wirth subsequently developed Modula-2 and Oberon, languages similar to Pascal.

(из статьи про модулу):

Modula-2 is a general purpose procedural language, sufficiently flexible to do systems programming, but with much broader application. In particular, it was designed to support separate compilation and data abstraction in a straightforward way. Much of the syntax is based on Wirth's earlier and better-known language, Pascal. Modula-2 was designed to be broadly similar to Pascal, with some elements removed and the important addition of the module concept, and direct language support for multiprogramming.

You will always get what you always got
  If you always do  what you always did

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

E>>Понятие "рулили" очень абстрактное. То, что большинство программистов в то время выполняли свою работу не на Lisp-е вовсе не означает, что на лиспе вообще не делалось важных и ответственных проектов. Думаю, что таки делались и метапрограммирование при этом использовалось на полную катушку.

J>Тогда понятие "бронзовый век" тоже очень абстрактное
J>Потому что наверняка кто-нть где-ть открыл возможность работы с железом.

Оно не абстрактное, зато точных дат начала и окончания бронзового века нет -- только приблизительные (с очень высокой дельтой )

J>С++ вполне соответствовал состоянию индустрии на момент его создания.

Вот в этом и вся суть!
C++ возник в ответ на нужды конца семидесятых, начала восьмидесятых годов. И унаследованные оттуда черты лежат в основе этого языка, не выдрать их оттуда и новые не вставить. И еще хорошо, что язык развивался, обрастал новыми возможностями.

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

J>Это сейчас все во всех областях приложения программирования рванули в сторону функциональных языков и метапрограммирования.

Да ладно тебе! Это здесь, на RSDN такой мощный поток диферамбов в сторону функциональщины и метапрограммирования, а в "обычной жизни" все по другому. Например, вокруг меня люди заняты обычной работой с использованием самой обычной Java и самого обычного C++. И в этой работе, по большому счету, на фиг не упало ни ФП ни МП -- понятные задачи, готовые инструменты -- бери и делай. Сложности вовсе не в технологиях, а в заказчиках

А высокий уровень интереса (и, соответственно, шума) на RSDN вокруг ФП и МП обуславливается тем, что пишут сюда, как мне кажется, весьма деятельные программисты/студенты/аспиранты, которые легко осваивают материал и стремяться к изучению нового. Ну не достаточно нам обычной, повседневной работы по клепанию EJB компонентов или очередного C++сового агента -- хочется чего-нибудь нового, экзотического, чтобы кровь разогнать. Вот и обсуждают ФП и МП снова и снова, как и остальные серебрянные пули.

J>А было "Дайте нам язык с поддержкой ООП, но чтоб он не тормозил, как Смолтолк, а работал со скоростью Си".

Мне кажется, даже этого не было. Было так. Страуструп думал: "Хочется мне языка с поддержкой ООП, но чтобы он работал со скоростью Си и не жрал столько памяти как ALGOL, и чтобы системным программированием на нем было приятнее заниматься, чем на C". Может так и еще кто-то думал, но у Страуструпа это получилось воплотить в C++. А затем его творением воспользовались те, кто нуждался в подобном инструменте.

J>Раз, как вы утверждаете, был большой запрос на это дело со стороны индустрии и это считалось "базовой вещью"?

J>Неужели я так криво пишу, что меня вообще невозможно понять?

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

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

CC>Здравствуйте, VladD2, Вы писали:
VD>>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
CC>Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет. Стандартные библиотеки должны быть переносимы, в противном случае это не кроссплатформенность а геморрой с бантиком. Так что претензия ИМХО мимо кассы...

WinForms в такой же степени стандартная библиотека для CLI, в какой MFC — стандартная библиотека C++.

CLI кроссплатформенна в рамках стандарта ECMA 335 и ISO/IEC 23271
.NET и Mono реализации CLI.

Есть для C++ стандартная GUI-библиотека? Нет. Ну так о чем разговор тогда?