Здравствуйте, FR, Вы писали:
FR>Все-таки паттерн матчинг вещь в хозяйстве полезная, неплохо было бы если бы его ввели в питон, да и в руби бы не помешал, притом для ввода например в питон даже не надо больших уж затрат и ломки старого кода, достаточно одного ключевого слова. Ну а пока не ввели, я тут играюсь библиотечными методами, вот например такой эскизик сегодня нарисовал:
Здравствуйте, FR, Вы писали:
FR>Угу это скорее ближе к мультиметодам, но упрощает решение тех же задач что паттерн матчинг. FR>При желании можно и связывание переменных добавить. FR>А струкуры и сейчас вполне разбираются, аргументом может быть любой логический предикат, при его истиности вызывается связанная функция
Предикат — это не то. Что я буду тебе рассказывать, ты ведь с Хаскелем игрался. Как такое на Питоне изобразить (объединение множеств из стандартной библиотеки Окамла):
let rec union s1 s2 =
match (s1, s2) with
(Empty, t2) -> t2
| (t1, Empty) -> t1
| (Node(l1, v1, r1, h1), Node(l2, v2, r2, h2)) ->
if h1 >= h2 then
if h2 = 1 then add v2 s1 else begin
let (l2, _, r2) = split v1 s2 in
join (union l1 l2) v1 (union r1 r2)
end
else
if h1 = 1 then add v1 s2 else begin
let (l1, _, r1) = split v2 s1 in
join (union l1 l2) v2 (union r1 r2)
end
Здравствуйте, Programmierer AG, Вы писали:
PA>Здравствуйте, FR, Вы писали:
FR>>Угу это скорее ближе к мультиметодам, но упрощает решение тех же задач что паттерн матчинг. FR>>При желании можно и связывание переменных добавить. FR>>А струкуры и сейчас вполне разбираются, аргументом может быть любой логический предикат, при его истиности вызывается связанная функция PA>Предикат — это не то. Что я буду тебе рассказывать, ты ведь с Хаскелем игрался. Как такое на Питоне изобразить (объединение множеств из стандартной библиотеки Окамла):
Просто структуры данных питона очень плохо приспособленны для сопоставления с образцом. Но в принципе решаемо вводом новых типов, с которыми сможет работать сопоставление (аналог variant из nemerle) и плюс адаптеров к встроенным спискам, туплам и т. п. Но это слишком трудоемко Поэтому мне пока более интересно возится с аналогами мультиметодов, они с одной стороны слабее pattern matching'а c другой наооборот мощнее.
Здравствуйте, eao197, Вы писали:
E>Кстати, Андрей, вопрос в offtopic, а на Smalltalk не GUI-приложения вообще делают, server-side такой жесткий, черный ящик? Не web, про Seaside я знаю.
Чисто теоретически — никаких ограничений. Для VW идут сразу "безголовые" билды ВМ, то есть ВМ не умеющие работать с графикой. В доке описаны особенности изготовления безголовых приложений и особенности прикручивания к ним гуя назад.
Для Squeak есть опция командной строки, с которой он запускается в безоконном режиме. Хотя там, как я понимаю, фреймбуфер егойный инициализируется всё равно. Кстати, для администрирования удалённых Squeak приложений сделали имплементацию протокола VNC. Типа берёш обычный клиент, подключаешся и смотриш всё, что тебе нужно. Полноту реализиции протокола не знаю, но люди ним практически пользуются.
Здравствуйте, eao197, Вы писали:
E>Да самый настоящий. Но это как бы дань моде. Интересно было еще про примеры узнать.
На счет не уеб-примеров — это всё таки "заказные" системы. Врядли о них много говорят. Хотя, к примеру, система, которую Бек разрабатывал для Крайслера в замен майнфреймовой системы в предверье миллениума (это с чего началось экстремальное программирование, afair). Сомневаюсь, что это было гуи-приложение. Система управления заводом по производству чипов — опять же, деталей нет но есть стойкое подозрение, что там есть и сервер-сайд компоненты.
Что касается инфраструктуры, то в VW всё есть — и интеграция с CORBA, и облегченный протокол для ST-ST связи и уеб-сервисы. Думаю, что VA тоже не страдает отсутсвием инфраструктуры.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что касается инфраструктуры, то в VW всё есть — и интеграция с CORBA, и облегченный протокол для ST-ST связи и уеб-сервисы. Думаю, что VA тоже не страдает отсутсвием инфраструктуры.
Кстати, все доки по VW тут. Изготовление "безголовых" приложений описано в DevGuide. Глава "Creating an Application without a GUI".
В главе "Refactoring" описаны доступные рефакторинги. Это просил Влад, а я забыл сразу ему ссылку кинуть. (Сейчас прочитает и начнёт опять меня в обмане уличать ). Там же было описание Rewrite Rules — "языка" для модификации кода, разработанного Беком в далёком 96гг вместе с RefactoringBrowser-ом, но сейчас я не могу его найти.
Здравствуйте, Denis2005, Вы писали:
D>Понять жизнь можно лишь оглядываясь назад, но жить-то приходится, смотря вперед. (C) Сёрен Кьеркегор
Не тот случай. Как раз С++ делает то, что давно (очень, 30 лет назад) было сделано в других языках. В частности в Лиспе.
D>Была избрана такая политика, чтобы помаксимому давить на библиотеки, т.к. язык и без того слишком сложный и многими местами противоричивый.
Язык особой сложностью не обладает. Даже C# имеет более сложный синтаксис и порой более сложную семантику. А вот противоричивость — это да. Что есть того не отнять. Только это даеко не плюс. Это огромный минус. Именно это, и то что язык пытаются расширять не штатнными средствами и приводит к повышению сложности языка. Причем совершенно не поравданной сложности, заметь.
D>Ты же знаешь, сколько времени нужно WG21 X3J16 чтобы принят то или иное решение, особенно если оно касается расширений.
И чьи это проблемы? Это проблемы тех кто сделал ужасный стандарт в 1993-ем и не хотят исправлять своих ошибок сегодня.
D>А сколько пройдет когда реальными компиляторами будет поддерживаться введеное расширение?
Опять же это проблемы дизайна языка. Противоричивость и кривизна его дизайна усложняют компиляторщикам жизнь. Отсюда и задержки. Хотя с последнего стандарта прошло 13 лет. За это время черта лсого можно было сделать. Так что факт недареализованности стандарта основными компиляторами скорее говорит об избыточности и непродуманности стандарта.
Учитывая то что 3 года достаточно для разработки языка с нуля, проблемы С++-ных комитетчиков вообще выглядят очень странно.
D>Вот с библиотекой дела обстоят немного попроще, поэтому на них и делается основной упор.
В библиотеках как мы видим все очень печально. Они просто не могут прыгнуть выше головы. С++ не обладает штатными средствами расширения (за исключением убогих макросов), что приводит к использованию неполноценных нештатных средств. Результат при этом получается удручающий. Ужасное время на компиляцию. Невозможность реализации задуманного на 100%. Ужасно сложная отладка. Никакие сообщения об ошибках. И в добавок огромнеший геморрой при попытках сделать код совместимым с компиляторами разных производителей. В общем, я бы оценил это положение дел как ужасающее.
D>'Горбатый' еще задаст жару молодым неокрепшим умам
Он уже никому ничего не задаст. Он давно перешел в разряд битомолотилки с избыточным синтаксисом. Не удивлюсь если через 10 лет С буедет иметь большую популяроность чем С++.
Сегодняшняя же популярность обуславливается только двумя факторами охринительной разрекламмированностью и человеческими привычками. Они еще долго будут держать С++ в фаворитакх. Вот только проивзодительность руда программистов на этом языке крайне низка. Особенно если речь вести о высококлассных специалистах. И использовать его себе могут позволить только очень богатые конторы (вроде МС и Сана, ну, на худой конец как-нить наш СиБосс и то он себе вубыток работает). Маленькая же контора используя С++ надевает на себя огромный гандикап.
VD>>"Обычными"? Это где они слали обычными? Что-то я такого чуда природы в языках с функциями высшего прядка вообще не видел. И знаешь, мне кажется, что это потому, что фанкторы на фиг не упали.
D>Я сказал обычно, и применительно для C++. В C# 2.0 нормально обхожусь анонимными делегатами.
Вот вот. А C# 2.0 анонимные методы чудовищьно неудобны. Вот в C# 3.0 другое дело.
Так что фанкторы — это самопальный костыль заменяющий то что требуется людям. А бусты — это попытка придать этому костылю приличный вид. Не очень удачная, надо сказать, попытка.
VD>>А зачем они нужны? В функциональных языках все обходятся одновсязанным списком, который так и называется "список". VD>>Если в коде присуствует vec.begin() и vec.end() — это уже избыточный код. Ведь работа ведется со всем списком и отдельно указывать его голову так же глупо как на вопрос о расстоянии до объекта начинать давать его координаты и координаты место где ты находишся.
D>За всех говорит не стоит. Частенько бывает, что работа ведется с определенными фрагментами коллекции.
Что значит за всех? Это банальный логический вывод. Если в коде есть vec.begin() и vec.end() одновременно, то это точно перебор всего списка. А раз так, то это явно избыточный код, так как в нем достаточно было бы указать просто "vec".
D>Хотя там где производительность особо не важна, можно и полными списками погонять.
Извини, но твои рассуждения о производительности звучат очень несерьезно. Производительность определяется в первую очередь качеством алогоритмов, и как показла эта тема библиотек (по сути их алгоритмов). И как видишь используя бусты можно спокойно не догадываясь об этом получить низко-эффективный код на казалось бы "таком быстром языке".
В функциональных языках работа со списками является чуть ли не основой возможностью и там давно пришли к выводу, что опереровать нужно понятием "список", а не "открезок". Если есть списко в котором лежат лишние элементы, то сначал проще отфильровать нужные элеметы, а потом уже обработать новый списко. Эффективность от этого нисколько не пострадает.
VD>>В общем, С++, точнее его создатели, нарушили один очень важный принцип KISS. И это его погубит. А пока он не умер, можно извлечь пользу для сбея и своей конторы перейдя на более продуктивный язык и набляюдая как туча ежиков колются, плачут но продолжают с упоением жрать это кактус.
D> D>Сам пишу пот .NET уже > 4 лет, если задача позволяет, поэтому про ежиков заканчивай.
А что же так? Писали бы на С++. С ним ведь все так здорово!
И ведь донет с C# далеко не лидеры в области выразительности. Сравнение с ним С++ хотя и вглядит тормозом разрабоки, но все же еще как-то смотрится. А вот по сравнению с новыми гибридами вроде Скалы и Немерла он выглядит как недоразумение. Хотя и по сравнению с функциональными языками прошлого вроде Лиспа или ОКамла он тоже выглядит не очень здорово.
Что до "задача позволяет", то лично у меня вообще нет задач которые бы не позволяли использовать дотнет. Думаю, что большинство людей просто недооценивает его (и Явы) возможности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: BOOST, .NET, String.Split и производительность…
Здравствуйте, McSeem2, Вы писали:
MS>Разница в том, что C# не вызывает ntdll по isspace (или какой там аналог?). А сишная библиотека от MS по кой-то фиг вызывает (ну или вызывала, не знаю как оно сейчас).
От МС? А что же тогда на Линусе 20 секунд в лучшем случае? Там тоже МС с ntdll накосявила?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>А струкуры и сейчас вполне разбираются, аргументом может быть любой логический предикат, при его истиности вызывается связанная функция
Ты не понял. Паттерн не всегда являюется придикатом. Даже скажу больше. Хороший паттерн всегд не предикат. Паттерн это описание структуры данных с возможносью задать метапеременные (то есть части этой структуры выразить как wildcards).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Просто структуры данных питона очень плохо приспособленны для сопоставления с образцом.
Не "просто", это одна из проблем. Почему ты думаешь при разговоре о паттерн-матчинге все время всплывают алгеброические типы данных (варинаты)? Именно потому, что они сделаны так чтобы по ним можно было делать сложный паттерн-матчинг. Но их наличие это еще не все. Еще нужен ээ... думатель (как точно подметил Ц-Смаил). Этот думатель должен преобразовать паттерн в набор логических предикатов. Это нехилый алгоритм. В Немерле его тупо скомуниздили из одной из реализаций ML-я. Его уже так на коленке не напишишь. Да и в рантайме его отрабатывать слишком накладно.
FR>Но в принципе решаемо вводом новых типов, с которыми сможет работать сопоставление (аналог variant из nemerle) и плюс адаптеров к встроенным спискам, туплам и т. п. Но это слишком трудоемко Поэтому мне пока более интересно возится с аналогами мультиметодов, они с одной стороны слабее pattern matching'а c другой наооборот мощнее.
В принципе все решаемо. Только это будет уже не Питон, а Гюрза или еще что-то. И решать конечно такие вещи лучше на уровне компилятора, а не на уровне интепретируемого в рантайме метапрограммирования.
Пойми, паттерн-матчинг только выглядит просто. А внтри это довольно высокотезнологичные алгоритмы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>В главе "Refactoring" описаны доступные рефакторинги. Это просил Влад, а я забыл сразу ему ссылку кинуть. (Сейчас прочитает и начнёт опять меня в обмане уличать ).
О! Не прошло и года. Списибо!
Тогда сразу вопрос. Возьмем к примеру:
Renaming a Method and its References To rename all implementors of a method, all senders, and all symbols
references, select Rename... from the Method menu.
In addition to strict renaming, this refactoring operation also enables you
to rearrange the method’s parameters. However, when rearranging the
parameters, any symbols that are performed cannot be permuted.
Правильно ли я понял эти строки, что можно переименовывать только все методы с одинаковым мменем во всех классах одновременно? Или все же можно изменить имя метода в одном классе и оставить без изменений другие методы с тем же именем и списком параметров?
Предполжим у мея есть кассы A и B. В обоих содержатся метод MyMethod. Можно ли переименовать метод в классе A на MyMethodEx не трокая метода из класса B и соотвественно корретно исправить все ссылки на переименованный метод.
Если это возможно, то второй вопрос. Как среда отделяет вызовы методов в случае когда например, объект передается в качестве параметра и не ясно что за тип будет у этого объекта?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: BOOST, .NET, String.Split и производительность…
Здравствуйте, VladD2, Вы писали:
VD>Не тот случай. Как раз С++ делает то, что давно (очень, 30 лет назад) было сделано в других языках. В частности в Лиспе.
Лисп и С++ создавались для несколько разных целей.
Как говорил Деннис Ричи: "Одни языки создаются для решения задачи, другие для — доказания той или иной точки зрения".
Лисп более относится к последней группы и писать на нем, мягко говоря по труднее чем на С++.
D>>Ты же знаешь, сколько времени нужно WG21 X3J16 чтобы принят то или иное решение, особенно если оно касается расширений. VD>И чьи это проблемы? Это проблемы тех кто сделал ужасный стандарт в 1993-ем и не хотят исправлять своих ошибок сегодня.
Как ты предлагаешь исправлять их сегодня? Расширять язык или быть может чего убрать из него, что приведет к еще большей не совместимости, несмотря на то, что сейчас она уже просто чудовищная.
VD>Учитывая то что 3 года достаточно для разработки языка с нуля, проблемы С++-ных комитетчиков вообще выглядят очень странно.
Я так понимаю ты плохо знаком со стандартом и хронологией его развития.
Кстати стоит учитывать, что это сейчас при уже имеющемся опыте достаточно 3-х лет, но как говорится "всяк силен задним умом".
Проблема у комитетчиков одна, не развалить до конца, чего и так шатается.
VD>В библиотеках как мы видим все очень печально. Они просто не могут прыгнуть выше головы. С++ не обладает штатными средствами расширения (за исключением убогих макросов), что приводит к использованию неполноценных нештатных средств. Результат при этом получается удручающий. Ужасное время на компиляцию. Невозможность реализации задуманного на 100%. Ужасно сложная отладка. Никакие сообщения об ошибках. И в добавок огромнеший геморрой при попытках сделать код совместимым с компиляторами разных производителей. В общем, я бы оценил это положение дел как ужасающее.
Об этом много раз уже говорили. Язык сложен, противоречив и т.д. Не нравиться — не пиши, только зачем кричать об этом на каждом углу.
VD>Он уже никому ничего не задаст. Он давно перешел в разряд битомолотилки с избыточным синтаксисом. Не удивлюсь если через 10 лет С буедет иметь большую популяроность чем С++.
VD>Сегодняшняя же популярность обуславливается только двумя факторами охринительной разрекламмированностью и человеческими привычками. Они еще долго будут держать С++ в фаворитакх. Вот только проивзодительность руда программистов на этом языке крайне низка. Особенно если речь вести о высококлассных специалистах. И использовать его себе могут позволить только очень богатые конторы (вроде МС и Сана, ну, на худой конец как-нить наш СиБосс и то он себе вубыток работает). Маленькая же контора используя С++ надевает на себя огромный гандикап.
VD>Вот вот. А C# 2.0 анонимные методы чудовищьно неудобны. Вот в C# 3.0 другое дело.
VD>Так что фанкторы — это самопальный костыль заменяющий то что требуется людям. А бусты — это попытка придать этому костылю приличный вид. Не очень удачная, надо сказать, попытка.
Слишком консервативное заявление, ведь многое зависит от размера/сложности функтора. Да и про декомпозицию не стоит забывать.
если func — что-то типа выражения {a + _1}, то действительно функтор может быть избыточен.
D>>За всех говорит не стоит. Частенько бывает, что работа ведется с определенными фрагментами коллекции. VD>Что значит за всех? Это банальный логический вывод. Если в коде есть vec.begin() и vec.end() одновременно, то это точно перебор всего списка. А раз так, то это явно избыточный код, так как в нем достаточно было бы указать просто "vec".
Если уж так хочется, то напиши функцию которая будет инкапсулировать begin()/end().
VD>А что же так? Писали бы на С++. С ним ведь все так здорово! VD>И ведь донет с C# далеко не лидеры в области выразительности. Сравнение с ним С++ хотя и вглядит тормозом разрабоки, но все же еще как-то смотрится. А вот по сравнению с новыми гибридами вроде Скалы и Немерла он выглядит как недоразумение. Хотя и по сравнению с функциональными языками прошлого вроде Лиспа или ОКамла он тоже выглядит не очень здорово.
Есть задачи которые удобно писать под .NET, и на более простом языке типа C#. Особенно это важно в командных проектах.
VD>Что до "задача позволяет", то лично у меня вообще нет задач которые бы не позволяли использовать дотнет. Думаю, что большинство людей просто недооценивает его (и Явы) возможности.
Попробуй пописать на .NET под GBA (Game Boy Advance) или Nintendo DS, или его где нибудь где он просто не применим.
Mono — не предлагать, по любому ресурсов у обозначенных выше аппаратов не хватит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: BOOST, .NET, String.Split и производительность…
Ну, раз пошла такая пьянка грех не порекламировать Nemerle .
Вот написал это никчемный тестик. Причем разными спосбами чтобы оценить насколько дорого обходится функционалщина и другие хайтек-изыски в современных языках. Особенноп риятно этот тест сравнивать с вот этоим произведением человеческой мысли .
Первый результат — это рукописный Split возвращающий (какой ужас!) динамический списко (то есть на каждый жлемент списка создается по дополнительному объекту с указателем на следующий элемент. Размет каждого доп. объекта 16 байт). Ко всему прочему этот метод строит прямой список для чего ему приходится использовать стек (не использовать концевую рекурсию). Так же для вычисления длинны списка свойство Length делет (ужас то какой!) еще один проход по списку.
Второй результат — это токенайзер возвращающий позицию токена. Интересен он тем, что использует конструкцию yield (то есть является континюэшоном).
Третий результат — это библиотечный метод Split().
А теперь код:
using System.Console;
using System.Diagnostics.Stopwatch;
module Parse
{
public Split(this str : string) : list[string]
{
def loop(start, i, lst)
{
if (i < str.Length)
match (str[i])
{
| ' ' | '\t' => str.Substring(start, i - start) :: loop(i + 1, i + 1, lst)
| _ => loop(start, i + 1, lst)
}
else if (start == i) lst
else [str.Substring(start, i - start)];
}
loop(0, 0, []);
}
public Tokenize(this str : string) : System.Collections.Generic.IEnumerable[(int * int)]
{
def loop(start, i)
{
if (i < str.Length)
match (str[i])
{
| ' ' | '\t' =>
yield (start, i - start);
loop(i + 1, i + 1)
| _ => loop(start, i + 1)
}
else if (start != i) yield (start, i - start)
else ()
}
loop(0, 0);
}
}
////////////////////////// Далее идут тесты /////////////////////////////////
WriteLine(Parse.Split("123 345 asdf 23453 asdfas"));
/////////////////////////////////////////////////////////////////////////////
// Тестируем сплит написанный что называется в стиле "мама не горюй" (с динамическими списками).
def timer = StartNew();
mutable count = 0;
for(mutable i = 0; i < 1000000; ++i)
count += Parse.Split("123 345 asdf 23453 asdfas").Length;
WriteLine(timer.Elapsed);
WriteLine(count);
/////////////////////////////////////////////////////////////////////////////
// Тестируем бибилиотечный сплит.
def timer = StartNew();
count = 0;
for(mutable i = 0; i < 1000000; ++i)
foreach (_ in Parse.Tokenize("123 345 asdf 23453 asdfas"))
count++;
WriteLine(timer.Elapsed);
WriteLine(count);
/////////////////////////////////////////////////////////////////////////////
// Тестируем токенайзер.
def timer = StartNew();
count = 0;
for(mutable i = 0; i < 1000000; ++i)
count += "123 345 asdf 23453 asdfas".Split().Length;
WriteLine(timer.Elapsed);
WriteLine(count);
_ = ReadLine();
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: BOOST, .NET, String.Split и производительность…
Здравствуйте, Denis2005, Вы писали:
D>Лисп и С++ создавались для несколько разных целей. D>Как говорил Деннис Ричи: "Одни языки создаются для решения задачи, другие для — доказания той или иной точки зрения".
А какое отношение Ричи и его миниатюрнинький язычек имеет к С++ и его монструозным порождениям вроде буста?
D>Лисп более относится к последней группы и писать на нем, мягко говоря по труднее чем на С++.
Ой, держите меня семеро. Я сейчас стану защитником Лиспа.
Ты меня извини, то на Лиспе писать то что есть в бусте в 100 раз проще. Язык банально создан для таких вещей. В метапрограммировании он один из лучших.
Как раз Лисп, по твоим словам "созданный для доказания той или иной точки зрения" прекрасно реализует идею "расширения языка за счет библиотек". А С++ тут выглядит очень убого.
D>Как ты предлагаешь исправлять их сегодня? Расширять язык или быть может чего убрать из него, что приведет к еще большей не совместимости, несмотря на то, что сейчас она уже просто чудовищная.
Элементарно, Ватсон (с). Добавить в язык то что люди безуспешно пытаются прикрутить к нему через одно место. Совместимость от этого не пострадает. К тому же можно ввести некие режимы. Например, в C# можно писать опасный код, но для этого нужно сказтаь об этом компилятору.
D>Я так понимаю ты плохо знаком со стандартом и хронологией его развития.
Да, да. Всегда проще найти проблему в оппоненте. Не признавать же свою неравоту?
D>Кстати стоит учитывать, что это сейчас при уже имеющемся опыте достаточно 3-х лет, но как говорится "всяк силен задним умом".
А что сейчас то изменеилось? Что опыт доступен только избранным? Что мешало проанализировать его 3, 6, 9 лет назад? Он же был. И он никуда не делся и сейчас. Стандарт 0x явно подразумевает что x — это римская 10. Так что время еще есть. Как раз можно успеть к 10-му году если начать работать уже сейчас.
D>Проблема у комитетчиков одна, не развалить до конца, чего и так шатается.
Мне кажется для языка опаснее оставлять все как есть.
D>Об этом много раз уже говорили. Язык сложен, противоречив и т.д. Не нравиться — не пиши, только зачем кричать об этом на каждом углу.
Не нравится. Не пишу. Уже давно. Лет 5 как...
VD>>Так что фанкторы — это самопальный костыль заменяющий то что требуется людям. А бусты — это попытка придать этому костылю приличный вид. Не очень удачная, надо сказать, попытка.
D>Слишком консервативное заявление, ведь многое зависит от размера/сложности функтора. Да и про декомпозицию не стоит забывать.
Ничего от размера не зависит. Достаточно месяцок пописать на языке с функциями высшего порядка и поймешь, что фанкторы это костыль. Причем неудобный.
D>Псевдокод: D>
D>если func — что-то типа выражения {a + _1}, то действительно функтор может быть избыточен.
Это еще одна ересь навиваемая С-шными корнями. В современных языках отказваются от указателей вообще. То как передавть объект или фунцию должен определять компилятор и/или рантайм. Если они умны, то без проблем могут вообще устранить сам факт передачи. Ведь код в конечном итоге не более чем инструкции процессора, то есть байты/биты.
D>Если уж так хочется, то напиши функцию которая будет инкапсулировать begin()/end().
А почему ее не написали в библиотеке? Да и как эту инкапсуляцию передавть в те самые функции STD и буста?
D>Есть задачи которые удобно писать под .NET, и на более простом языке типа C#. Особенно это важно в командных проектах.
Ага. Не спорю. Но какие задачи тебе удобно писать на С++? Не уж то ты драйверы пишешь?
D>Попробуй пописать на .NET под GBA (Game Boy Advance) или Nintendo DS, или его где нибудь где он просто не применим.
А ты для них пишешь?
И что С++ это единственный выбор для этих платформ?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: BOOST, .NET, String.Split и производительность…
Здравствуйте, VladD2, Вы писали:
MS>>Разница в том, что C# не вызывает ntdll по isspace (или какой там аналог?). А сишная библиотека от MS по кой-то фиг вызывает (ну или вызывала, не знаю как оно сейчас).
VD>От МС? А что же тогда на Линусе 20 секунд в лучшем случае? Там тоже МС с ntdll накосявила?
Влад, ты слова читать умеешь? Напомню, что в моем сообщении речь шла о неком другом случае, а не о split. На Линухе он не проверялся.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[9]: BOOST, .NET, String.Split и производительность…
Здравствуйте, McSeem2, Вы писали:
MS>Влад, ты слова читать умеешь? Напомню, что в моем сообщении речь шла о неком другом случае, а не о split. На Линухе он не проверялся.
О како таком другом случае? Я просто уже второй раз тут вижу, что проблемы в МС. Очень интересна эта теория. Люблю, знаете ли, теорию заговора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>А струкуры и сейчас вполне разбираются, аргументом может быть любой логический предикат, при его истиности вызывается связанная функция
VD>Ты не понял. Паттерн не всегда являюется придикатом. Даже скажу больше. Хороший паттерн всегд не предикат. Паттерн это описание структуры данных с возможносью задать метапеременные (то есть части этой структуры выразить как wildcards).
Я знаю, пролог изучал правда давно и недавно игрался с языками с паттерн матчингом. Да и не зря я смайлик поставил
Вообще это скорее пример использования скажем так условных мультиметодов
А эта вещь только соприкасается с сопоставлением с образцом, хотя тоже вещь мощная.
Поэтому мне пока более интересно возится с аналогами мультиметодов, они с одной стороны слабее pattern matching'а c другой наооборот мощнее.
А что же тогда на Линусе 20 секунд в лучшем случае? Там тоже МС с ntdll накосявила?
