Re[3]: И снова Дельфи против СИ++ - Компьютерные священные войны

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

I>>P.S. А теперь попробуй решить вторую задачу, для которой я привел свое решение, — поиск всех роутов начиная с заданного вертекса.
G>Нивопрос, выбирай

Итак, берем орграф вида:

 1, 2, 3, 4
1   x     x
2x     x 
3   x     x
4x     x

находим все роуты из 1, получаем — (1,2),(1,2,3),(1,2,3,4),(1,4),(1,4,3),(1,4,3,2)

Очевидно, ни одна твоя функция этот тест не проходит

Ты в курсе, что bfs эту задачу не решает ?

I>>P.P.S. фунцыя в JS V8 походу порвёт твой _шедевр_ по перформансу.
G>Нивопрос, приведи реальную задачу и тестовые данные.

А это реальная задача

Я упростил структуру модели, а сам алгоритм остался.
Тестовые данные — полносвязный граф из 100 элементов — это что бы кольца были в наличии, из него удалить рандомом примерно 80% связей — что бы алгоритм закончился в разумное время. Далее посчитать AllRoutes из одной вершины.

У меня есть оптимизирования версия, которая работает почти так же быстро как и С++ версия

Хочешь сравнить всерьез — это сильно легко.

G>Я специально сделал поиск максимально ленивым, чтобы мог при желании ограничить перебор и даже не искать все пути на графе.

Ты специально сделал то, чего делать почти никогда и не нужно

да еще и с ошибкой.

Отсечения делаются при переборе, но немного не так, как тебе хочется.

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

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

I>>>P.S. А теперь попробуй решить вторую задачу, для которой я привел свое решение, — поиск всех роутов начиная с заданного вертекса.
G>>Нивопрос, выбирай

I>Итак, берем орграф вида:
I>

I> 1, 2, 3, 4
I>1   x     x
I>2x     x 
I>3   x     x
I>4x     x
I>

I>находим все роуты из 1, получаем — (1,2),(1,2,3),(1,2,3,4),(1,4),(1,4,3),(1,4,3,2)
Ты и не пытался объяснить что такое роуты

I>Очевидно, ни одна твоя функция этот тест не проходит

Ты в курсе, что bfs эту задачу не решает ?

Я тебе уже говорил чтобы ты сформулировал решение в проверяемом виде.

Ты написал только это:

находит и возвращает все вертексы достижимые из заданного.

Я тебе привел два с половиной варианта, все они делают то что написано выше.
Так что не выкручивайся теперь.

I>>>P.P.S. фунцыя в JS V8 походу порвёт твой _шедевр_ по перформансу.
G>>Нивопрос, приведи реальную задачу и тестовые данные.
I>А это реальная задача

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

I>Тестовые данные — полносвязный граф из 100 элементов — это что бы кольца были в наличии, из него удалить рандомом примерно 80% связей — что бы алгоритм закончился в разумное время. Далее посчитать AllRoutes из одной вершины.
Ну так скинь сюда файл. На нем и будем забеги устраивать.

I>У меня есть оптимизирования версия, которая работает почти так же быстро как и С++ версия

Хочешь сравнить всерьез — это сильно легко.
Нивопрос, я тоже могу ченить соптимизировать.

G>>Я специально сделал поиск максимально ленивым, чтобы мог при желании ограничить перебор и даже не искать все пути на графе.

I>Ты специально сделал то, чего делать почти никогда и не нужно

С чего ты взял?

I>да еще и с ошибкой.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>За это минус, ибо ни в какие ворота... Все "трюки", описанные в GOF были известны задолго до.
V>> GOF известен тем, что обобщил и что дал терминологию трюкам, ну и дохочиво, "на пальцах", разъяснил подходящие условия для применения упомянутых паттернов.

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

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

НС>А речь здесь именно о терминологии, о том что называется словом "визитор". И для этого надо читать определения, а не заниматься фантазированием на тему. Считаешь что термин ввели не в банде? Возможно. Но тогда приводи первоисточник, будем смотреть что в нем написано.

Я вроде и написал, что банда дала термины.

Лишь обращаю внимание, что рассматриваемый трюк — частный случай более общего (и более полезного/важного) трюка, известного как множественная диспетчеризация. Поэтому уверен, что полезней понимать общую концепцию. Ибо если некая обезъянка "зазубрит" паттерн визитор без понимания происходящего, то расширить этот же паттерн на случай, когда у посетителя в методе visit(ConcreteObj) будет более одного аргумента, он уже не сможет. Упрется в бессилии.

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

V>>Визитор — это трюк всегда известный под названием двойной диспетчеризации.

НС>Ссылку на такое определение — в студию.

Хорошая ссылка на гугл уже дана.

V>> Словесная муть это, а не "другая точка зрения".

НС>ПОка что словесная муть у тебя, потому что не подкреплена ни одной ссылкой.

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

V>>ИМХО, это от непонимания концепции мультиметодов (частный случай которых в 2-х аргументах веселая четверка обозвала визитором, хотя суть паттерна "визитор" может быть расширена на любое кол-во аргументов, ибо это позволяют мультиметоды).

НС>Это от того, что кое кто жонглирует терминами.

Похоже, требуется для начала дать определение термину "жонглирование терминами". Потому как было четко сказано, что термин1 обозначает частный случай термина2. Где ты усмотрел жонглирование? Если не согласен с озвученным "обозначает частный случай", то аргументируй, в чем именно не согласен.

V>>Посмотри на этот boost::variant, должно стать понятней, что имеют ввиду, когда говорят про "статического визитора" в С++.

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

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

НС>Виртуальные функции нужны не для интерфейса визитора, виртуальным (и объявленным в базовом классе) должен быть метод AcceptVisitor. Это принципиально.

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

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

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

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

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

I>>находим все роуты из 1, получаем — (1,2),(1,2,3),(1,2,3,4),(1,4),(1,4,3),(1,4,3,2)
G>Ты и не пытался объяснить что такое роуты

Да очевидно — маршруты. В английском они называются path или route.

I>>Очевидно, ни одна твоя функция этот тест не проходит

Ты в курсе, что bfs эту задачу не решает ?

G>Я тебе уже говорил чтобы ты сформулировал решение в проверяемом виде.

G>Ты написал только это:
G>

G>находит и возвращает все вертексы достижимые из заданного.

Это первая задача, с ней ты справился

G>Я тебе привел два с половиной варианта, все они делают то что написано выше.
G>Так что не выкручивайся теперь.

первую задачу ты решил, а на второй — загруз

I>>А это реальная задача

G>Нет, реальная задача имеет некоторый value для пользователя. В поиске всех роутов я value не вижу.

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

I>>Тестовые данные — полносвязный граф из 100 элементов — это что бы кольца были в наличии, из него удалить рандомом примерно 80% связей — что бы алгоритм закончился в разумное время. Далее посчитать AllRoutes из одной вершины.
G>Ну так скинь сюда файл. На нем и будем забеги устраивать.

Тестовый файл есть только для полной структуры которая тебе без толку. Я же специально упростил структуру до предела

interface Vertex
{
  ...
  IEnumerable<Vertex> Connections {get;}
  ...
}

I>>У меня есть оптимизирования версия, которая работает почти так же быстро как и С++ версия

Хочешь сравнить всерьез — это сильно легко.
G>Нивопрос, я тоже могу ченить соптимизировать.

Конечно, linq тебе придется выбросить и ты придешь почти к той же форме, которую я тебе подкинул

И в любом случае js версия короче и понятнее.

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

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

I>>>находим все роуты из 1, получаем — (1,2),(1,2,3),(1,2,3,4),(1,4),(1,4,3),(1,4,3,2)
G>>Ты и не пытался объяснить что такое роуты

I>Да очевидно — маршруты. В английском они называются path или route.

Не прячь знания за терминологией. Объясни по-русски что это такое.

I>>>Очевидно, ни одна твоя функция этот тест не проходит

Ты в курсе, что bfs эту задачу не решает ?

G>>Я тебе уже говорил чтобы ты сформулировал решение в проверяемом виде.

G>>Ты написал только это:
G>>

G>>находит и возвращает все вертексы достижимые из заданного.

I>Это первая задача, с ней ты справился

Вау...

G>>Я тебе привел два с половиной варианта, все они делают то что написано выше.
G>>Так что не выкручивайся теперь.
I>первую задачу ты решил, а на второй — загруз

Так ты её не сформулировал

I>>>А это реальная задача

G>>Нет, реальная задача имеет некоторый value для пользователя. В поиске всех роутов я value не вижу.

I>Ну вот смотри, нужно найти наилучшую схему доставки(снова упрощаю, что бы было понятно). Наилучшую — скажем, оптимальную по надежности, стоимости, длине, покрытию, количеству элементов в пути. Эту задачу дополняем целевой функцией, можно приближенной, фильтруем выход AllRoutes и, вуаля, наилучшая схема доставки найдена.
Ок
1)Граф связей между точками
2)Многозначная функция весов между узлами графа
3)Целевая функция, которая берет множество значений весов и возвращает число
4)Нужно найти такую такую последовательность точек между заданными начальной и конечной точкой, чтобы функция была минимальна

public static IEnumerable<IEnumerable<T>> DepthFirst<T>(T item, Func<T, IEnumerable<T>> adjacentNodes, Func<IStack<T>, bool> predicate)
{
    return DepthFirstImpl(ImmutableStack.Create(item), adjacentNodes, predicate).MemoizeAll();
}

private static IEnumerable<IStack<T>> DepthFirstImpl<T>(IStack<T> path, Func<T, IEnumerable<T>> adjacentNodes, Func<IStack<T>, bool> predicate)
{
    return (from n in adjacentNodes(path.Top)
            let pp = path.Push(n)
            where predicate(pp) //Вот тут самое интересное, если predicate возвращает false, то продолжение перебора по этому пути не идет
            from p in DepthFirstImpl(pp, adjacentNodes, predicate)
            select p)
            .StartWith(path);
}

public static IEnumerable<T> ShortestPath<T>(T from, T to, Func<T, IEnumerable<T>> adjacentNodes, Func<IEnumerable<T>, double> weight)
{
    var minWeights = new Dictionary<T, double>();
    var minWeight = double.MaxValue;
    IEnumerable<T> minPath = null;

    DepthFirst(from, adjacentNodes, path =>
        {
            var w = weight(path);
            double value = 0;
            if (w < minWeight && (!minWeights.TryGetValue(path.Top, out value) || w < value))
            {
                minWeights[path.Top] = w;
                if (to.Equals(path.Top))
                {
                    minPath = path;
                    minWeight = w;
                }
                return true;
            }
            return false;
        });

    return minPath;
}

При этом с небольшими изменениями можно распараллелить этот код.

I>>>Тестовые данные — полносвязный граф из 100 элементов — это что бы кольца были в наличии, из него удалить рандомом примерно 80% связей — что бы алгоритм закончился в разумное время. Далее посчитать AllRoutes из одной вершины.
G>>Ну так скинь сюда файл. На нем и будем забеги устраивать.

I>Тестовый файл есть только для полной структуры которая тебе без толку. Я же специально упростил структуру до предела
Для забегов нужны данные, а не "структура"

I>>>У меня есть оптимизирования версия, которая работает почти так же быстро как и С++ версия

Хочешь сравнить всерьез — это сильно легко.
G>>Нивопрос, я тоже могу ченить соптимизировать.

I>Конечно, linq тебе придется выбросить и ты придешь почти к той же форме, которую я тебе подкинул

И в любом случае js версия короче и понятнее.
Так покажи наконец js версию.

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

V>>Под ФП-стилем обычно подразумевают ориентацию в дизайне на работу с функциональными объектами. Т.е. ср-ва для создания оных, и ожидание их же в кач-ве аргументов в публичном АПИ.

I>А что такое функциональный объект ?

Это аналог первоклассной функции в ФП языках.

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

I>>Да очевидно — маршруты. В английском они называются path или route.
G>

G>Не прячь знания за терминологией. Объясни по-русски что это такое.

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

I>>Ну вот смотри, нужно найти наилучшую схему доставки(снова упрощаю, что бы было понятно). Наилучшую — скажем, оптимальную по надежности, стоимости, длине, покрытию, количеству элементов в пути. Эту задачу дополняем целевой функцией, можно приближенной, фильтруем выход AllRoutes и, вуаля, наилучшая схема доставки найдена.
G>Ок
G>1)Граф связей между точками

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

G>2)Многозначная функция весов между узлами графа

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

G>3)Целевая функция, которая берет множество значений весов и возвращает число

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

G>4)Нужно найти такую такую последовательность точек между заданными начальной и конечной точкой, чтобы функция была минимальна

где ты взял конечную точку

? Я про это ничего не говорил. Ищется схема доставки, а не один путь доставки. В качестве объяснения — один склад товара на страну и одноразовые курьеры мотаются от склада к клиентам.

В задаче нужно найти покрытие для которого функция минимальна

Очевидно — задача слишком сложная, что бы мерять её ради форумной баталии. Потому я предложил тебе упрощенный случай — только первую фазу, поиск всех маршрутов.
G>При этом с небольшими изменениями можно распараллелить этот код.

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

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

I>>Тестовый файл есть только для полной структуры которая тебе без толку. Я же специально упростил структуру до предела
G>Для забегов нужны данные, а не "структура"

Я вроде описал, как можно сгенерировать эти данные, строишь т.н. турнир, см. вики про орграфы, удаляешь 80-90% связей.

I>>Конечно, linq тебе придется выбросить и ты придешь почти к той же форме, которую я тебе подкинул

И в любом случае js версия короче и понятнее.
G>Так покажи наконец js версию.

Нет её под рукой

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

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

Вот тебе реальный "боевой пример":

#include "Fsm.h"
#include "ServerInstance.h"

typedef void Callback(ServerInstance*);

enum Signal { 
    success, hello, login, alert, net_error, 
    max_signal_N 
};

typedef State<Signal, max_signal_N, Callback> ServerState;

// Forwards
extern ServerState 
    init, wait_hello, hello_reply, wait_login, check_login, login_reply, working, send_alert, closing, closed;

const Signal other = max_signal_N;

ServerState 
    init        = { onInit,       { success>wait_hello, other>closed } },
    wait_hello  = { NULL,         { hello>hello_reply, other>closing } },
    hello_reply = { onHelloReply, { success>wait_login, other>closing } },
    wait_login  = { NULL,         { login>check_login, net_error>closing, other>send_alert } },
    check_login = { onLogin,      { success>login_reply, other>send_alert } },
    login_reply = { onLoginReply, { success>working, other>closing } },
    working     = { NULL,         { alert>closing, net_error>closing, other>send_alert } },
    send_alert  = { onSendAlert,  { other>closing } },
    closing     = { onClosing,    { other>closed } },
    closed      = { onClosed,     {} };

Fsm<ServerState> fsm(&init);

int main(int argc, char* argv[])
{
    try {
        ServerInstance server(argc, argv);
        server.run(&fsm);
    } catch(const std::exception &ex) {
        cerr << "Error: " << ex.what();
    }

  return 0;
}

Определения Callback, Signal и ServerState были скопированы из ProtocolController.h для полноты картины. В нем реакция на события и генерирование входных сигналов для автомата.
Fsm.h сделан однократно много лет назад и постоянно используется.

В общем, возможность переопределения операторов позволяют сделать синтаксис более-менее декларативным в C++.

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

V>>>Под ФП-стилем обычно подразумевают ориентацию в дизайне на работу с функциональными объектами. Т.е. ср-ва для создания оных, и ожидание их же в кач-ве аргументов в публичном АПИ.

I>>А что такое функциональный объект ?

V>Это аналог первоклассной функции в ФП языках.

Т.е. это нечто, что выглядит как функция, но ею не является и по этой причине вводит в заблуждение + затрудняет понимание — это как раз про СТЛ и БУСТ.

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

V>Вот тебе реальный "боевой пример":
...
V>В общем, возможность переопределения операторов позволяют сделать синтаксис более-менее декларативным в C++.

В декларативном стиле и ФП-стиле это чуток разные вещи. С декларативным я согласен. С ФП — категорически нет.

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

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

G>>При этом с небольшими изменениями можно распараллелить этот код.

I>Код я скипнул, потому что ты поторопился с решением. В этой функции нельзя заранее отсекать варианты

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

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

Кстати с чего все началось: для обхода графов вполне достаточно Linq и комбинаторов.

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

I>>>Там кривое изложение.
НС>>Давай источник с прямым.

I>Joshua Kerievsky

Нет, ты определение давай. Или предлагаешь мне все сочинения этого автора перечитать?

I>Покажи мне решение для общего случая без двойной диспетчеризации.

Что значит "для общего случая" и где я такое обещал?

I>а визитор это вроде обфускации, что бы gandjustasа проверить.

Ясно, как обычно. Больше вопросов не имею.

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

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

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

Это уход от вопроса.

V>Лишь обращаю внимание, что рассматриваемый трюк — частный случай более общего

Зачем?

V> Поэтому уверен, что полезней понимать общую концепцию.

Возможно. Но к чему ты это?

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

Ссылку в студию.

НС>>Ссылку на такое определение — в студию.

V>Хорошая ссылка на гугл уже дана.

Ссылка в гугль эквивалентна посыланию на три или пять букв.

НС>>ПОка что словесная муть у тебя, потому что не подкреплена ни одной ссылкой.

V>Угу, по википедии шпарить мы можем, а вправо-влево по теме не можем... серьезней надо.

Тем не менее выделенное — чистая правда.

НС>>Это от того, что кое кто жонглирует терминами.

V>Похоже, требуется для начала дать определение термину "жонглирование терминами".

Какая красота.

V>Например, именно ввиду упомянутого возможна обобщенная библиотечная реализация паттерна визитор в C++, в то время как в дотнете библиотечная реализация этого паттерна принципиально невозможна.

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

НС>Это не паттерн Visitor, а какая то фигня. Паттерн используется, когда нужна диспетчеризация по типам с общим корнем.
На статическом полиморфизме визитор тоже прекрасно работает, например в С++.

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

V>Вообще-то, это принципиально для случая "внешнего" обхода

Ять! Визитор предназначен для внешнего "подключения" алгоритма. По определению! Слово "обход" у тебя, кстати, очень показательно.

V>, например через итераторы. Если же посещаемый "черный ящик" инкапсулирует логику обхода (а оно почти всегда так), то это не принципиально. В интернете есть разъяснения как первого варианта реализации визитора, так и второго. И пока не видел, чтобы кто-то считал один из вариантов более "визитёристым", чем другой. Фактически, ты первый, со своей принципиальностью.

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

V>И как теперь с тобой вести дискуссию?

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

V> По твоей логике здесь тоже должны быть принципиально виртуальные ф-ии

Это по твоей логике.

V>, ведь в GOF описана ситуация, когда оба участника паттерна являются абстрактными.

В GoF есть еще и определение паттерна. Перечитай.

V> Совершенно не понимаю твоей логики, почему одну часть паттерна можно модифицировать, а другую нельзя.

Модифицировать можно что угодно. Но если после этого определение (не пример, а именно определение) перестает подходить, то оно перестает быть визитором. Все очень просто.

V>ИМХО, ключевое во всей этой теме и корень взаимонепонимания — это рантайм полиморфизм, используемый при определении конкретного вызываемого метода посетителя.

Это не корень взаимонепонимания, а кое кто не потрудился понять, на что же он все таки отвечал.

V>Другое дело, что такой полиморфизм может быть реализован в некоторых языках без техники виртуальных ф-ий.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

Если взять boost::variant там динамическая диспетчеризация конечно присутствует, правда виртуальных вызовов нет,
есть банальный switch в потрохах. Но это же не мешает сделать подобный visitor полностью отрабатывающий в compile
time в том же C++ или проще в D, понятно что в рантайме будет доступен только результат его работы. В том же D
наверняка можно сделать код который будет одинаков что в рантайме что в компилтайме.
По моему все эти разделения весьма зыбки и шатки, и не думаю что именно динамическая диспетчеризация позволит
отличить визитор от невизитора.

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

DG>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом

Так так, сейчас я сделаю выброс на вентилятор =)

И так, Делфи это не только Борланд или кодегеар, это не только 500$ за минимальную лицензию, это не только Windows зависимость, но это также opensource компилятор FreePascal под win, mac, linux, iphone и другие платформы, это также opensoucre IDE Lazarus со своей системой библиотек GUI, которая обеспечивает кроссплатформенность без свистоплясок. Нужен тебе gui на основе GTK, QT, WinAPI и др. не проблема, библиотека LCL настолько уникальна, что позволяет без изменения кода легко переходит от GTK к QT и т.п. Ну что соснули? Пока вы тут пишите на Qt Creator'e хвастаясь кроссплатформенностью, Lazarus уделал вас по полной, он не зависит от какого-то тул-кита. А FreePascal уделал си++ по скорости компиляции, по организации модулей. Хвастаетесь крутыми фишками в ООП си++? Многие эти фишки красиво реализованы в freepascal. Что еще говорить о встроенном сборщике мусора для типа String в freepascal и delphi? Конечно сейчас начнется кидание библиотеками.

Freepascal умеет статически линковать объектные файлы gcc, любой код написанный на gcc может быть легко присоединен статически к приложениям на фрипаскаль.

СИ++ это настоящий костыль над костылем, Страуструп соответствует своей фамилии, потому что его книги ужасны, по ним становится понятно, что у самого автора в голове творится самый настоящий бардак, такой же бардак творится и в стандарте си++. СИ жив только благодаря linux'у, да и потому что альтернатив компилируемых языков можно сосчитать по пальцам, что кроме freepascal может придти в голову? такое же кроссплатформенное и развивающеся?

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

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.01.11 10:29
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	28.01.11 11:38
Оценка:

	От:	vdimas
	Дата:	28.01.11 12:39
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.01.11 13:47
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	28.01.11 14:53
Оценка:

	От:	Ночной Смотрящий
	Дата:	29.01.11 01:36
	Оценка: