Notorious b.s.d. posted:

and smarter pointers

fart simpson posted:

how do you know this? like i find refactoring and modifying stuff in elm (a pure functional language) is way way way easier than doing the same in javascript, because elm code easily ends up being modular and composable and the compiler is v helpful

Notorious QIG posted:

nah now it's

code:

for (std::Butt::iterator it = butt.begin(); it != butt.end(); ++it) {
    fart(*it);
}

(ok or you just use auto in c++11 and up)

Illusive gently caress Man posted:

its just so dumb that every time i want to say

code:

DoThis();
DoThat();

instead it has to be

code:

result = DoThis();
if (!result.ok()) {
  return result;
}
result = DoThat();
if (!result.ok()) {
  return result;
}

even though its doing the same thing, my eyes fuckin glaze over with the second one.

Captain Foo posted:

probably some code, tbqh

Illusive gently caress Man posted:

its just so dumb that every time i want to say

code:

DoThis();
DoThat();

instead it has to be

code:

result = DoThis();
if (!result.ok()) {
  return result;
}
result = DoThat();
if (!result.ok()) {
  return result;
}

even though its doing the same thing, my eyes fuckin glaze over with the second one.

Notorious QIG posted:

not if it's c++03 or earlier

HoboMan posted:

i had to use LISP for some academic poo poo like 6 years ago. i remember nothing about it except infinite function nesting.
but now, upon typing that, i realize i may be ascribing to functional programming what might just be the fact it was academic code.
but surely my professor would never write code that is a muddled mess only he understands!

tef posted:

gonadic io posted:

I'm glad you reconsidered. All of the best parts of the c# language (ie NOT the .net infrastructure) are considered to be "functional" features. var, foreach, linq, expression bodies, cascading nulls, AndThen (is that what it's called when u chain futures together?)

Illusive gently caress Man posted:

its just so dumb that every time i want to say

code:

DoThis();
DoThat();

instead it has to be

code:

result = DoThis();
if (!result.ok()) {
  return result;
}
result = DoThat();
if (!result.ok()) {
  return result;
}

even though its doing the same thing, my eyes fuckin glaze over with the second one.

HoboMan posted:

i had to use LISP for some academic poo poo like 6 years ago. i remember nothing about it except infinite function nesting.
but now, upon typing that, i realize i may be ascribing to functional programming what might just be the fact it was academic code.
but surely my professor would never write code that is a muddled mess only he understands!

fritz posted:

can you at least use a boost

weird posted:

code:

std::for_each(butt.begin(), butt.end(), fart);

more like dICK posted:

std::transform should do that?

more like dICK posted:

I think that "operation I regularly apply to a map entry" is he perfect thing to encapsulate in a function but I'm in this thread so whatevs

Bloody posted:

i have an incredibly noob haskell question

okay so i have a type like:
data Butt = Fart String | Poop Int | Diarrhea Bool

and now i have a list like butts = [Butt]

and i wanna filter the list down to just Fart Strings somehow. so right now im doin like:
isFart :: Butt -> Bool
isFart (Fart _) = true
isFart _ = false

...filter (isFart) butts

this seems insanely bad. like if butts was actually butts = [Bool] i could filter (=True) butts to get True butts but because its a Fart String i don't seem to be able to do that?

Bloody posted:

either lightly documented or i don't understand how to read the docs for it

Notorious QIG posted:

i pretty frequently have to iterate over stl::map objects, which is really "fun" in c++03. say i want to add one to each member of an int map keyed by strings

C++ code:

std::map<std::string, int> myMap;
...
for (std::map<std::string, int>::iterator it = myMap.begin(); it != myMap.end(); ++it) {
    ++myMap[it->first];
}

concise!

VikingofRock posted:

Why wouldn't you just do ++(it->second)?

Bloody posted:

while ur here do you happen to know how to interact or at least capture state from megaparsec it's clearly a thing that can be done but is either lightly documented or i don't understand how to read the docs for it. i wanna be able to tag all this stuff im parsing out with where it came from so later when im doing stuff with it i can say "hey this thing is never used, it was declared on line 16"

gonadic io posted:

But that was with regular parsec not mega so maybe it's built in now? It's a pretty common use case...