LINUX.ORG.RU

С++


0

1

Здравствуйте. Подскажите, есть ли для C++ в STL или BOOST функция аналогичная функции map в Haskell, Clean?

Ответ на: комментарий от TERRANZ

Применяет функцию в качестве первого аргумента к списку значений в качестве второго и возвращает измененный список.

vitkornle
() автор топика

Нет, нету. Использую C++0x можешь написать её сам.

KblCb ★★★★★
()
Ответ на: комментарий от Begemoth

>А что ж тогда Boost.Lambda?

Суррогат. Порой, выручает, конечно. Но нормальных замыканий всё равно не хватает

yoghurt ★★★★★
()
Ответ на: комментарий от Love5an

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

creepnee
()
Ответ на: комментарий от creepnee

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

Экспериментальный математический код или код со сложной вычислительной логикой я бы написал на хаскелле. Продакшн ънтерпрайз на Java, десктопный или системный софт на С. Административные скрипты на Perl или Python. Еще на Java пишу с

Но я бы не писал Ъ серверный софт на haskell, а всякие чистки логов, монтирования, бекапы, простые утилитки на С++

<holywar>

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

</holywar>

В этом языке они такие, какие они есть, по определенным причинам и все

C++-ники вообще любят чужие понятия подменять своими, ссылаясь на «определённые причины», да

korvin_ ★★★★★
()
Ответ на: комментарий от vertexua

> Экспериментальный математический код или код со сложной вычислительной логикой я бы написал на хаскелле. Продакшн ънтерпрайз на Java, десктопный или системный софт на С.

C в списке вижу, Java — вижу, Haskell — и тот вижу. А C++ не вижу...

kemm
()
Ответ на: комментарий от kemm

Хм... Он был на месте Haskell. Пока я не начал изучать Haskell. Теперь на него перейду. Так же вместе с С++ юзал Scala, всем был доволен, кроме как тормознутостью компилятора. Ждать достало >10 сек после каждого изменения кода

vertexua ★★★★★
()
Ответ на: комментарий от Booster

>Замыкания? Уже или в новом стандарте?

В новом конечно.

вот так:

// Определяем замыкание
struct inner_t {
    inner_t(my_type_t& arg, other_type_t& x): arg(arg), x(x) {}
    void operator() (type2_t y, type3_t z) {
        // Здесь вычисления и действия над arg, x, y, z
    }
    my_type_t& arg
    other_type_t& x;
} inner(arg, x);

// Примеряем замыкание
for (....) {
    type2_t y = ...
    type3_t z = ...
    inner(y, z);
}

?

korvin_ ★★★★★
()
Ответ на: комментарий от vertexua

> Тебе эта ссылочка как раз не помешает

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

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

C++-ники вообще любят чужие понятия подменять своими, ссылаясь на «определённые причины», да

Какие С++-ники?

Какие чужие понятия?

Каким образом подменять?

vertexua ★★★★★
()
Ответ на: комментарий от korvin_

Структура это по-вашему лямбда? Что-то новое. И вообще непонятно что вы хотели показать этим примером, странное какое-то у вас замыкание.

Booster ★★
()
Ответ на: комментарий от vertexua

Какие С++-ники?

всякие разные, то у них map не map, то функтор не функтор, теперь вот и замыкания какие-то свои, особенные, как Вы говорите

Какие чужие понятия?

вышеперечисленные, например.

Каким образом подменять?

прямым.

korvin_ ★★★★★
()
Ответ на: комментарий от Booster

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

не знаю, пример с какого-то сайта взял

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>всякие разные, то у них map не map, то функтор не функтор, теперь вот и замыкания какие-то свои, особенные, как Вы говорите

А лисперам больше придраться не к чему, кроме как к названиям функций?

creepnee
()
Ответ на: комментарий от creepnee

> А лисперам больше придраться не к чему, кроме как к названиям функций?

лисперам? не знаю, у них спросите

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

Нет, вот так:

#include <functional>
#include <iostream>

using namespace std;
typedef std::function<int (int, int)> Function;

void oper(Function f, int a, int b)
{
    cout << f(a, b) << endl;
}

int main()
{
    Function f1 = [](int a, int b) {
        int c = a + b;
        return c;
    };
    oper(f1, 5, 4);

    int c = 1;
    Function f2 = [=](int a, int b) {
        return c + a + b;
    };
    oper(f2, 2, 3);
}
creepnee
()
Ответ на: комментарий от korvin_

Хорошо, переформулирую более понятно: Вам больше придраться не к чемуу, кроме как к названиям функций?

creepnee
()
Ответ на: комментарий от Love5an

>Вопрос выделения памяти, в частности, и вопрос вида функции-обработчика.
В лиспе оно работает как-то супер оптимально и это не доступно С++? Смешно. Вообще это обычная, унылая, библиотечная функция, не вижу поводов для восхищения.

Booster ★★
()
Ответ на: комментарий от creepnee

ну это не совсем замыкание, замыкание, это вот:

#include <functional>
#include <iostream>

using namespace std;
typedef std::function<int (int)> Curried;
typedef std::function<int (int, int)> Operator;

Curried curry (int x, Operator op)
{
    return [x](int y) { return op( x, y ); };
}

Operator mul = [](int x, int y) { return x * y };

int main()
{
    for (int i = 1; i < 9; ++ i) {
        auto times = curry( mul, i );
        for (int j = 1; j < 9; ++j) {
            cout << times(j) << " ";
        cout << endl;
}

здесь times — замыкание

korvin_ ★★★★★
()
Ответ на: комментарий от Booster

> Смешно вас читать. Названия кем-то запатентованы?

названия общеприняты

korvin_ ★★★★★
()
Ответ на: комментарий от Booster

В Common Lisp оно работает в разы круче. Там можно делать разные виды map (каноничный - mapcar) на неопределённое число списков сразу.

(mapcar #'+ '(1 2 3) '(4 5 6)) ;; получим (5 7 9)

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

yoghurt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.