SEPPLES [Part SEPPLES]

HASKELL

Time for a serious thread.


std::map<std::string, std::list<MyTypeThatHasLongName> > faggot;
//...
for (std::map<std::string, std::list<MyTypeThatHasLongName> >::iterator iter = faggot.cbegin(); iter != faggot.cend(); iter++) {
    std::pair<std::string, std::list<MyTypeThatHasLongName> >& faggot_pair = *iter;
    std::cout << "faggotry: " << faggot_pair.first << " -> " << faggot_pair.second << std::endl;
}

>>3
SEPPLECOCKS TO THE RESCUE!

>>3

    std::multimap<std::string, std::list<MyTypeThatHasLongName> > faggot;
    //...
    for (std::multimap<std::string, std::list<MyTypeThatHasLongName> >::iterator iter = faggot.cbegin(); iter != faggot.cend(); iter++) {
        std::pair<std::string, std::list<MyTypeThatHasLongName> >& faggot_pair = *iter;
        std::cout << "faggotry: " << faggot_pair.first << " -> " << faggot_pair.second << std::endl;
    }
Here, I upgraded that code of yours. No need to thank me - just remember to include GPL license when distributing the modified code.

>>3,5
Doing it completely wrong. You're supposed to use typedefs.

typedef std::list<MyTypeThatHasLongName> my_type_list;
typedef std::map<std::string, my_type_list> faggot_map;
faggot_map faggot;
//...
for (faggot_map::const_iterator it = faggot.cbegin(), it_end = faggot.cend(); it != it_end; ++it) {
    std::cout << "faggotry: " << it->first << " -> " << it->second << std::endl;
}

That's not so bad, right?


for (auto& herp : derp)
    harpdarp(herp);

My dick is NP-hard for thinking about C++11

:-)

>>7

std::parallel_for_each(derp.cbegin(), derp.cend(), [](derp_type::const_iterator herp) {
    harpdarp(herp);
});

>>9
Whoa, that's not standard, is it?

>>9

std::combinable<int> harp;

std::parallel_for_each(derp.cbegin(), derp.cend(), [&](derp_type::const_iterator herp) {
    harp.local() = harpdarp(herp);
});

int final_harp = harp.combine([](int x, int y) {
    return x + y;
});

>>10
It's a part of the common subset between Microsoft's PPL framework and Intel's TBB framework, and it's being proposed as a Standard C++ Library addition for inclusion in TR2 after C++11 is ratified in a couple of weeks.

So it'll actually be std::tr2::parallel_for_each to start with. But eventually, after it stabilizes, it'll be moved into the std namespace. It's layered on top of the C++0x/C++11 threading and atomic libraries.

Right now, if you use Microsoft's library, it's in the Concurrency namespace, and with TBB, it's in the tbb namespace.

>>11
Is that a parallel map and reduce? In C++?! It's almost like C++ is turning into a Lisp with more syntax.

>>13
It's almost like C++ is turning into a Lisp with more syntax.
Lisp with the syntax of Perl 6! Or is Perl 6 Lisp with the syntax of C++?

>>13
Is that a parallel map and reduce? In C++?! It's almost like C++ is turning into a Lisp with more syntax.
You are saying that as if Lisp had parallel map and reduce, you poor delusional nyasha.

>>15
map and reduce have been staple components of Lisp hackers' personal toolkits and libraries, if not a core part of the language.

>>15
I don't think that reduce is parallelizzable, it depends on older results.

>>16
map and reduce have been staple components of Lisp hackers' personal toolkits and libraries, if not a core part of the language.

std::transform and std::accumulate are and have always been core parts of the C++ language, you ignorant nyasha.

We are talking about the parallel versions.

>>17 not as such of course, the "Reduce" in MapReduce actually reduces a Monoid. But I was afraid to assault feeble minds of our resident lispers with this additional complication. After all, they all suffer from a severe case of Blub paradox (complicated by the fact that they are fully aware of it but still believe themselves to be at the apex of the hierarchy, objectively).

>>18
Oh, monoids are such a complicated concept. And of course, lists are not monoids. Thus, Lisp's reduce and map are not parallelizable.

And the Reduce in MapReduce is not exactly ``reduce''