Надеюсь, что не развяжу очередной карибский кризис.
Попалась мне статья в "Открытых Системах": интервью с Бьярном Страуструпом.

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

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

К>Надеюсь, что не развяжу очередной карибский кризис.
К>Попалась мне статья в "Открытых Системах": интервью с Бьярном Страуструпом.

К>

К>Вывод, к которому я пришел (году приблизительно в 1980-м или около того), можно сформулировать так: всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо, обеспечивая близкое к оптимальному время выполнения и распределение памяти.

Тогда расскажи как С++ поддерживает парадигмы:

Компонентного программирования.
Атрибутного (декларативного) программирования.
Ну и аспектно ориентированного программирования.

В общем устарел этот самы С++, а менять его очень не хотят.

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

К>Надеюсь, что не развяжу очередной карибский кризис.

...но танки подкатим. Тут вон внимание международной общественности отвлечено на COM/DCOM/COM+

К>Попалась мне статья в "Открытых Системах": интервью с Бьярном Страуструпом.

К>

К>Вывод, к которому я пришел (году приблизительно в 1980-м или около того), можно сформулировать так: всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо, обеспечивая близкое к оптимальному время выполнения и распределение памяти.

Всё правильно, C++ — язык для решения проблем. То есть — сугубо практический инструмент для решения практических задач, которые подчас приходится решать эклектичными с точки зрения "теории" способами. В то же время, он позволяет реализовать и вполне себе "чистый" подход к разработке софта для любителей той или иной парадигмы. Ну так на то он и "язык общего назначения"! Кстати, потому он и "рулить" будет ещё очень-очень долго.

Ну а про то, что с ним в угоду манагёрам и маркетологам делают — сам знаешь...

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

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

[...]

VD>Тогда расскажи как С++ поддерживает парадигмы:

А давай-ка ты дашь внятное определение представленным парадигмам (в крайнем случае подойдут отсылки к первоисточникам, но так, чтобы там было написано: "Парадигма такая-то: Определение. ..." или "Программирование такое-то, это..."). Вот тогда и рассмотрим.

VD>Компонентного программирования.
VD>Атрибутного (декларативного) программирования.
VD>Ну и аспектно ориентированного программирования.

VD>В общем устарел этот самы С++, а менять его очень не хотят.

Батарея, товсь!!! Его не менять надо, а пользоваться научиться и за пулями серебряными бегать перестать.

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

К>Надеюсь, что не развяжу очередной карибский кризис.

Я вот вообще нашел цитату
Inside C# / Tom Archer, 2nd ed

Therefore, the majority of programmers simply accept the fact that they have two categories of types and that the intrinsic types aren’t compatible—and they learn to live with that. By the way, this is why most scholars will tell you that C++ isn’t an object-oriented language but instead is an object-based language

.

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

К>>Надеюсь, что не развяжу очередной карибский кризис.
К>>Попалась мне статья в "Открытых Системах": интервью с Бьярном Страуструпом.

К>>

К>>Вывод, к которому я пришел (году приблизительно в 1980-м или около того), можно сформулировать так: всякий язык программирования общего назначения обязан поддерживать сразу множество парадигм, и каждая парадигма должна быть реализована хорошо, обеспечивая близкое к оптимальному время выполнения и распределение памяти.

VD>Тогда расскажи как С++ поддерживает парадигмы:

VD>Компонентного программирования.

Он ему не мешает, по крайней мере.

VD>Атрибутного (декларативного) программирования.

Это как? Признавайся, ты сам придумал новую парадигму, и никому не говоришь? Это, IMHO, не парадигма, а так, техника программирования. По крайней мере, гугл на запрос "Attribute programming" paradigm выдает 3 ссылки, и все не про то.

VD>Ну и аспектно ориентированного программирования.

Во, Александреску как раз про ето на OOPSLA 4 ноября лекцию читал. Че он там прочитал, я не знаю, но в аннотации написано — "This tutorial presents the weaving approach in C++, discusses some drawbacks of weaving and then presents in-depth the use of policy classes to implement cross-cutting concerns in an AOP way."

VD>В общем устарел этот самы С++, а менять его очень не хотят.

Гы Лучше то все равно пока ничего не придумали.

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

VD>>Компонентного программирования.

S>Он ему не мешает, по крайней мере.

Еще как мешает. КОМ (единственная выжившая компонентная модель на С++) сложна и запутана при реализации на С++.

VD>>Атрибутного (декларативного) программирования.

S>Это как? Признавайся, ты сам придумал новую парадигму, и никому не говоришь? Это, IMHO, не парадигма, а так, техника программирования. По крайней мере, гугл на запрос "Attribute programming" paradigm выдает 3 ссылки, и все не про то.

ПАРАДИГМА, -ы, ж. 1. Образец, тип, модель (книжн.).

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

VD>>В общем устарел этот самы С++, а менять его очень не хотят.

S>Гы Лучше то все равно пока ничего не придумали.

Ага. Именно по этому ищут изо всех сил ему замену. Т.е. все эти Шарпы, Явы и т.п. просто так появились.

Можно долго и нудно уговаривать и себя и других что С++ кул форева, но это уже давно не так. Его давно пора реформировать. К сожалению этого скорее всего не произойдет. Или произойдет, но поздно.

Когда в Шарпе и Яве появятся шаблоны, (а это уже точно произойдет) и когда оптимизация в нет несколько улучшится, падет последний фиговый листок этого, без сомнения, заслуженного языка.

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

ГВ>А давай-ка ты дашь внятное определение представленным парадигмам (в крайнем случае подойдут отсылки к первоисточникам, но так, чтобы там было написано: "Парадигма такая-то: Определение. ..." или "Программирование такое-то, это..."). Вот тогда и рассмотрим.

ГВ>Батарея, товсь!!! Его не менять надо, а пользоваться научиться и за пулями серебряными бегать перестать.

Куда нам лаптям... это ж для особо "крутых".

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

ГВ>>Батарея, товсь!!! Его не менять надо, а пользоваться научиться и за пулями серебряными бегать перестать.

VD>Куда нам лаптям... это ж для особо "крутых".

Допустим. И всё-таки, будь добр, ответь по существу. Напоминаю вопрос:

А давай-ка ты дашь внятное определение представленным парадигмам (в крайнем случае подойдут отсылки к первоисточникам, но так, чтобы там было написано: "Парадигма такая-то: Определение. ..." или "Программирование такое-то, это..."). Вот тогда и рассмотрим.

VD>Компонентного программирования.
VD>Атрибутного (декларативного) программирования.
VD>Ну и аспектно ориентированного программирования.

Как вариант ответа подойдут высказывания "Не знаю", "Чёткого определения нет, но это примерно...". Определение желательно давать, используя существительные (а не глаголы).

Извини, но ответ, данный в соседней ветке трудно считать определением какого-либо "образца, типа, модели":

ПАРАДИГМА, -ы, ж. 1. Образец, тип, модель (книжн.).

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

Эти два абзаца попросту никак не связаны друг с другом. Второй уместен для пояснения чего-либо, но вот чего?

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

VD>Еще как мешает. КОМ (единственная выжившая компонентная модель на С++) сложна и запутана при реализации на С++.

VD>>>Атрибутного (декларативного) программирования.

S>>Это как? Признавайся, ты сам придумал новую парадигму, и никому не говоришь? Это, IMHO, не парадигма, а так, техника программирования. По крайней мере, гугл на запрос "Attribute programming" paradigm выдает 3 ссылки, и все не про то.

VD>ПАРАДИГМА, -ы, ж. 1. Образец, тип, модель (книжн.).

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

В С++ это называется множественное наследование.

VD>>>В общем устарел этот самы С++, а менять его очень не хотят.

S>>Гы Лучше то все равно пока ничего не придумали.

VD>Ага. Именно по этому ищут изо всех сил ему замену. Т.е. все эти Шарпы, Явы и т.п. просто так появились.

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

VD>Можно долго и нудно уговаривать и себя и других что С++ кул форева, но это уже давно не так. Его давно пора реформировать. К сожалению этого скорее всего не произойдет. Или произойдет, но поздно.

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

Там, кроме шаблонов, дофига всего другого не хватает.

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

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

S>В С++ это называется множественное наследование.

А ну да. А я тгда Карлсон.

S>Не просто так. Появились они в силу объективных причин, но, к сожалению, в некоторых отношениях являются шагом назад по сравнению с С++.

Вот если бы С++ развивался, то и замену ему искать не пришлось бы.

S>Там, кроме шаблонов, дофига всего другого не хватает.

Например? Множественное наследование спокойно на шаблонах обходится. Больше я ничего не заметил.

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

ГВ>Допустим. И всё-таки, будь добр, ответь по существу. Напоминаю вопрос:

ГВ>

ГВ>А давай-ка ты дашь внятное определение представленным парадигмам (в крайнем случае подойдут отсылки к первоисточникам, но так, чтобы там было написано: "Парадигма такая-то: Определение. ..." или "Программирование такое-то, это..."). Вот тогда и рассмотрим.

VD>>Компонентного программирования.
VD>>Атрибутного (декларативного) программирования.
VD>>Ну и аспектно ориентированного программирования.

Я что толковый словарь?

Ну могу попробывать, но за качество не отвечаю...

Компонентного программирования — программирование основанное на компонентах, т.е. сборка ПО из готовых блоков. Нечто вроде сборки помпьютеров из комплектующих, но для ПО.

Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:

[MyAtrybut(MyValue)]
void MyMethod(){}

Ну и аспектно ориентированного программирования. Ну это к Мишке.EJB Он много про него в форумах писал.

ГВ>Как вариант ответа подойдут высказывания "Не знаю", "Чёткого определения нет, но это примерно...". Определение желательно давать, используя существительные (а не глаголы).

Слушай! Тебе надо, ты и ищи эти определения. Мне не надо...

ГВ>Эти два абзаца попросту никак не связаны друг с другом. Второй уместен для пояснения чего-либо, но вот чего?

Ты чего от меня хочешь? Что бы я тебе дал энцеклопедические определения понятий которым книги посвещают?

Давай местами поменяемся? Дай вот определение термину программирования ну или еще какому нибудь.

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

VD>Я что толковый словарь?

А шо, бестолковый?

VD>Ну могу попробывать, но за качество не отвечаю...

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

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

VD>Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов.

Типа того.

VD>Ну и аспектно ориентированного программирования. Ну это к Мишке.EJB Он много про него в форумах писал.

Этот термин ещё толком не сформулировался. Основная идея заключается в отделении мух от котлет. Если алгоритм занимается вычислением логарифма, то ему желательно ничего не знать о транзакциях, модели синхронизации и/или обработки исключений. К тому же эти операции как правило повторяются от раза к разу в различных алгоритмах. Аспектный подход позволяет отделить подобные служебные функции и выделить их в отдельный класс задач. Одним из способов реализации AOP являются атрибуты. К тому же в .NET существует механизм создания классов, все публичные методы которых будут перехватываться специальными обработчиками, которые могут выполнять определённые служебные функции.

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

VD>Когда в Шарпе и Яве появятся шаблоны, (а это уже точно произойдет) и когда оптимизация в нет несколько улучшится,

И когда у большинства пользователей будет стоять операционная система со встроенным фреймворком. Раньше ничего не выйдет.

VD>падет последний фиговый листок этого, без сомнения, заслуженного языка.

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

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

S>>В С++ это называется множественное наследование.

VD>А ну да. А я тгда Карлсон.

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

S>>Не просто так. Появились они в силу объективных причин, но, к сожалению, в некоторых отношениях являются шагом назад по сравнению с С++.

VD>Вот если бы С++ развивался, то и замену ему искать не пришлось бы.

Ну давай теперь флеймить на тему, является ли Java заменой C++ или дополнением и зачем MS выпустила .Net Сразу скажу, я не считаю, что причинами появления Java и .Net является несовершенство С++. Другие были причины, совсем другие.

S>>Там, кроме шаблонов, дофига всего другого не хватает.

VD>Например? Множественное наследование спокойно на шаблонах обходится. Больше я ничего не заметил.

Ключевое слово — обходится. На ассемблере вообще все обходится, только вот не человеческое это дело, на ассемблере большие программы писать... Кстати, покажи, как именно обходится — че то в удобство такого метода не очень верится.
А не хватает, например, нормальных деструкторов, argument-dependent name lookup, директивы using внутри функций — эти козлы ничего умнее, чем считать ее там за using statement не придумали. Что стоило для using statement другой синтаксис придумать? Привязки параметров в делегатах не хватает, причем, в отличие от C++, руками ее не напишешь. Возможности написать ручной распределитель памяти для конкретного класса не хватает. Наледования для структур. Внутренней непротиворечивости, в конце концов, не хватает — взять хотя бы исключения в деструкторах или в finally. В общем, чем дальше в лес, тем чудесатее и чудесатее. Сырой язык.

Да, и что из шаблонных фич будет в С#? Неужто class template partial specialization и partial ordering of function templates собираются поддерживать? С ними шаблоны — мощное средство кодогенерации, позволяющее писать программы (только рекурсивные правда), выполняемые компилятором, без них — всего лишь типизированные макросы

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

S>Чтоб не флеймить зря, покажи, как на C# реализуется эта самая парадигма — тогда можно будет предметно обсудить, чего в С++ не хватает.

Вот пример из соседнего формума:

[assembly: Guid("49E484AE-02C4-4c77-A36E-7B4ED0BCE11F")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationID("49E484AE-02C4-4c77-FFFF-7B4ED0BCE11F")]
[assembly: AssemblyDescription("Test AssemblyDescription")]
[assembly: ApplicationName("TestNetComPlusServer")]
// Обратите внимание на то, что версия сборки задана явно!
// Т.е. без использования знака *. Это позволяет отучить VS
// излишне беспокоиться о "правильности" версии сборки. 
// И тем самым снять проблему постоянной перерегистрации
// COM+-приложения, COM+-прокси и перекомпиляции клиента.
[assembly: AssemblyVersion("1.1.100.200")]
[assembly: AssemblyDelaySign(false)]
// Строгое имя (а именно так лучше переводить "strong name") 
// нужно создать утилитой Sn.exe
[assembly: AssemblyKeyFile("..\\..\\TestNetComPlusServer.snk")]
[assembly: AssemblyKeyName("")]


using System;
using System.EnterpriseServices;
using System.Runtime.InteropServices;

namespace TestNetComPlusServer
{

    [GuidAttribute("FBEAA7C9-06D2-40a3-A3B7-ABC769DDA589")]
    // Ип интерфейса: Dual, IDispatch или IUnknown
    [InterfaceType(ComInterfaceType.InterfaceIsDual)]
    public interface IServer
    {
        void Method1();
    };

    
    // Переключает галочку "Component supports e&vents and statistics",
    // тем самым позволяя следить за активностью компонента в Component Services
    [EventTrackingEnabledAttribute(true)]
    // CLSID. Сногие думают что так задается IID дефолтного интрфейса, но это не так.
    [Guid("676C8C4F-7178-4023-863F-BC13658B8688")]
    [ClassInterface(ClassInterfaceType.None)]
    // Тут же можно задать кучу дургих атрибутов.
    //[Transaction(TransactionOption.Disabled)]
    public class Server: System.EnterpriseServices.ServicedComponent, IServer
    {
        public Server(){}

        // Лдя методов тоже можно задавать атрибуты.
        //[AutoComplete]
        void IServer.Method1()
        {
            // Метод ком объекта.
            int i = 0;
            i = i;
        }
    }
}

Это COM+-объект созданный на C#. Без применения атрибутов мне прилось бы создать отдельный idl-файл с описанием интерфейсов, ко-классов и библиотеки типов. Это — раз. Ну и при регистрации пришлось бы задать все параметры вручную или написать нехилый скрипт для их задания. Тут же я обхожусь заданием атрибутов.

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

VD>>Вот если бы С++ развивался, то и замену ему искать не пришлось бы.

S>Ну давай теперь флеймить на тему, является ли Java заменой C++ или дополнением и зачем MS выпустила .Net Сразу скажу, я не считаю, что причинами появления Java и .Net является несовершенство С++. Другие были причины, совсем другие.

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

VD>>Например? Множественное наследование спокойно на шаблонах обходится. Больше я ничего не заметил.

S>Ключевое слово — обходится. На ассемблере вообще все обходится, только вот не человеческое это дело, на ассемблере большие программы писать... Кстати, покажи, как именно обходится — че то в удобство такого метода не очень верится.

И причем тут ассемблер? Демогогия одно слово. Множественное наследование хорошо только для одного дела — подключение готовых реализаций. В остальном от него только одни проблемы. Я согласен, что ATL демонстрирует эффективность этго подхода. Но ведь для подключения реализаций можно пользоваться и более простыми методами. Мне, например, кажется что введение в язык агрегации (подключения внешних классов в качестве реализации интерфейсов) было решило бы эту проблему. Ну да об этом мы уже много дискутировали.

В С++ главная проблема — это непомерная сложность. Да на нем можно все. Но какй цено! В .NET же я могу писть основной костяк программы на простом и удобном языке, а когда нужно использовать С++. Правд практика показывает, что обычно это использование ограничивается созданием оберток над разыми нэйтив-АПИ.

S>А не хватает, например, нормальных деструкторов,

Мне в первое время тоже не хватало. Но во времением понимаешь, что это вобщем-то просто привычка. Хотя для вэлью-типов можно было бы добавить.

S>argument-dependent name lookup,

Это я вообще не понял, что такое?

S> директивы using внутри функций

Никогда не испытывал необходимости. И не помню чтобы такое было в С++. Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.

S> — эти козлы ничего умнее, чем считать ее там за using statement не придумали.

using — это как раз замена тем самым деструкторам. Блок контролирующий освобождение ресурсов.

S>Что стоило для using statement другой синтаксис придумать?

Я сперва тоже юсинг за виз принял. Но потом быстро привык.

S>Привязки параметров в делегатах не хватает, причем, в отличие от C++, руками ее не напишешь.

Опять же не понял о чем идет речь? Уж делегаты то в нэте куда лучше уродливых указателей на методы класса в С++. Локанично и эффективно.

S>Возможности написать ручной распределитель памяти для конкретного класса не хватает.

Опять же на С++ это обхдится. Да и на Шарпе в ансэйф-режиме тоже. Но практика показывает, что в этом просто нет нужды.

S>Наледования для структур.

Ну, это я не знаю зачем они сделали, но опять же на практике не мешает.

S>Внутренней непротиворечивости, в конце концов, не хватает — взять хотя бы исключения в деструкторах или в finally.

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

S>В общем, чем дальше в лес, тем чудесатее и чудесатее. Сырой язык.

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

S>Да, и что из шаблонных фич будет в С#? Неужто class template partial specialization и partial ordering of function templates собираются поддерживать?

Я так понял шаблонным хотят сделать почти все. Но конкретно не разбирался. Ссно тольк одно они будут делать наиболее просто вариант. Просто в смысле простоты использования, а не реализации. Кстити вроде хотят избавиться от дублирования кода. На протатип можно посмотреть скачав хакнутый вариант CLI (здесь ftp://rsdn.ru/CLI/Generic/gyro20020823[1].tar.gz). Там есть примеры можешь посмотреть.

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

S>С ними шаблоны — мощное средство кодогенерации, позволяющее писать программы (только рекурсивные правда), выполняемые компилятором, без них — всего лишь типизированные макросы

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

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

Я вот для простоты распаковал примеры от шаблонного CLI:

ftp://rsdn.ru/CLI/Generic/Samles
ftp://rsdn.ru/CLI/Generic/Samles/generics.html — описания

Орати внимаене на забавные вещи типа параметризованных делегатов (они их называют протометоды) ftp://rsdn.ru/CLI/Generic/Samles/Memoization/Memoization.html

Вот это тоеж забавно ftp://rsdn.ru/CLI/Generic/Samles/Polynomial/Polynomial.html

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

A>И когда у большинства пользователей будет стоять операционная система со встроенным фреймворком. Раньше ничего не выйдет.

Рантай думаю проблемой не будет. Качают же новые версии IE и обнавления к нему размером в десякти, а то и сотни мегобайт...

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

IT>Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль.

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

IT>Этот термин ещё толком не сформулировался.

Да это мы с тобой не можем кратко сформулировать овновную идею.

IT>Основная идея заключается в отделении мух от котлет. Если алгоритм занимается вычислением логарифма, то ему желательно ничего не знать о транзакциях, модели синхронизации и/или обработки исключений. К тому же эти операции как правило повторяются от раза к разу в различных алгоритмах. Аспектный подход позволяет отделить подобные служебные функции и выделить их в отдельный класс задач. Одним из способов реализации AOP являются атрибуты. К тому же в .NET существует механизм создания классов, все публичные методы которых будут перехватываться специальными обработчиками, которые могут выполнять определённые служебные функции.

Дык речь то о С++. К сожалению всего этого похоже уже никогда не появится в С++.

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

А жаль.

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

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

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

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

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

A>...то это, во-первых, для многих достаточно важное приложение, в отличии от фреймворка

Вот тут то собачка и порылась. Как только людям нужно будет приложение на нэте сделаное, то тут же и скачают. Так что главное чтобы твое приложение было людям нужно.

A>во-вторых, качают далеко не все (зачем?),

Статистика показывает что большинство перешло на 6-й эксплорер. А он ни в одну ОСь не ваходит.

A>а в-третьих — далеко не каждый пользователь может произвести такую сложную операцию, как скачку многомега и ее последующую установку. Да и зачем? Все программы, которые нужны, работают и безо всякого фреймворка, а если они требуют какие-то длл, то значит они просто кривые... Так рассуждают многие... Нет, это серьезная проблема для массовых программ.

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

Возми тот же янус. Тебе придется скачать 20 мег + 1. Но зато потом проблемы с просмотром в офлайне того же рсдн-а не будет. Думаю что оно того стоит. Тем более что пользователь Януса сам программист и фреймворк у него скорее всего уже есть. Ну а пользователи пользователя возмут фреймоврк у пользователя.

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

A>>...то это, во-первых, для многих достаточно важное приложение, в отличии от фреймворка
VD>Вот тут то собачка и порылась. Как только людям нужно будет приложение на нэте сделаное, то тут же и скачают. Так что главное чтобы твое приложение было людям нужно.

Проблема в том, что они могут предпочесть менее гмм.. требовательное решение.

A>>во-вторых, качают далеко не все (зачем?),
VD>Статистика показывает что большинство перешло на 6-й эксплорер. А он ни в одну ОСь не ваходит.

Что за статистика такая? Мои шпионы говорят, что это не так .

A>>а в-третьих — далеко не каждый пользователь может произвести такую сложную операцию, как скачку многомега и ее последующую установку. Да и зачем? Все программы, которые нужны, работают и безо всякого фреймворка, а если они требуют какие-то длл, то значит они просто кривые... Так рассуждают многие... Нет, это серьезная проблема для массовых программ.

VD>Ну в общем ты сам к моим выводам пришел. Главное чтобы программа была нужна, а фрймворк дело десятое. 20 мег можно и по модему скачать.

Нет. Программа должна установиться и работать. Если она не работает, то ее снесут и поставят другую .

VD>Возми тот же янус. Тебе придется скачать 20 мег + 1. Но зато потом проблемы с просмотром в офлайне того же рсдн-а не будет. Думаю что оно того стоит.

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

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

Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится.

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

VD>Статистика показывает что большинство перешло на 6-й эксплорер. А он ни в одну ОСь не ваходит.

В ХР входит. Впрочем это дела не меняет, пользователей ХР заметно меньше чем тех у кого IE6.

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

A>Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой. Если говорить в общем — это изрядно сократит количество пользователей этой, вполне возможно, замечательной во всех других отношениях программы. Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения. Мне не понравилось и пришлось снести все это. К тому же .NET-приложения мне показались медленными и прожорливыми. Смена операционной системы неприемлима .

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

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

A>Проблема в том, что они могут предпочесть менее гмм.. требовательное решение.

Значит твое решение хреновое. Ведь рантайм тебе дает кардбланш. И если твое решение ничем не лучше чем аналогичное на обычном С++, значит ты валял дурака или взялся не за то.

A>Что за статистика такая? Мои шпионы говорят, что это не так .

На хотлоге.

A>Нет. Программа должна установиться и работать. Если она не работает, то ее снесут и поставят другую .

Дык другие еще писаться будут.

A>Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой.

Посмотрим. Пока что эта ошибка дала возможность обогнать конкурирующую (хе-хе) разработку на плюсах. Причем объем работ просто несравним.

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

Опять таки увидим.

A>Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения.

Значит криво установлена. Сам фрймворк не может оказывать влияния на внешние приложения.

A>Мне не понравилось и пришлось снести все это. К тому же .NET-приложения мне показались медленными и прожорливыми. Смена операционной системы неприемлима .

Интересно почему неприемлима? Ну а про меденность это наговоры. Правда про прожорливаость — чистая правда.

A>Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится.

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

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

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

Скорость — это, безусловно, плюс. Но перевешивает ли он минусы, которых немало?

A>>Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения.
VD>Значит криво установлена. Сам фрймворк не может оказывать влияния на внешние приложения.

Ты думаешь? На внешние приложения он, вполнне вероятно, оказывать влияния не может, но вот на систему оказывает и еще как .

A>>Смена операционной системы неприемлима .
VD>Интересно почему неприемлима?

i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.
ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.

A>>Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится.
VD>Думаю что после выхода релиза Януса (бжта выдет в бижайшее время) сам увидишь как народ будет качать фрймворк.

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

A>>>Смена операционной системы неприемлима .
VD>>Интересно почему неприемлима?

A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.
A>ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.

Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.

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

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

A>>>Смена операционной системы неприемлима .
VD>>Интересно почему неприемлима?
A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.

Бедняга! По секрету скажу, что дома у меня стоял Celeron 333(o/c 500) с 64МБ памяти! Когда поставил вместо Win98SE Win2k (без всяких сервиспаков, их просто ещё не было), то сразу поразился субъективно возросшей производительности и объективно повысившейся устойчивости!
И сколько после этого мне ни говорили про то, что мол, Win2k начинает шевелиться от 128МБ, я только улыбался в ответ!
В это самое время писался курсовик (веб-сайт) так вОт, одновременно у меня тогда работали Photoshop, DreamWeaver4, FrontPage и HomeSite. Естественно отдельно висели IE, WinCmd, но это Не надо издеваться по поводу такого изобилия средств -- дело не в этом. Дело в том, что меня вполне устраивало время отклика каждой из этих програм при переключении между ними.

Может что-нибудь в консерватории подправить?

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

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

IT>Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль.

Это уже другие компоненты.
Функционально законченный — это необходимо, но еще недостаточно.

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

ХД>В это самое время писался курсовик (веб-сайт) так вОт, одновременно у меня тогда работали Photoshop, DreamWeaver4, FrontPage и HomeSite. Естественно отдельно висели IE, WinCmd, но это Не надо издеваться по поводу такого изобилия средств -- дело не в этом. Дело в том, что меня вполне устраивало время отклика каждой из этих програм при переключении между ними.

В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого.

ХД>Может что-нибудь в консерватории подправить?

Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .

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

PSP>Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.

PSP>После второго сервис пака глюков конечно меньше стало. Несравнимо меньше. Но вижуал продолжает подглюкивать, хотя всё остальное вроде нормально работает.

Что за гнилые, блин, базары ?
Садись за Юникс или Линукс и ковыряйся в консоли, шоб не падоло ничего.
Или запусти для сравнения KDeveloper там же.

Здравствуйте, old->*Plutonia_Experiment(), Вы писали:

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

PSP>>Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.

PSP>>После второго сервис пака глюков конечно меньше стало. Несравнимо меньше. Но вижуал продолжает подглюкивать, хотя всё остальное вроде нормально работает.

OE>Что за гнилые, блин, базары ?
OE>Садись за Юникс или Линукс и ковыряйся в консоли, шоб не падоло ничего.
OE>Или запусти для сравнения KDeveloper там же.

Я принципиально против таких рассуждений. Если вижуал одинаковый и там и там, нахрен мне глюки иметь. А совместимость всё равно идёт снизу вверх, если я прилаги писать буду под NT4, то под 2k они тем более работать будут..

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

A>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .

Знаешь, утверждение что W2K на 384М памяти работает меленней 98 мягко говоря неверно.

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

VD>В общем устарел этот самы С++, а менять его очень не хотят.

Ну всем и так ясно, что не любишь ты C++.

Есть известный анекдот по этому поводу: "... ну не люблю я тебя мужик!..."

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

AVK>Знаешь, утверждение что W2K на 384М памяти работает меленней 98 мягко говоря неверно.

Полностью согласен. У меня до недавнего времени стоял PIII733/384 с 98 и 2K, 2K работал быстрее и надежнее но грузился немного медленней, а если учесть чо 98 падал от каждого чиха... После замены 2K, XP произошли резкие изменения XP грузился быстрее 98, а производительность (после вырубания понтов) выросла относительно 2K надежность тоже. После того как я обнаружил что все программы ради которых я держал 98 после небольших уговоров работают в XP... бедный 98. Плюс у XP есть система востановления после кривых прог и дровдва раза перезагрузился и работаешь дальше, а 2K про 98 я вобще молчу пришлось бы переустонавливать со всеми вытекающими.

ЗЫ на K6 500/128 XP быстрее 98.

2Aquila факты говоря что новые винды быстрее

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

WH>После замены 2K, XP произошли резкие изменения XP грузился быстрее 98, а производительность (после вырубания понтов) выросла относительно 2K надежность тоже. После того как я обнаружил что все программы ради которых я держал 98 после небольших уговоров работают в XP... бедный 98. Плюс у XP есть система востановления после кривых прог и дровдва раза перезагрузился и работаешь дальше, а 2K про 98 я вобще молчу пришлось бы переустонавливать со всеми вытекающими.
WH>ЗЫ на K6 500/128 XP быстрее 98.

Грузится, говоришь, быстрее? А я еще и программы запускаю.

Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения (В конце постинга). Если оппоненты согласны, то дальше будем дискутировать, опираясь на эти определения. Если нет, то попрошу аргументированно оспорить предложенные определения и предложить свои формулировки.

Компонентное программирование

VD> Компонентного программирования — программирование основанное на компонентах, т.е. сборка ПО из готовых блоков. Нечто вроде сборки компьютеров из комплектующих, но для ПО.
IT> Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль.
OE> Это уже другие компоненты.
OE> Функционально законченный — это необходимо, но еще недостаточно.
VD> В компонентах главное, что это отчуждаемые модули. Т.е. они должны быть самодостаточны и не требовать наличия исходного кода для своего использования.

OK, так или иначе, но определение компонента есть. ИМХО, не сказали только, что компонент без компонентной инфраструктуры – суть ноль без палочки.

Попробую пояснить свою мысль и сделать кое-какие выводы.

"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.

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

Модуль, который реализует требования, накладываемые инфраструктурой (а они неизбежно есть), называется компонентом, а сама инфраструктура — компонентной инфраструктурой.

Компонент, удовлетворяющий требованиям инфраструктуры, тем не менее может предъявлять определённые требования к другим компонентам, с которыми он взаимодействует. (Как это справедливо заметил old->*Plutonia_Experiment() )

Другой аспект — отчуждаемость компонента, т.е., компонент, в принципе, может быть помещён в любое окружение, отвечающее спецификации компонентной инфраструктуры. (Приблизительный “железячный”аналог – установка платы на исптытательный стенд).

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

Теперь о компонентно-ориентированном программировании (собственно, о нём, первоначально речь и была).

В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.

Атрибутное (декларативное) программирование

VD> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:


VD>

VD>[MyAtrybut(MyValue)]
VD>void MyMethod(){}
VD>

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

OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п. Атрибуты, вероятно, характеризуются именем, и типом значения. Кстати, о декларативном программировании – декларативное программирование подразумевает наличие какой-то системы, интерпретирующей декларации. SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.

Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".

Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.

Аспектно-ориентированное программирование

IT> Этот термин ещё толком не сформулировался. Основная идея заключается в отделении мух от котлет. Если алгоритм занимается вычислением логарифма, то ему желательно ничего не знать о транзакциях, модели синхронизации и/или обработки исключений. К тому же эти операции как правило повторяются от раза к разу в различных алгоритмах. Аспектный подход позволяет отделить подобные служебные функции и выделить их в отдельный класс задач. Одним из способов реализации AOP являются атрибуты. К тому же в .NET существует механизм создания классов, все публичные методы которых будут перехватываться специальными обработчиками, которые могут выполнять определённые служебные функции.

OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.

Вот ещё, интересный, на мой взгляд, фрагмент введения к документу "Declarative aspect-oriented programming", взятый с сайта:

Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality. To overcome that problem special languages are used to specify such properties---the so-called aspects---in isolation. The software application is obtained by weaving the aspect code and the implementation of properties corresponding to basic functionality---the so-called components. This paper investigates the suitability of functional meta-programs to specify aspects and to perform weaving. The proposal focuses on the declarative paradigm (logic programming, attribute grammars, natural semantics, constructive algebraic specification etc.) as far as components are concerned, whereas aspects are represented by program transformations. Weaving is regarded as a program composition returning a combination of the components satisfying all the aspects. The computational behaviour of the components is preserved during weaving. The proposal improves reusability of declarative programs. The approach is generic in the sense that it is applicable to several representatives of the declarative paradigm. Several roles of aspect code are defined and analysed.

AOP нацелено на проблему реализации таких свойств как обработка ошибок и оптимизация, пронизывающих основную функциональность [программы]. Для решения этой проблемы используются специальные языки, независимо определяющие эти свойства (так называемые — аспекты). Прикладная программа обрабатывается «сшиванием» [weaving] аспектного кода и реализаций указанных свойств в соответствии с базовой функциональностью (т.н. — компоненты). Настоящий документ исследует пригодность функционального метапрограммирования для специфицирования аспектов и выполнения «сшивания». Предложение фокусируется на декларативной парадигме (логическое программирование, атрибутные грамматики, естественные семантики, конструктивные алгебраические спецификации и т.п.) и компонентах, тогда как аспекты представлены трансформацией программы. «Сшивание» представляется композицией, являющейся комбинацией компонентов, удовлетворяющих всем аспектам. Вычислительное поведение компонента после «сшивания» сохраняется неизменным. Предложение повышает степень повторного использования декларативных программ. Подход, по сути является обобщённым, поскольку применим к разным представлениям [representatives] декларативной парадигмы. Определён и проанализирован ряд ролевых функций аспектного кода.

Значит, таким образом, цепочка замыкается – от AOP (цель) к атрибутам и компонентам(средство).

*****************************************************************
Итак, попробую дать определения для различных «программирований».
*****************************************************************

Компонентно-ориентированное программирование.

Подход к разработке, ориентированный на использование разных языков программирования, в рамках какой-либо компонентной инфраструктуры. Подход, в основном, нацелен на реализацию независмого распространения компонентов.
Примеры инфраструктур: COM, Corba Component Model (CCM), Любые plug-ins – тоже, в сущности, компоненты.

Атрибутное программирование.

Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Аспектно-ориентированное программирование.

Совокупность подходов и средств, предусматривающих независимую реализовацию различной, например — прикладной и инфраструктурной [часто встречающийся термин "cross-cutting" я перевёл как «пронизывающей»] функциональности системы. Такие реализации называются аспектами. Подразумевает наличие средства, компонующего [weaving] аспекты в единое целое. Наличие такого средства требует, чтобы аспекты были снабжены определёнными декларациями, на основе которых выполняется компоновка.

Ну вот так или примерно так. Теперь жду ваших мнений.

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

Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns.
Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".

Насчет SoC я ни до чего путного недодумался.

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

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

ГВ>Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения (В конце постинга). Если оппоненты согласны, то дальше будем дискутировать, опираясь на эти определения. Если нет, то попрошу аргументированно оспорить предложенные определения и предложить свои формулировки.

Провокатор?

ГВ>"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.

Почему именно бинарной? Корба или веб-сервисы как то без обходиться. И никаких согласователей там не наблюдается.

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

Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

ГВ>В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.

Про языки см. выше.

VD>> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:

На определение не катит. Атрибуты тоже прописываются в коде. И еще — Атрибутное ... — ... ввиде атрибутов. Это как:
Что такое компилятор? Эта такая программа которая компилирует. А что такое компилировать? Это то что делает компилятор.
Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.

ГВ>OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п.

Прежде всего внутренними. Компилятор шарпа кстати тоже написан на шарпе и работает в CLR.

ГВ>Атрибуты, вероятно, характеризуются именем, и типом значения.

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

ГВ>SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.

Пролог не декларативный, в отличие от SQL92. Это продукционный язык. Более известный аналог — язык шаблонов XSLT. Да и sql декларативный только то что в стандарте. Реальные языки, вроде transact sql или pl/sql имеют как декларативную так и экзекутивную часть.

ГВ>Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".

Что ты понимаешь под семантикой атрибутов?

ГВ>Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.

Это можно сказать про очень много видов программирования. Не в этом изюминка атрибутов. Атрибутное программирование это прежде всего программирование метаданных. Другой вид такого программированиия — часть Reflection.Emit, так которая не касается собственно IL опкодов.

ГВ>OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.

Непонятно.

ГВ>

ГВ>Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality.

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


ГВ>Компонентно-ориентированное программирование.

ГВ>Подход к разработке, ориентированный на использование разных языков программирования,

Как я уже говорил — в корне неверно

ГВ>Corba Component Model (CCM)

Это неофициальный термин по моему. Официально CORBA 3.

Остальное вроде бы правильно.

Здравствуйте Anton V. Kolotaev, Вы писали:

AVK>Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns.
AVK>Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".

Сращивание

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

Чего за прикол? Все смайлики покоцались.

Смайлики были у слова провокатор и про определение компилятора.

еще раз попробую

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

AVK>Здравствуйте Anton V. Kolotaev, Вы писали:

AVK>>Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns.
AVK>>Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".

AVK>Сращивание

Во! Кажется нашёл — "слияние".

Правда, вот что делать с SoC пока толком не представляю. По идее, если буквально перевести, то получится "Разделение озабоченностей". Наверное, что-то вроде "Разделения соглашений". Вобщем, надо думать...

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

AVK>Чего за прикол? Все смайлики покоцались.
AVK>Смайлики были у слова провокатор и про определение компилятора.

AVK>еще раз попробую
AVK>

Да ладно, я не обиделся

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

ГВ>>Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения.
[...]

AVK>Провокатор?

Да нет, просто на самом деле, жду формулировок от оппонентов. Поскольку они молчат, то решил предложить свои формулировки.

ГВ>>"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.

AVK>Почему именно бинарной? Корба или веб-сервисы как то без обходиться. И никаких согласователей там не наблюдается.

Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.

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

AVK>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

Ни в коем случае. Я сказал — возможно.

ГВ>>В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.

AVK>Про языки см. выше.

Пожалуй, что ты прав. В определении акцент, вероятно, следует сделать на инфраструктурную составляющую.

VD>>> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:

AVK>На определение не катит. Атрибуты тоже прописываются в коде. И еще — Атрибутное ... — ... ввиде атрибутов. Это как:
AVK>Что такое компилятор? Эта такая программа которая компилирует. А что такое компилировать? Это то что делает компилятор.
AVK>Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.

ГВ>>OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п.

AVK>Прежде всего внутренними. Компилятор шарпа кстати тоже написан на шарпе и работает в CLR.

OK, сократим формулировку до: "... могут анализироваться какими-то средствами ...".Справедливости ради, стоило ввести понятие "внутреннего" и "внешнего" средства.

ГВ>>Атрибуты, вероятно, характеризуются именем, и типом значения.

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

В сущности — класс атрибута это и есть тип его значения.

ГВ>>SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.
AVK>Пролог не декларативный, в отличие от SQL92. Это продукционный язык. Более известный аналог — язык шаблонов XSLT. Да и sql декларативный только то что в стандарте. Реальные языки, вроде transact sql или pl/sql имеют как декларативную так и экзекутивную часть.

OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.

ГВ>>Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".

AVK>Что ты понимаешь под семантикой атрибутов?

Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.

ГВ>>Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.

AVK>Это можно сказать про очень много видов программирования. Не в этом изюминка атрибутов. Атрибутное программирование это прежде всего программирование метаданных. Другой вид такого программированиия — часть Reflection.Emit, так которая не касается собственно IL опкодов.

Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.

ГВ>>OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.

AVK>Непонятно.

Ну, может быть и не очень удачный термин. Эмоции, понимаешь. Собственно, на определение само по себе это не повлияло.

ГВ>>

ГВ>>Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality.

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

Ничего не поделаешь, поиск, сам понимаешь...

ГВ>>Компонентно-ориентированное программирование.

ГВ>>Подход к разработке, ориентированный на использование разных языков программирования,

AVK>Как я уже говорил — в корне неверно

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

В особенности, за её конструктивную составляющую.

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

ГВ>Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.

Не вижу никакой принципиальной разницы между бинарной и текстовой совместимостью.

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

ГВ>В сущности — класс атрибута это и есть тип его значения.

Не стоит все же упрощать атрибут до именованного значения. К примеру в конструкторе атрибут может произвести какие то действия (при компиляции!). Какие то значения могут вычисляться (опять же — и при компиляции и при чтении), значения могут подгружаться из внешнего источника. Да при желании много чего можно наворотить вроде АОП для атрибутов. Все же называть полноценный класс парой имя-значение несколько некорректно.

ГВ>OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.

Какой он нафик декларативный если в теле продукции совсем недекларативные конструкции. Он декларативный только на верхнем уровне — наборе продукций (правил), а точнее их условной части.


AVK>>Что ты понимаешь под семантикой атрибутов?

ГВ>Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.

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

ГВ>Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.

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

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

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

ГВ>>Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.

AVK>Не вижу никакой принципиальной разницы между бинарной и текстовой совместимостью.

В каком-то смысле я тоже не вижу разницы. Вот потому я и выбрал термин "бинарная" как более общий. Здесь, ИМХО, правомерно утверждение, что "текстовая совместимость" — ипостась "бинарной совместимости". То есть, хорошо бы иметь бинарную, но за неимением такой возможности сойдёт и "текстовая". На самом деле, ИМХО, что бинарная, что текстовая совместимости — просто способы реализации инфраструктуры, обеспечивающей взаимодействие.

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

ГВ>>В сущности — класс атрибута это и есть тип его значения.

AVK>Не стоит все же упрощать атрибут до именованного значения. К примеру в конструкторе атрибут может произвести какие то действия (при компиляции!). Какие то значения могут вычисляться (опять же — и при компиляции и при чтении), значения могут подгружаться из внешнего источника. Да при желании много чего можно наворотить вроде АОП для атрибутов. Все же называть полноценный класс парой имя-значение несколько некорректно.

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

Хотя, знаешь, идея! Можно заменить определение "имя-значение" (кстати, я говорил о паре "имя-тип") фразой "сопутствующий объект, с которым могут взаимодействовать как объекты программы, так и внешние по отношению к программе средства (в частности — компилятор)".

ГВ>>OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.

AVK>Какой он нафик декларативный если в теле продукции совсем недекларативные конструкции. Он декларативный только на верхнем уровне — наборе продукций (правил), а точнее их условной части.

OK, Prolog — не полностью декларативный язык. И давай завяжем с ним.

AVK>
AVK>>>Что ты понимаешь под семантикой атрибутов?

ГВ>>Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.

AVK>Атрибут в общем случае может не иметь семантики и сам по себе производить какие то действия. См. выше примеры.

Вот эти действия и есть его семантика.

ГВ>>Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.

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

Хорошо, назовём .NET инфраструктурой, а Emit — её частью. По-моему — справделиво.

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

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

S>>Чтоб не флеймить зря, покажи, как на C# реализуется эта самая парадигма — тогда можно будет предметно обсудить, чего в С++ не хватает.

VD>Вот пример из соседнего формума:
VD>

   Пример поскипан.
VD>

VD>Это COM+-объект созданный на C#. Без применения атрибутов мне прилось бы создать отдельный idl-файл с описанием интерфейсов, ко-классов и библиотеки типов. Это — раз. Ну и при регистрации пришлось бы задать все параметры вручную или написать нехилый скрипт для их задания. Тут же я обхожусь заданием атрибутов.

Этот пример говорит только о том, что модель COM (а именно, расширенная динамическая информация о типах в стиле IDispatch) плохо стыкуется со статически типизированным C++. Никакой новой парадигмой тут и не пахнет. Грубо говоря, если мне в плюсовом коде у класса A нужен атрибут GUID, я пишу:

struct ClassWithGUIDBase
{
virtual bool HasGUID() const = 0;
virtual void GetGUID(GUID &id) const = 0;
};

class ClassWithGUID : public ClassWithGUIDBase
{
GUID _id;
public:
ClassWithGUID(const GUID& id) : _id(id) {}
virtual bool HasGUID() const
{ return true; }
virtual void GetGUID(GUID &id) const
{ id = _id; }
};

class ClassWithoutGUID : public ClassWithGUIDBase
{
public:
virtual bool HasGUID() const
{ return false; }
virtual void GetGUID(GUID &id) const
{ throw std::runtime_error("Да нет у меня гуида"); }
};

class A : ClassWithGUID
{
public:
A() : ClassWithGUID(&some_id)
{
...
}
}

Те же атрибуты, только типизация — статическая.

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

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

VD>>>Вот если бы С++ развивался, то и замену ему искать не пришлось бы.

S>>Ну давай теперь флеймить на тему, является ли Java заменой C++ или дополнением и зачем MS выпустила .Net Сразу скажу, я не считаю, что причинами появления Java и .Net является несовершенство С++. Другие были причины, совсем другие.

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

Неа. Это перекладывание обязанностей на разработчиков библиотек Я вот, например, не знаю в деталях, как boost::bind внутри устроен, но успешно его использую, поскольку эта функция куда удобней, чем вполне прозрачные, но убогие stl'ные bind1st и bind2nd. А компонентное программирование — COM меня почти устраивал, вот только библиотеки (да и мокрософтовский подход вообще) к нему уж больно убогие. Впрочем, учитывая ужасную поддержку шаблонов в основном "COM'овском" компиляторе и медленное развитие приемов метапрограммирования в С++ (ну тут уже не MS виновата), другого ожидать и не приходится.

VD>>>Например? Множественное наследование спокойно на шаблонах обходится. Больше я ничего не заметил.

S>>Ключевое слово — обходится. На ассемблере вообще все обходится, только вот не человеческое это дело, на ассемблере большие программы писать... Кстати, покажи, как именно обходится — че то в удобство такого метода не очень верится.

VD>И причем тут ассемблер? Демогогия одно слово.

Это не демагогия, а гипербола. Демагогия — это когда кто-то заявляет, что "множественное наследование спокойно на шаблонах обходится", а потом, когда его попросили пояснить, что он под этим понимает, делает вид, что он про это не говорил или его ни о чем не спрашивали.

VD>Множественное наследование хорошо только для одного дела — подключение готовых реализаций.

Именно. Оно для того и придумывалось. Конкретное средство для решения конкретной проблемы. Его отсутствие в C# — шаг назад, к C и ассемблеру

VD>В остальном от него только одни проблемы.

Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.

VD>Я согласен, что ATL демонстрирует эффективность этго подхода.

ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.

VD>Но ведь для подключения реализаций можно пользоваться и более простыми методами.

Ну а я не считаю агрегацию более простым методом, чем множественное наследование.

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

Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?

VD>В С++ главная проблема — это непомерная сложность. Да на нем можно все. Но какй цено! В .NET же я могу писть основной костяк программы на простом и удобном языке, а когда нужно использовать С++. Правд практика показывает, что обычно это использование ограничивается созданием оберток над разыми нэйтив-АПИ.

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

S>>А не хватает, например, нормальных деструкторов,

VD>Мне в первое время тоже не хватало. Но во времением понимаешь, что это вобщем-то просто привычка. Хотя для вэлью-типов можно было бы добавить.

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

S>>argument-dependent name lookup,

VD>Это я вообще не понял, что такое?

В MSDN загляни, оно там описано.

S>> директивы using внутри функций

VD>Никогда не испытывал необходимости.

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

VD>И не помню чтобы такое было в С++.

Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.

VD>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.

Ну это дело вкуса. Хотя как быть с операторами?

S>> — эти козлы ничего умнее, чем считать ее там за using statement не придумали.

VD>using — это как раз замена тем самым деструкторам. Блок контролирующий освобождение ресурсов.

Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.

S>>Привязки параметров в делегатах не хватает, причем, в отличие от C++, руками ее не напишешь.

VD>Опять же не понял о чем идет речь? Уж делегаты то в нэте куда лучше уродливых указателей на методы класса в С++. Локанично и эффективно.

Имеются в виду Loki::Functor, Loki::BindFirst или все тот же boost::bind. И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.

S>>Возможности написать ручной распределитель памяти для конкретного класса не хватает.

VD>Опять же на С++ это обхдится. Да и на Шарпе в ансэйф-режиме тоже. Но практика показывает, что в этом просто нет нужды.

Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).

S>>Внутренней непротиворечивости, в конце концов, не хватает — взять хотя бы исключения в деструкторах или в finally.

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

А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

S>>В общем, чем дальше в лес, тем чудесатее и чудесатее. Сырой язык.

VD>Ничего там сырого нет. Ты назвал все спорные места. Других нет.

Хе-хе, вон в C++ спорные места до сих пор находят, а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел

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

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

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

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

VD>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.

А меня, к сожалению, нет.

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

ГВ>Атрибутное программирование.
ГВ>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).

Я имею в виду, что никакой атрибут не может быть получен из иерархии объекта, а только через "левый" путь: через метаданные и т.п.

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

A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.

У меня сервер на PII 233 прилично работае... К тому же ХаРэ все одно на твоей машине будет шустрее чем 98-ые.

A>ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.

Например? У меня нормально работают 16-битная бухгалтения и Dave (старая досовская игрушка от id).

A>Не забудьте встроить в Янус упаковку почты .

Не понял?

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

A>В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого.

Ты бы поставил, а потом трепался бы. На 300-х мегах W2k за всегда шустрее 98-х будет. Она эту память использовать умеет.

A>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .

Их твоих слов видно только одно. W2k ты видил только у других. А ХаРэ вообще не видил.

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

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

Vi2>

ГВ>>Атрибутное программирование.
ГВ>>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Vi2>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).

Ну, вероятно, не классами, а всё-таки — экземплярами.

Vi2>Я имею в виду, что никакой атрибут не может быть получен из иерархии объекта, а только через "левый" путь: через метаданные и т.п.

В смысле — приведением типа объекта к типу атрибута? Если так, то согласен. Как раз "левый" путь — это и есть обработка информации о типе.

OK, Thanx

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

Vi2>>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).

ГВ>Ну, вероятно, не классами, а всё-таки — экземплярами.

Совершенно верно.

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

A>Грузится, говоришь, быстрее? А я еще и программы запускаю.

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

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

PSP>Я принципиально против таких рассуждений. Если вижуал одинаковый и там и там, нахрен мне глюки иметь. А совместимость всё равно идёт снизу вверх, если я прилаги писать буду под NT4, то под 2k они тем более работать будут..

Ты под "вижуалом" VC6 имееш в иду? Ну у меня под W2k это дело уже два года работает и ничего. Сейчас вот под ХаРэ работает. К тому же студия тоже новая появилась. Та так просто на 98-е уже не рассчитана.

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

S>Этот пример говорит только о том, что модель COM (а именно, расширенная динамическая информация о типах в стиле IDispatch) плохо стыкуется со статически типизированным C++. Никакой новой парадигмой тут и не пахнет.

Конечно не пахнет! Еще если хочешь чтобы чай стал сладким без сахара, говори себе "сахар, сахар, сахр, ...) и сразу станет легче.

S>Ну, метаданными в C++ является только информация о типах. Компилятор эту информацию вполне может анализировать, сторонние утилиты — нет, но и необходимости в этом почти не возникает.

Да это тоже полезно. Говориш себе "мне это не нужно, меня это не интересует" и сразу становится легче. Аутотренинг — вещь полезная!

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

В случае С++ они могут быть заменены на килобайт скриптов. Больше ни на что. А про "поддержку взаимодуйствия со средой выполнения" это ты правильно подметил. В С++ этот намного лучше и удонее. Главное говорить сбе "вахар...).


S>Это не демагогия, а гипербола. Демагогия — это когда кто-то заявляет, что "множественное наследование спокойно на шаблонах обходится", а потом, когда его попросили пояснить, что он под этим понимает, делает вид, что он про это не говорил или его ни о чем не спрашивали.

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

class C : A< B< C > {};

Ну а демагогия — это 1. Основанное на намеренном извращении фактов воздействие на чувства, инстинкты малосознательной части масс. 2. Рассуждения или требования, основанные на грубо одностороннем истолковании чего-н.

VD>>Множественное наследование хорошо только для одного дела — подключение готовых реализаций.

S>Именно. Оно для того и придумывалось. Конкретное средство для решения конкретной проблемы. Его отсутствие в C# — шаг назад, к C и ассемблеру

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

S>Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.

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

S>ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.

Ага. Я бы сказал бы ламеры. И почему только эти неотесанные программисты так его любят? Если серьезно, то вообще не ясно почему ATL нужно оценивать с точки зрения ОО (хотя и с этой точки зрения там все впорядке).

S>Ну а я не считаю агрегацию более простым методом, чем множественное наследование.

От нее нет таких проблем как от наследования. К тому же она может производиться в рантайме.

S>Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?

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

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

Кодировать то на Шарпе удобно. Если конечно задача может быть реализована для разных типов, то шаблоны бы не помешали. И в общем то и добавят в следующей версии. Жаль что этого еще долго ждать.

S>Это вопрос удобства, а не просто привычка. Ручная очистка ресурсов там, где раньше была автоматическая — шаг назад.

Для стековых переменных есть using. Так что жтого даже не замечаешь. Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно. Так что это компромис. Но я лично на своей шкуре прочуствовал насколько лучше такое решение чем "автоматическое" из С++. Дело в том, что память теряется куда чаще чем другие ресурсы. И ловить ее потери куда сложенее. Незарытый файл или хэндл проявляются довольно быстро, а вот утечки памяти — это бичь почти всех Win32-программ. К тому же с программиста как минимум снимается куча обязанностей по контролю.

S>>>argument-dependent name lookup,

VD>>Это я вообще не понял, что такое?

S>В MSDN загляни, оно там описано.

Где там? Что оно? Может по русски?

S>Когда один класс должен использовать одноименные классы из разных неймспейсов (особенно если внутри одной функции), просто необходимая вещь. Без него — только полная квалификация имен.

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

S>Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.

Ты про using namspace?

VD>>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.

S>Ну это дело вкуса.

Это дело смысла. Точка (та что в VB) догогого стоит. Вон в пскале без нее и получается фигня. Как перекрывающиеся имена отличать?

S>Хотя как быть с операторами?

Да просто пережить. В крайнем случае .operator()...

S>Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.

В данном случае согласен. Могли бы придумать другое название. Но это они по Струструпу. Чтобы не создавать дополнительных ключевых слов. Помнишь историю про = 0 для абстрактных методов вместо слова abstract? Тоже по уродски было и аргументировалось так же.

S>И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.

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

S>Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).

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

S>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally! Почти все компиляторы это дело встроили, а Страуструп не чешется. На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей. В С++ исключение живет в пределах одного модуля, нельзя намисать код обрабоки на VC, а лволи на BCC.

S>Хе-хе, вон в C++ спорные места до сих пор находят,

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

S> а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел

А я тебе говрю, что в Шарпе все просто как три копейки. Для того он и делался.

S>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.

И ты говоришь что это не демагогия?

VD>>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.

S>А меня, к сожалению, нет.

Дык првильно! Тебе же на них кривой язык переписывать. А мне просто не зависимые от конкретных типов алгортмы писать.

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

ГВ>Компонентно-ориентированное программирование.

ГВ>Подход к разработке, ориентированный на использование разных языков программирования

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

ГВ>Примеры инфраструктур: COM, Corba Component Model (CCM), Любые plug-ins – тоже, в сущности, компоненты.

Я бы добавил Яву и .NET. В них компонентный подход вошел в общеупотребительную практику. По сути любой класс в этих системах является компонентом.

ГВ>Атрибутное программирование.

ГВ>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Мое определение "декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов" мне нравится больше.

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

Vi2>

ГВ>>Атрибутное программирование.
ГВ>>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.

Vi2>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).

Про классы явно надумано. В COM-е небыло никаких классов.

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

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

A>>Грузится, говоришь, быстрее? А я еще и программы запускаю.

VD>В общем, после твоих рассуждений о скорости, серьезно относиться к твоим рассужедениям о неприемлемости фреймворка нельзя.

В общем, после твоих рассуждений о скрости, с серьезно относиться к твоим рассужедениям о приемлемости фреймворка нельзя

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

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

A>>В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого.
VD>Ты бы поставил, а потом трепался бы. На 300-х мегах W2k за всегда шустрее 98-х будет. Она эту память использовать умеет.

Да ставил я ее. Не понравилось.

A>>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .
VD>Их твоих слов видно только одно. W2k ты видил только у других.

Я ее вижу каждый день на работе . Но там у меня компьютер побыстрее.

VD>А ХаРэ вообще не видил.

XPень я вообще ставить не буду. Большая, тормозная... Смысл ее ставить, если получаю тоже самое но с меньшими потерями?

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

AVK>Почему именно бинарной? Корба или веб-сервисы как то без обходиться. И никаких согласователей там не наблюдается.

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

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

AVK>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

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

VD>>> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:

AVK>На определение не катит. Атрибуты тоже прописываются в коде. И еще — Атрибутное ... — ... ввиде атрибутов. Это как:
AVK>Что такое компилятор? Эта такая программа которая компилирует. А что такое компилировать? Это то что делает компилятор.

Если детерминировать все термины, то определения дать невозможно.

AVK>Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.

Это определение атрибутов. А товарищь просил определение атрибутного программирования, т.е. парадигмы.

AVK>Прежде всего внутренними. Компилятор шарпа кстати тоже написан на шарпе и работает в CLR.

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

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

Еще разок. Не зацикливайся на .NET. Атрибуты не в ней ролились и не в ней помрут. Ты же мам дал определение... (атрибуты это метаданные, структура которых определяется пользователем). Классы — это реализация в .NET. К делу это отношения не имеет.

ГВ>>Corba Component Model (CCM)

AVK>Это неофициальный термин по моему. Официально CORBA 3.

Думаю это раздел из CORBA 3.

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

S>>Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.

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

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

VD>Для стековых переменных есть using.

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

VD>Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно.

А для нестековых и С++ ничего предложить не может.

VD>Но я лично на своей шкуре прочуствовал насколько лучше такое решение чем "автоматическое" из С++.

Ура. А какие споры весной были IT не даст соврать. Пользуясь случаем передаю привет IT.

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

У меня тоже.

S>>Ну это дело вкуса.

VD>Это дело смысла. Точка (та что в VB) догогого стоит. Вон в пскале без нее и получается фигня. Как перекрывающиеся имена отличать?

with все же поудобнее будет, поскольку он не для имен типов а для экзепляров. Плюс width это дополнительный хинт по оптимизации компилятору. Правда чем он поможет в случае CLR не знаю.

VD>В данном случае согласен. Могли бы придумать другое название. Но это они по Струструпу. Чтобы не создавать дополнительных ключевых слов.

Это не по Страуструпу, это по Оккаму

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

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

S>>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

VD>Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally!

Это он наверное не про finally а про Finalize() ака деструктор в дотнете.

S>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.

VD>И ты говоришь что это не демагогия?

Что проще — досовский интерфейс с сотняти хоткеев или гуй?

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

A>Да ставил я ее. Не понравилось.

Тебе не странно что куча людей поставила W2K или XP и считают что работает она быстрее даже 128М памяти? Ведь на самом деле 98 быстрее? Или они 98 не видели не разу?

A> Я ее вижу каждый день на работе . Но там у меня компьютер побыстрее.

Я конечно не знаю про новомодные W2K и XP, но NT4 было начхать на процессор, она прекрасно крутилась на 486Dx2 66. Небольшие провисания были только при обращении к реестру. Главное чтобы память была. И уж 384М ей выше крыши. У меня на работе 256, более чем хватает для студии, мейл-сервера, mssql, 1С, бата, фара и пары-тройки ie запущенных одновременно. И ничего не тормозит.

A>XPень я вообще ставить не буду. Большая, тормозная... Смысл ее ставить, если получаю тоже самое но с меньшими потерями?

Кому как. В W2K были кое какие глючки и недоделки которые мне мешали. В XP поправили. Правда я SP3 не видел.

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

ГВ>Да нет, просто на самом деле, жду формулировок от оппонентов. Поскольку они молчат, то решил предложить свои формулировки.

Вообще-то тебе дали формулировки (хотя их и легко было найти в Инете). Но ты видимо захотел их подправить так чтобы было удобее (тебе).

ГВ>OK, сократим формулировку до: "... могут анализироваться какими-то средствами ...".

Да. Так лучше.

ГВ>Справедливости ради, стоило ввести понятие "внутреннего" и "внешнего" средства.

А вот это лишнее. Отношения к делу не имеет.

ГВ>В сущности — класс атрибута это и есть тип его значения.

Не нужно привносить философию в простые вещи. Атрибут — это пользовательские методанные. Не больше не меньше.

ГВ>OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.

Согласен. Но почему атрибутное программирование ты упорно не хочешь признать декларативным? По-моему — это очевидно. Мы задаем условия и получаем нужный нам результат (вместо того чтобы программировать путь его достижения).

ГВ>Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.

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

ГВ>OK, я согласен с твоим доводом. Компонентное программирование акцентировано на поддерживающей компоненты инфраструктуре.



ГВ>Многоязычие можно считать частным случаем развития инфраструктуры компонентного программирования.

Я бы сказал следствием, да и то в некоторых случаях. Кстит, исключением является одна Ява. Дельфи делит компоненты с Билдером.

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

VD>Корба

CORBA 3

VD> и веб-сервисы не явлются компонентными технологимя. Это по сути ORPC.

ORPC это корба. Сервисы это нечто большее (WSDL, UDDI), котя на компонентную технологию может и не тянет.

VD>В любом случае даже в эих технологиях есть согласователи.

Где ты их там увидел?

AVK>>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

VD>А чем они не удовлетваряют?

Ты вобще читаешь топик? В них нет многоязыковости.

VD> В них прекрасно можно подменять реализацию. Главное чтобы интерфейс совподал. Или ты про язык? С языком согласен. Но выражайся точней.

Я точно выразился. Точнее некуда.

VD>Если детерминировать все термины, то определения дать невозможно.

Надо ввести аксиомы.

AVK>>Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.

VD>Это определение атрибутов. А товарищь просил определение атрибутного программирования, т.е. парадигмы.

Ну так атрибутное программирование это программирование с использованием атрибутов Главное атрибуту определение дать.

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

В общем то да.

VD>Еще разок. Не зацикливайся на .NET. Атрибуты не в ней ролились и не в ней помрут.

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


AVK>>Это неофициальный термин по моему. Официально CORBA 3.

VD>Думаю это раздел из CORBA 3.

Судя по тому что на их сайте это не раздел а именно она и есть. Хотя могу и ошибаться.

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

VD>> и веб-сервисы не явлются компонентными технологимя. Это по сути ORPC.

AVK>ORPC это корба. Сервисы это нечто большее (WSDL, UDDI), котя на компонентную технологию может и не тянет.
Совсем записАлся. Читать ORPC это SOAP + SoapFormatter + прокси и стабы

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

VD>Она вообще-то позволяет сгенерировать бинарный код.

Не только код! Метаданные тоже.

VD>Я бы сказал следствием, да и то в некоторых случаях. Кстит, исключением является одна Ява. Дельфи делит компоненты с Билдером.

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

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

AVK>Не вижу никакой принципиальной разницы между бинарной и текстовой совместимостью.

Не бывает "текствых" компонентов. Это противоречит принципу потчужаемости. Приведи хотябы один пример текстовой совместимости.

AVK>Не стоит все же упрощать атрибут до именованного значения.

Только так их и можно понимать. Все остальное это особенности реализации в .NET.

ГВ>К примеру в конструкторе атрибут может произвести какие то действия (при компиляции!).

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

ГВ> Какие то значения могут вычисляться (опять же — и при компиляции и при чтении), значения могут подгружаться из внешнего источника.

Ты пробовал?

AVK>Какой он нафик декларативный если в теле продукции совсем недекларативные конструкции. Он декларативный только на верхнем уровне — наборе продукций (правил), а точнее их условной части.

Здесь про нет (в котором впрочем все тоже самое) речь не шла. Речь шла о декларативном программировании.

AVK>Атрибут в общем случае может не иметь семантики и сам по себе производить какие то действия. См. выше примеры.

Это уже не атрибут. Атибут есть выражение мысли запечатленное в метаданных.

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

ГВ>Хотя, знаешь, идея! Можно заменить определение "имя-значение" (кстати, я говорил о паре "имя-тип") фразой "сопутствующий объект, с которым могут взаимодействовать как объекты программы, так и внешние по отношению к программе средства (в частности — компилятор)".

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

AVK>>Атрибут в общем случае может не иметь семантики и сам по себе производить какие то действия. См. выше примеры.

ГВ>Вот эти действия и есть его семантика.

Нет. Это просто заблуждение.

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

VD>Не бывает "текствых" компонентов. Это противоречит принципу потчужаемости. Приведи хотябы один пример текстовой совместимости.

Чем тебе веб сервисы не катят? В любом случае — что мне мешает сделать свою компонентную модель без бинарной совместимости?

AVK>>Не стоит все же упрощать атрибут до именованного значения.

VD>Только так их и можно понимать. Все остальное это особенности реализации в .NET.

Эти особенности реализации определяют само программирование. Цитату Дийкстры про то что средство программирования определяет стиль мышления я недавно приводил.

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

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

От чего же теоритически? Ведь же есть реальные продукты.

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

Много это больше одного. Если по классике. К тому же я и говорю следствие. Билдер тоже был пределан апосля.

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

AVK>Чем тебе веб сервисы не катят? В любом случае — что мне мешает сделать свою компонентную модель без бинарной совместимости?

Только тем что они не имеют никакого отношения к компонентам и компонентным технологиям.

VD>>Только так их и можно понимать. Все остальное это особенности реализации в .NET.

AVK>Эти особенности реализации определяют само программирование. Цитату Дийкстры про то что средство программирования определяет стиль мышления я недавно приводил.

Атрибуты в общем случае всего лишь возможность расширения метаданных.

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

VD>>В любом случае даже в эих технологиях есть согласователи.

AVK>Где ты их там увидел?

В корбе: idl, iiop, соглашения о именовании...

AVK>>>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

VD>>А чем они не удовлетваряют?

AVK>Ты вобще читаешь топик? В них нет многоязыковости.

Читаю. Ты тоже читай что пишешь. И указывай конкретно что тебе не понравилось в чужих словах. К тому же компонентная модель Дельфи совместма с Билдером, а для Ява-машины тоже можно создавать компоненты на других языках.

VD>> В них прекрасно можно подменять реализацию. Главное чтобы интерфейс совподал. Или ты про язык? С языком согласен. Но выражайся точней.

AVK>Я точно выразился. Точнее некуда.

Тогда еще раз перечитай то что ты скзал:

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

AVK>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?

Про языки тут сказано "возможно", т.е. не обязательно. Я так понмаю что "Это совершенно не обязательно." отностся к "любой компонент может быть заменён своим функциональным аналогом".

VD>>Если детерминировать все термины, то определения дать невозможно.

AVK>Надо ввести аксиомы.

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

AVK>Ну так атрибутное программирование это программирование с использованием атрибутов Главное атрибуту определение дать.

Вот и не нужно приплетать суда то что в нэте это классы. Это детали.

AVK>Определение, подходящее для атрибутов дотнета и атрибутов кома одновременно будет расплывчатым и неточным — слишком мало общего и слишком важны отличия.

Определение сущности не должно давать еще каких-то определений. Я уже дал простое определение: "программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов".

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

VD>>Из твоих слов видно только одно. W2k ты видил только у других.

A> Я ее вижу каждый день на работе . Но там у меня компьютер побыстрее.

Твой примерно в 5 рабз превышает необходимый уровень.

VD>>А ХаРэ вообще не видил.

A>XPень я вообще ставить не буду. Большая, тормозная... Смысл ее ставить, если получаю тоже самое но с меньшими потерями?

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

В любом случае фрймворк работает на 98 ни чем не хуже.

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

AVK>Кому как. В W2K были кое какие глючки и недоделки которые мне мешали. В XP поправили. Правда я SP3 не видел.

Интересно какие? У меня с ХаРэ проблем оказалось значительно больше. Один только прикол с переводом экрана в 8 цветов при запуске 16-битного прложения для Вин 3.1...

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

A>В общем, после твоих рассуждений о скрости, с серьезно относиться к твоим рассужедениям о приемлемости фреймворка нельзя

A>

Ну-ну. Здесь конечно все идиоты кроме тебя.

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

VD>>Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно.

Там есть статические объекты. Правда в Шарпе GC всегда срабатывает при выходе из программы, так что без разницы.

AVK>А для нестековых и С++ ничего предложить не может.

VD>>Но я лично на своей шкуре прочуствовал насколько лучше такое решение чем "автоматическое" из С++.

AVK>Ура. А какие споры весной были IT не даст соврать. Пользуясь случаем передаю привет IT.

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


VD>>Это дело смысла. Точка (та что в VB) догогого стоит. Вон в пскале без нее и получается фигня. Как перекрывающиеся имена отличать?

AVK>with все же поудобнее будет, поскольку он не для имен типов а для экзепляров. Плюс width это дополнительный хинт по оптимизации компилятору. Правда чем он поможет в случае CLR не знаю.

Да все темже. Я собственно за with и говорил, но в семантике VB. Там для доступа к with-нутым объектам нужно ставить точку:

with obj
  .Text ' Доступ к свойству obj.Text
  Text  ' Доступ к свойству Me.Text
end with

В Паскле с этим задница.

AVK>Это не по Страуструпу, это по Оккаму

Ну тебе видней.

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

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

S>>>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

VD>>Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally!

AVK>Это он наверное не про finally а про Finalize() ака деструктор в дотнете.

Да вроде про finally (см. выше).

AVK>Что проще — досовский интерфейс с сотняти хоткеев или гуй?

Кому как. Это тоже не по делу.

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

VD>>В общем устарел этот самы С++, а менять его очень не хотят.

А>Ну всем и так ясно, что не любишь ты C++.

А>Есть известный анекдот по этому поводу: "... ну не люблю я тебя мужик!..."

Не то чтобы не люблю. Но то что он устарел и не хочет развиваться — это факт.

Пописал я на нем немало. В общем-то моей первый ОО язык.

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

VD>>>Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно.

AVK>>А для нестековых и С++ ничего предложить не может.

VD>Там есть статические объекты. Правда в Шарпе GC всегда срабатывает при выходе из программы, так что без разницы.

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

AVK>>Ура. А какие споры весной были IT не даст соврать. Пользуясь случаем передаю привет IT.

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

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

AVK>>with все же поудобнее будет, поскольку он не для имен типов а для экзепляров. Плюс width это дополнительный хинт по оптимизации компилятору. Правда чем он поможет в случае CLR не знаю.

VD>Да все темже. Я собственно за with и говорил, но в семантике VB. Там для доступа к with-нутым объектам нужно ставить точку:

VD>

VD>with obj
VD>  .Text ' Доступ к свойству obj.Text
VD>  Text  ' Доступ к свойству Me.Text
VD>end with
VD>

Очень правильно — в случае with конфликты имен бывают частенько. Плюс точка дает понять что это именно к with относиться. Единственный подводный камень with — ухудшение читаемости программы.

VD>В Паскле с этим задница.

С чем задница?

VD>Ну это ты зря. В плюсах есть шаблоны с их помощью многое можно сотворить.

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


S>>>>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

VD>>>Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally!

AVK>>Это он наверное не про finally а про Finalize() ака деструктор в дотнете.

VD>Да вроде про finally (см. выше).

Тогда как понять

нормальные деструкторы вместо finally

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

[ой, много чего писали ]

VD>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.

Это ECMA-шный-то стандарт? Пока на этом стандарте не будет буковок "ANSI/ISO <ля-ля-ля>" — это фикция (ой, извините за неполиткорректность, это блестящий маркетинговый ход ), а не стандарт. Таких стандартов своих у любой фирмы — вагон и две телеги впридачу.

Специально напоминаю: Win16 API тоже был стандартизирован в ECMA. Кстати, я уже постил по этому поводу

Автор: Геннадий Васильев
Дата: 06.09.02

. Желающие могут проверить и скачать потрясающе интересные документы с сайта www.ecma.ch. Ёлки! Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.

Поясняю свою оценку. В принципе-то да, принятие стандарта позволяет клонировать разработку MS другим производителям, но оригинал улетит за это время ещё неизвестно куда, и неизвестно во что превратится. То есть в данном случае стабильность этого стандарта — от силы полгода-год. И шо це за стандарт?

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

VD>>В Паскле с этим задница.

AVK>С чем задница?

С точкой. Вернее без нее.

AVK>Есть, я о них тоже подумал. Но в случае джавы и дотнета решение более кардинальное.

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

AVK>Тогда как понять
AVK>

нормальные деструкторы вместо finally

Да черт этих защитников С++ поймет.

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

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

ГВ>[ой, много чего писали ]

VD>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.

ГВ>Это ECMA-шный-то стандарт?

В С++ нет и такого. Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.

ГВ>Пока на этом стандарте не будет буковок "ANSI/ISO <ля-ля-ля>" — это фикция (ой, извините за неполиткорректность, это блестящий маркетинговый ход ), а не стандарт. Таких стандартов своих у любой фирмы — вагон и две телеги впридачу.

Правильно! Вот Штаты — это круто а европа — дерьмо. Только вот мне это хыть бы.

ГВ>Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.

Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?

ГВ>Поясняю свою оценку. В принципе-то да, принятие стандарта позволяет клонировать разработку MS другим производителям, но оригинал улетит за это время ещё неизвестно куда, и неизвестно во что превратится. То есть в данном случае стабильность этого стандарта — от силы полгода-год. И шо це за стандарт?

Да плевать мне на опен сорс. Мне ешать нужно. Я стандарт имел в виду в том смысле, что в .NET определено как нужно обрабоатывать и генерировать исключения. И все языки будут делать это именно так. Причем даже не важно будет ли это соотвествать ECMA CLI или нет.

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

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

VD>>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.

ГВ>>Это ECMA-шный-то стандарт?

VD>В С++ нет и такого.

Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.

VD>Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.

Тоже аргумент.

ГВ>>Пока на этом стандарте не будет буковок "ANSI/ISO <ля-ля-ля>" — это фикция (ой, извините за неполиткорректность, это блестящий маркетинговый ход ), а не стандарт. Таких стандартов своих у любой фирмы — вагон и две телеги впридачу.

VD>Правильно! Вот Штаты — это круто а европа — дерьмо. Только вот мне это хыть бы.

Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...

ГВ>>Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.

VD>Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?

Я бы так уверенно не говорил. IBM очень уж большие ставки на Java делает.

ГВ>>Поясняю свою оценку. В принципе-то да, принятие стандарта позволяет клонировать разработку MS другим производителям, но оригинал улетит за это время ещё неизвестно куда, и неизвестно во что превратится. То есть в данном случае стабильность этого стандарта — от силы полгода-год. И шо це за стандарт?

VD>Да плевать мне на опен сорс. Мне ешать нужно. Я стандарт имел в виду в том смысле, что в .NET определено как нужно обрабоатывать и генерировать исключения. И все языки будут делать это именно так. Причем даже не важно будет ли это соотвествать ECMA CLI или нет.

Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...

VD>А вот в С++ с этим беда. Его создатели как черт ладана боятся говорить о рантайме. Принцип реализации исключений не определен и каждый лепит реализацию как хочет. А мир уже изменился. Сегданя совместимости на уровне исходников недосточно!

Хорошо бы сначала её получить, а потом рассуждать о достаточности...

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

ГВ>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.

У меня стандарта нет. Так что приведи пункты где говорится о обем бинарном формате. Плиз.

ГВ>Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...

Ну и скорость реакции во столько же раз менше.

VD>>Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?

ГВ>Я бы так уверенно не говорил. IBM очень уж большие ставки на Java делает.

Он и на полуось стаки далела. Они вообще теперь на все ствят. А про Хюлет — это уже 100%.

ГВ>Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...

А я хоть слово про ECMA вообще говорил? Хотя любая независимая стандартизация — это хорошо.

VD>>А вот в С++ с этим беда. Его создатели как черт ладана боятся говорить о рантайме. Принцип реализации исключений не определен и каждый лепит реализацию как хочет. А мир уже изменился. Сегданя совместимости на уровне исходников недосточно!

ГВ>Хорошо бы сначала её получить, а потом рассуждать о достаточности...

Я что-то не пойму что ты плучить не можешь? Я вот без проблем генерирую исключение в MC++ и ловлю в Шарпе.

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

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

ГВ>>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.

VD>У меня стандарта нет. Так что приведи пункты где говорится о обем бинарном формате. Плиз.

А я ничего и не говорил о бинарном стандарте на C++. Да и откуда он возьмётся для языка высокого уровня? Я говорил о неправомерности апелляции к стандарту ECMA, как к документу, сохраняющему значимость на протяженном отрезке времени. Что называется, прочувствуйте разницу.

ГВ>>Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...

VD>Ну и скорость реакции во столько же раз менше.

Вопрос: кому нужны стандарты, меняющиеся как погода осенью?

[...]

VD>Он [IBM] и на полуось стаки далела. Они вообще теперь на все ствят. А про Хюлет — это уже 100%.

Всё равно, пока что сомневаюсь, что IBM перейдёт в разряд адептов .NET. Ну, да это уже моё личное мнение. Что в IBM думают по этому поводу — .

ГВ>>Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...

VD>А я хоть слово про ECMA вообще говорил? Хотя любая независимая стандартизация — это хорошо.

Насколько я помню, стандарт CLI существует только в ECMA-шном исполнении. Отсюда при упоминании тобой термина "стандарт" я сразу и вспомнил про ECMA.

Про "независимую стандартизацию" в данном случае ничего определённого сказать не могу. Напоминаю только, что Win16 API...

ГВ>>Хорошо бы сначала её получить, а потом рассуждать о достаточности...

VD>Я что-то не пойму что ты плучить не можешь? Я вот без проблем генерирую исключение в MC++ и ловлю в Шарпе.

Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.

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

ГВ>Ну, вероятно, не классами, а всё-таки — экземплярами.

В начале я использовал "объект класса", потом оставил "класс". Под влиянием NET.

Конечно, атрибуты — это метаданные отдельного объекта класса. Причем, атрибуты отдельных объектов класса могут быть совершенно независимы и могут не иметь отношения к классу как таковому (в NET это не так).

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

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

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

VD>Кодировать то на Шарпе удобно...
VD>А я тебе говорю, что в Шарпе все просто как три копейки. Для того он и делался.

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

Аналогия? Пожалуйста! Использование VB — легко и просто, Дельфи (которую все почему-то(?) ругают) — тоже. И вот теперь Шарп — легко и просто.

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

[Эмоции поскипаны]

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

VD>class C : A< B< C > {};

Не въехал. У меня есть два библиотечных (читай — неизменяемых) классов A1 и B1. У класса A есть функция a(), у B — b(). Мне надо, чтоб обе они были у C. Твой пример я понял так:

template <class Tb>
struct A : public A1
{
int a();
};

template <class Ta>
struct B : public B1
{
int b() const;
};

class C: public A< B<C> > {};

Но тут эмуляции множественного наследования нет, класс C имеет только функцию int a();

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

Угу, не было, в том числе и множественного не было. Поэтому его отсутствие — шаг назад, к тем языыкам, где его не было.

S>>Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.

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

Включение в наследников членов-данных предков — не побочный, а прямой эффект. Это именно то, что требуется при множественном наследовании (да и при агрегации). Проблему дублирование представляет только при "бриллиантовом" наследовании, которое здравомыслящие люди используют только при крайней необходимости. Но даже при "бриллиантовом" наследовании дублирование контролируемое — с помощью виртуального наследования. Проблем при приведении типов, честно говоря, я не замечал. Малопонятных сообщений компиляторов я тоже не замечал — по сравнению с тем заклинаниями, что VC выдает для шаблонов, все прозрачно как слеза комсомолки.

S>>ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.

VD>Ага. Я бы сказал бы ламеры. И почему только эти неотесанные программисты так его любят? Если серьезно, то вообще не ясно почему ATL нужно оценивать с точки зрения ОО (хотя и с этой точки зрения там все впорядке).

Не охота ATL по второму разу обсуждать . Ну ладно — там полно "грязного" кода в сишном стиле, там куча ошибок и утечек (особенно в OLE DB шаблонах и в хосте для ActiveX контролов), премерзкая реализация синков событий (мля, ну обернули бы в класс, запасающий куку — нет, самому приходится делать). Половину генерированного визардом кода приходится переписывать руками. Включение макроса _ATL_DEBUG_INTERFACES приводит к появлению AV время от времени — Release обектов начинает производить обращение к уже освобожденной памяти, если страница успела выгрузиться — иммедиате кирдык. А любят этот глючный ATL только потому, что нет ничего лучшего да еще за большую, по сравнению с MFC, гибкость и удобство. На безрыбье, так сказать...

S>>Ну а я не считаю агрегацию более простым методом, чем множественное наследование.

VD>От нее нет таких проблем как от наследования. К тому же она может производиться в рантайме.

Ну тут как раз неразрешимое противоречие — или в рантайме, или C++. Мне удобнее, чтоб ошибки с типами компилятор искал. Если надо будет в рантайме, я выберу другой язык.

S>>Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?

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

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

S>>Это вопрос удобства, а не просто привычка. Ручная очистка ресурсов там, где раньше была автоматическая — шаг назад.

VD>Для стековых переменных есть using. Так что жтого даже не замечаешь.

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

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

У меня несколько другой опыт — в C++ программах обычно вполне хватает рефкаутинга (умные указатели), при этом время жизни объекта остается детерменированным. Я уже не помню, когда последний раз в своем коде утечки памяти искал. А вот утечки хэндлов зачастую проявляются тогда, когда про код, в котором они возникают, все и думать забыли. Поэтому мне GC не нравится в принципе. Если уж даже Страуструп утверждает, что когда в С++ появится GC (причем добавляет "когда, а не если"), деструкторы для коллектнутых объектов вызываться не будут, то нафиг мне такой GC не нужен.

S>>>>argument-dependent name lookup,

VD>>>Это я вообще не понял, что такое?

S>>В MSDN загляни, оно там описано.

VD>Где там? Что оно? Может по русски?

Там — это в MSDN. Оно — это argument-dependent name lookup. Задаешь поиск по фразе "argument-dependent name lookup", находишь в C++ language reference пункт 3.4.2 — Argument-Dependent Name Lookup. Объяснять, тем более по русски, долго.

S>>Когда один класс должен использовать одноименные классы из разных неймспейсов (особенно если внутри одной функции), просто необходимая вещь. Без него — только полная квалификация имен.

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

Так тебе и неймспейсы, получается, не нужны, раз и без них имена не пересекаются. Хотя, конечно, в шарпе алиасы есть, но они нарушают локальность — в одном месте объявляем, через 500 строк используем.

S>>Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.

VD>Ты про using namspace?

И про using namspace тоже. Но в основном, конечно, про using Namespace_name::Name (типа using std::vector). using namspace опасен, поскольку открывает все имена из неймспайса, даже те, про которые ты не знаешь.

VD>>>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.

S>>Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.

VD>В данном случае согласен. Могли бы придумать другое название. Но это они по Струструпу. Чтобы не создавать дополнительных ключевых слов. Помнишь историю про = 0 для абстрактных методов вместо слова abstract? Тоже по уродски было и аргументировалось так же.

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

S>>И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.

VD>Ну тогда может ты приведешь мне пример отличный от эмуляции делегатов (что тоже делает через одно место). А? Уродливо именно то что из полезного и удобного средства в С указатели на функции превратились в безмолезные уродливые кострукции.

Ну были у меня ситуации, когда у класса функция должна делать разные вещи в зависимости от содержимого членов. Причем должна работать быстро (правило к таблице применить). Самым простым и прямым решением оказалось применение указателей на функции. Одно длинное сравнение, потом 10000 косвенных вызовов. Еще для эмуляции vtbl полезно — посмотреть можно здесь: http://oonumerics.org/tmpw01/alexandrescu.pdf. В общем, указатели на функции-члены нужны в случаях, когда применение виртуальных функций и иерархий классов затруднено, избыточно или чересчур дорого.

S>>Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).

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

Не, к GC тот случай отношения не имеет. Я просто точно знал, как работает (конкретно — как именно выделяет и копирует память) стрим (это был мой стрим), поэтому мог применять VirtualAlloc и MoveMemory вместо хиповских функций. MoveMemory, насколько я понимаю, работает достаточно умно и в случае, если двигается целая страница, физического копирования не производит, а просто меняет таблицу дескрипторов памяти, подставляя одну физическую страницу по разным виртуальным адресам. Поскольку после копирования скопированная страница сразу освобождалась, никакого Copy-On-Write не было. За счет этого — гигансткий рост производительности.

S>>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.

VD>Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally! Почти все компиляторы это дело встроили, а Страуструп не чешется.

Деструкторы выглядят куда логичнее в ООП-языке. Вся очистка ресурсов делается классами-обертками. finally же поощряет не-ООПный стиль. Кроме того, если я в finally буду вызывать какие-то библиотечные функции, которые могут кинуть новое исключение, мне каждый такой вызов придется заворачивать в try/catch и код станет совершенно нечитаемым. В С++ я эти try/catch могу спрятать внутри деструкторов, вызов деструкторов руками прописывать не надо, кода меньше — ошибок меньше.

VD>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.

Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения (то ли в интеропе он это делает, то ли еще когда, я пока не разобрался), часть ошибок (все та же неочистка ресурсов, например) просачивается в релиз.

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

Есть такая проблема. Без стандартизации рантайма не решается. Но рантайм нельзя стандартизировать в рамках языка общего назначения, максимум, что можно сделать — стандартизировать рантайм в рамках языка и платформы. Так что опять производители компиляторов и, конечно же, горячо любимая MS, виноваты — так и не договорились, падлы.

S>>Хе-хе, вон в C++ спорные места до сих пор находят,

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

Их иногда находят в самых простых местах

Как тебе такой пример:

int main()
{
   bool a;
   bool b = a;
   if (b == a)
      return 0;
   else
      return 1;
}

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

S>> а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел

VD>А я тебе говрю, что в Шарпе все просто как три копейки. Для того он и делался.

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

S>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.

VD>И ты говоришь что это не демагогия?

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

VD>>>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.

S>>А меня, к сожалению, нет.

VD>Дык првильно! Тебе же на них кривой язык переписывать. А мне просто не зависимые от конкретных типов алгортмы писать.

Я на них метапрограммировать хочу Это примерно как ты на С# подсел

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

S>Угу, не было, в том числе и множественного не было. Поэтому его отсутствие — шаг назад, к тем языыкам, где его не было.

И джава и object паскаль моложе плюсов. У обоих множественного наследования нет. Что это все так дружно назад шагают, не знаешь?

S>Но даже при "бриллиантовом" наследовании дублирование контролируемое — с помощью виртуального наследования.

Это называется создаем себе проблемы а потом начинаем их решать.

S>using, конечно, частично исправляет ситуацию. Но он вводит область видимости, что не всегда удобно.

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

S>Там — это в MSDN. Оно — это argument-dependent name lookup. Задаешь поиск по фразе "argument-dependent name lookup", находишь в C++ language reference пункт 3.4.2 — Argument-Dependent Name Lookup. Объяснять, тем более по русски, долго.

Классная вещь наверное, что про русски объяснить что это такое очень сложно.

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

Ни разу не сталкивался.

S>>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.

VD>>И ты говоришь что это не демагогия?

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

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

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

ГВ>Ёлки! Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.

Хрюклет где то с пару месяцев назад выпустил совместный с мсом пресс-релиз о полной и безоговорочной поддержке дотнета и начале совместных разработок.

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

ГВ>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?

Поинтересуйся сановскими стандатртами для джавы. Они довольно часто меняются. И даже в ЕСМА не стандартизованы, только комитетом сана. Но это не мешает всему и вся в джава мире иметь между собой вполне приличную совместимость. Хотя и там ляпы случаются, но почти всегда из-за недоделанных стандартов, как это было с EJB 1.0.
Стандарт это не конфетка, не признак крутости и не вещь решающая все проблемы. Стандарт это такая штука которая позволяет продукту А работать совместно с продуктом В когда они созданы разными производителями. И мне пофигу кто круче — ANSI, ISO, IEEE, РСТ или ЕСМА. Главное что ни один производитель в зравом уме не будет писать продукты под дотнет не соответствующие этому стандарту.

ГВ>Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.

Ну жди. А мы пока по простому, на шарпе будем потихоньку.

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

VD>>>В Паскле с этим задница.

AVK>>С чем задница?

VD>С точкой. Вернее без нее.

А, ну да. Но это небольшая и ожидаемая задница.

Лирическое отступление: классификация задниц
Задницы подразделяются по следующим признакам:
1) По величине. Бывают задницы маленькие, задницы средние, задницы большие и полные задницы. Последние встречаются редко, но последствия при этом бывают весьма печальные. Чаще всего встречаются задницы маленькие, но к счастью они как правило не доставляют больших хлопот.
2) По неожиданности. Бывают ожидаемые и неожиданные задницы. Ожидаемая задница встречается редко, ходят они обычно по одиночке, имет свою территорию и редко выходит за ее пределы, при встрече с человеком стараются убежать или спрятаться. Неожиданные задницы, в противоположность, очень часто сбиваются в стаи, которые постоянно меняют свое местоположение. Интересно что в стае встречаются особи разных размеров и окраски. При встрече с человеком не убегают а напротив стараются на него напасть. Таким образом встреча с большой стаей неожиданных задниц очень опасна.
3) По настроению. Бывают радостные задницы, мрачные задницы, скучные задницы и агрессивные задницы. Радостные задницы это как правило особи небольших размеров. Доставляемые ими хлопоты обычно не приводят к плохим последствиям. Мрачные задницы обычно тоже малых или средних размеров, однако заметно более неприятны. Скучные задницы, как и две предыдущих разновидности, невелики по размерам. Их характерная особенность — они пасуться очень большими стаями и завидев человека начинают выпрашивать у него еду. Если вы отвернетесь то они могут и украсть вашу еду. Агрессивные задницы как правило средних и больших размеров. Большинство полных задниц относятся именно к этой разновидности.

AVK>>Есть, я о них тоже подумал. Но в случае джавы и дотнета решение более кардинальное.

VD>И все же те же типизированные коллекции вручную делать очень геморойно. Шаблоны бы очень даже пригодились бы.

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

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

A>>В общем, после твоих рассуждений о скрости, с серьезно относиться к твоим рассужедениям о приемлемости фреймворка нельзя
A>>
VD>Ну-ну. Здесь конечно все идиоты кроме тебя.

Ты сказал.

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

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

ГВ>>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?

AVK>Поинтересуйся сановскими стандатртами для джавы. Они довольно часто меняются. И даже в ЕСМА не стандартизованы, только комитетом сана. Но это не мешает всему и вся в джава мире иметь между собой вполне приличную совместимость. Хотя и там ляпы случаются, но почти всегда из-за недоделанных стандартов, как это было с EJB 1.0.

Согласен, я как раз о том и говорил, что таких стандартов у каждой фирмы — вагон и две телеги. Мне просто непонятно, почему MS особо отметила факт стандартизации в ECMA. ИМХО — она где-то чувствует себя неуверенно, а иначе зачем лишние траты?

AVK>Стандарт это не конфетка, не признак крутости и не вещь решающая все проблемы. Стандарт это такая штука которая позволяет продукту А работать совместно с продуктом В когда они созданы разными производителями. И мне пофигу кто круче — ANSI, ISO, IEEE, РСТ или ЕСМА. Главное что ни один производитель в зравом уме не будет писать продукты под дотнет не соответствующие этому стандарту.

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

Кстати, стандарт ещё и позволяет разрабатывать продукт А, имея ввиду, что разрабатываемый продукт Б тоже будет сооответствовать этому стандарту, а сам стандарт не изменится в неизвестном направлении к моменту окончания разработок А и Б.

ГВ>>Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.

AVK>Ну жди. А мы пока по простому, на шарпе будем потихоньку.

Ну так кто же возражает?

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

ГВ> А я ничего и не говорил о бинарном стандарте на C++.

Вот ход рассуждений...

VD>>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.

VD>>В С++ нет и такого. Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.

ГВ>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.

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

Вот я тебе и говрю, что нет никакого стандарта. Стандарт — общие разплывчатые слова о том как должна вести себя обработка исключений. Но про то как это реализовывать там ничего не сказано. Я это и без стандарта прекрасно понимаю. Дело в том что С++ вообще избегает всего что связано с физической совместимостью. Этот стандарт подразумевает что есть только одна программа и что она состоит из одного модуля. Т.е. речь идет только о бинарной совместимости и только о стическом связывании. Даже библиотеки уже не выдерживают никакой критики. Попробуй на одном комиляторе создать библиотеку которая генерирует исключения, а на другом ее использовать. От сюда и все навороты КОМ-а. Все эти HRESULT вместо исключений и другая дрибидень. В .NET это все устрнено. Можно смело пользоваться всеми возможностями языка так как они гарантируются исполняющей средой.


ГВ>Да и откуда он возьмётся для языка высокого уровня?

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

ГВ>Я говорил о неправомерности апелляции к стандарту ECMA,

Еще раз тебе говорю, что слова про ECMA сказал ты. Так что это чисто воды демагогия.
Я говорил о том, что .NET это стандарт по которому будут делаться все совместимые с ним языки. Что же касается отрезка времени, то MS ясно дала понять, что будут разные версии CLR. При этом с каждой из них можно будет быть совместимым. А тот факт что разные версии CLR могут жить на одной машине не даст коду независимых фирм умереть от смены версий. И кстити продукты именно MS обладают очень высокой степенью обратной совместимости. До сих пор под NT прекрасно работают досовские игры и т.п.

ГВ>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?

Пример привести можешь? Или лиш бы наехать?

ГВ>Всё равно, пока что сомневаюсь, что IBM перейдёт в разряд адептов .NET. Ну, да это уже моё личное мнение. Что в IBM думают по этому поводу — .

IBM большая рыночная контора. Рынок PC она упускать не будет. Как только .NET завоюет серьезную чатьс этого рынка IBM будет вынуждена поддержать эту платформу, как в свое время поддержала NT бросив свою полуось.

ГВ>Насколько я помню, стандарт CLI существует только в ECMA-шном исполнении. Отсюда при упоминании тобой термина "стандарт" я сразу и вспомнил про ECMA.

А кто говорил про CLI? Я говрю о самом .NET как о стандарте де-факто.

ГВ>Было бы странно, если бы было иначе.

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

ГВ>А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.

А по исключеним совместмость полная. К тому же если ты напшешь код для VC6 без использвания специфичных для MS фич, то получишь полную совместимость с другими компиляторами. Но все это пустые слова. Если тебе нужна переносимость, то ты скорее всего просто скомпилируешь все под gcc, а если ты работаешь для виндовс, то под VC или Intel. Меня лично совместмость компиляторов не трогает. А вот бенароной или компонентной совместмости мне (как и многим) нехватет. Это как раз веление времени. И С++ здесь на сегодня в пролете. Хотя очень заль. (МС++ по большому счету уже не С++-компилятор).

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

ГВ>Согласен, я как раз о том и говорил, что таких стандартов у каждой фирмы — вагон и две телеги. Мне просто непонятно, почему MS особо отметила факт стандартизации в ECMA. ИМХО — она где-то чувствует себя неуверенно, а иначе зачем лишние траты?

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

ГВ>Не горячись , я не называл стандарт "конфеткой", "признаком крутости" и т.п. Вообще, здорово ты попытался опровергнуть довод, который сам же мне и приписал. Я говорил только о стабильности стандарта самого по себе и правомерности апелляции к стандарту с учётом стереотипа "стандарт — общепринятое стабильное решение".

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

ГВ>Кстати, стандарт ещё и позволяет разрабатывать продукт А, имея ввиду, что разрабатываемый продукт Б тоже будет сооответствовать этому стандарту, а сам стандарт не изменится в неизвестном направлении к моменту окончания разработок А и Б.

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

Важна не консервативность которую ты называешь неизменностью стандарта, а обратная совместимость. Тот же С++ можно было спокойно обоготить современными возможностями без ущерба для обратной совместимости. Но делать этог не хотят. От сюда и рождаются все эит .NET, Явы и
D.AVK>>Ну жди. А мы пока по простому, на шарпе будем потихоньку.

ГВ>Ну так кто же возражает?

Вот в 7.1 MS обещает аж 89%-ую совместмость.

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

VD>ftp://rsdn.ru/CLI/Generic/Samles
VD>ftp://rsdn.ru/CLI/Generic/Samles/generics.html — описания

Кстити как рьяные поклаоники С++ и шаблонов оценивают шаблоны в .NET?

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

S>Не въехал. У меня есть два библиотечных (читай — неизменяемых) классов A1 и B1. У класса A есть функция a(), у B — b(). Мне надо, чтоб обе они были у C. Твой пример я понял так:

S>template <class Tb>
S>struct A : public A1
S>{
S> int a();
S>};

S>template <class Ta>
S>struct B : public B1
S>{
S> int b() const;
S>};

S>class C: public A< B<C> > {};


Не так, а что-то вроде этого:

template <T>
class A : public T
{
   int a();
};

class <T>
struct B : T
{
    int b() const;
};

class A < B < C > > {};

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

PS

Кстати, в терминах шарпа писать примеры проще.

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

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

Я бы скзал так. А елси будет очень нужно то возмем МС++ тотрый 80% С++-а поддерживает и сделаем те 2% кода которые не сможем сделать на Шарпе или VB. За то не будем трахаться с отладкой по пол года и отсуствием элементаных библиотек.