CppCon 2015: Eric Niebler "Ranges for the Standard Library"
Vložit
- čas přidán 28. 09. 2015
- www.Cppcon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2015
-
Range-based interfaces are functional and composable, and lead to code that is correct by construction. With concepts and ranges coming to the STL, big changes are in store for the Standard Library and for the style of idiomatic C++. The effort to redefine the Standard Library is picking up pace. Come hear about one potential future of the STL from one of the key people driving the change.
-
I've been doing C++ professionally for the past 20 years, first for Microsoft, then as an independent consultant. Right now, I'm working on bringing the power of "concepts" and "ranges" to the Standard Library with the generous help of the Standard C++ Foundation. Ask me about the future of the Standard Library, or about range-v3, my reference implementation for C++11.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
Mindbending, brilliant. After watching this talk, I need a vacation to recover.
Amazing speaker, so smooth, so nice to follow.
I enjoyed the talk very much. I feel like 70-x assembler programmers may have felt when were shown higher level programming language. To understand how it works they had to compile the program in their mind to grasp how it works. I find myself compiling declarative to imperative C++ while watching the talk. It is so elegant and beautiful. Thank you!
Excellent work.... I really liked it... No loops, No states ,No if, Correct by construct. Super awesome.
Lex Luthor teaches C++ developers how to *really* use the STL... Ha! Kidding, great talk, great looking code. It'll take a while to paradigm shift, but D has shown this to be a very, very viable option for the future of the STL.
Big thanks, been wating for F# seq in C++ for a long time........ and it's worth it !!!
Thank you for sharing the videos from the conference!
Expressively complex. But it's a library addition, so I'm more than happy to have it.
C++ may be a very old horse but it's certainly alive.
Why doesn't the for_each in the interleave count as a loop? We have to loop through all the different iterators to increment them when the outer iterator reaches the end of a row, so this seems like a loop to me.
04:59 - oh, wow. Didn't know there is an influence of APL on C++11.
I think he meant for loops in the date generation logic, not in the output part.
They really need to CC these.
This is functional programming style. The calendar example is a little contrived, but Eric Niebler used it to show off the power of the ranges concept. In real production code, you don't want to write all your code like that because even if it's very compact, it may be hard to read. However, whenever you have to do successive operations on whole ranges, this writing becomes easy to read because you reason on the whole tabular structure, you don't have to mess with iterators.
For the same reason the copy at the very top doesn't count as a loop--it's not a *raw* loop, where the user code is controlling the conditions and state of the loop.
Dlang rocks!
@Nami Doc, why would it be undefined?
+Out of my misery n_ is modified twice before a sequence point occurs. Unless it's changed somehow in C++11, but I doubt that.
i got warnings for this in c++11 code. and its undefined behaviour, which still works (in gcc).
44:33 isn't that "(++n_) %= ..." undefined behavior? :/
Why should it be?
Tried this challenge in haskell. Got it right on the first try (not counting compile errors), 36 lines. C++ functional style just can't compete with the real thing.
import Data.List
import Control.Monad.State.Strict
months :: [(String, Int)]
months = [
("January", 31), ("February", 28), ("March", 31), ("April", 30),
("May", 31), ("June", 30), ("July", 31), ("August", 31),
("September", 30), ("October", 31), ("November", 30), ("December", 31)]
layout1 :: (String, Int) -> Int -> ([String], Int)
layout1 (m, n) day = (header : map render (rows day n), (day + n) `mod` 7) where
header =
let w = length m
left = 10 - w `div` 2
right = 21 - w - left
in replicate left ' ' ++ m ++ replicate right ' '
rows :: Int -> Int -> [[Maybe Int]]
rows day n = res ++ replicate (6 - length res) (replicate 7 Nothing) where
xs = replicate day Nothing ++ map Just [1..n]
res = go (length xs) xs
go n ys | n String
render = concatMap go where
go Nothing = " "
go (Just n) | n < 10 = " " ++ show n ++ " "
go (Just n) = show n ++ " "
main :: IO ()
main = mapM_ putStrLn lines where
layouts :: [[String]]
layouts = evalState (mapM (state . layout1) months) 4
chunks :: [[[String]]]
chunks = takeWhile (not . null) $ unfoldr (Just . splitAt 3) layouts
lines :: [String]
lines = concatMap (map (intercalate " ") . transpose) chunks
yeah.. but try to write a device driver with the same language as well :P The thing is C++ is a toolbox, not a very very efficient tool, but has tools for everything.
The greater zero check shouldn't be existing as runtime check only, there should be some static error, too
It can't be static. How could a dynamic value be statically asserted?
“$ ./example/calendar.exe” ? It's an interesting mix of Unix and Windows. Btw, “./” can be omitted .
State is evil 😈
No state no mutations
Functional programming style removes most of the evil
and makes you not able to do anything quickly! you need good practices, not sweeping statements and proclamation of evil
It's funny how he had to comment the actual type of 'auto' sometimes.
Those aren't the actual types.
This is just a joke, isn't it? I was lost after 20 minutes. :-) I find the whole thing way too complex for any practical use.
I suggest you really give it another go, it's neat to be able to chain ranges.
The complicated parts are about the implementation of ranges. As a programmer, you don't have to (and should not) care about that. Using ranges as a programmer is really convenient, it's just like the Unix command line in some respect. Consider this dummy example:
print_attendee_table() | column(3) | sort() | unique() | split(" ") | reverse() | sort()
... and try to make sense of it. Then think about how your implementation would look like when just using existing STL concepts in, say, C++14. And how long it would take someone to understand your code.