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

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