Back to Basics: Almost Always Vector - Kevin Carpenter - CppCon 2024

[@sky_is_the_limit_13]

Great talk! Thank you so much!

[@sky_is_the_limit_13]

Thank you for posting here! I wish there were a playlist for 'Back to Basics' with newer talks, as there is only one for 2019-2021.

[@sky_is_the_limit_13]

I truly enjoy watching i! Very very informative! Great easy to understand explanations and I am half way through it and loved the part about comparing heap and stack. Very very informative! Thanks Kevin please do more Back To Basics!

[@LyolikZzz]

For those who is thinking if this video worth watching: it has only basics, nothing advanced.

[@cppevents]

Yes it is. I thought about adding details like using a std::pmr::monotonic_buffer_resource for creating stack allocated vectors. Perhaps even comparing the performance of the two. However the point was most of the time new developers should just start with std::vector when in doubt.

[@LyolikZzz]

@@cppevents no problems :) This video will be useful for many people. I just wrote this message for such people as me, who doesn't know if it has advanced topics or not.

[@Roibarkan]

59:36 As of C++20, I try to use ranges to wrangle vectors. For example “for (auto& x : drop_view(vec, 10)) {…}” will safely skip the first 10 elements of vec, and simply perform no iterations if vec has fewer than 10 elements

[@toby9999]

In terms of performance, is there any overhead? I rarely use anything past C++14

[@Roibarkan]

@@toby9999 I believe if you do it right, there’s no performance overhead (compared to non ranges code that does the same, not compared to the version that doesn’t check and might crash). Compilation times and attention-to-detail that is required when using ranges are considered not ideal…

[@llothar68]

@@Roibarkan Yes, the whole modern std library is a no-no for me. the more condense the harder to read, with just a few exceptions from the rule.

[@stefanalecu9532]

​@@llothar68 as opposed to...?

[@cppevents]

Love all the feedback on this talk, thank you. Thanks @Roibarkan for the follow up answers, they are spot on. 😃

[@katanasteel]

The vulkan api likes using pointers and reserve + .data() seems like a neat way around that

[@tharindulakmal6615]

26:20 In actual scenario, I think move will be happen instead of copying. If 'nonexcept' is being used in move constructor. Please correct me if I am wrong here.

[@Roibarkan]

30:50 Pablo & Alisdair’s talk: kzbin.info/www/bejne/iH3Iq32rprOWe7M

[@Roibarkan]

40:41 Mike’s talk: kzbin.info/www/bejne/fKeboJ1uesmmqbs

[@gowthamkumars365]

Reference to the books please

[@cppevents]

Data Structures and Algorithms with the C++ STL - www.packtpub.com/en-us/product/data-structures-and-algorithms-with-the-c-stl-9781835469071

[@ZHDINC]

I know this talk is about std::vector, but for the slide about "old c style reallocation" I noticed that there was a missing delete[] for temp. I was curious to see if temp was still accessible after cArray's final delete and it was, but also was surprised to see that indexing cArray was still accessible as well (probably undefined behavior territory?). Putting deletes for both and then attempting to index into them gave the expected error of crashing (it didn't look like it crashed as it just returned to the prompt but found STATUS_HEAP_CORRUPTION in Event Viewer). I suppose this is all a long-winded way of saying...there should've been a delete[] temp; in addition to delete[] cArray; at the end of that snippet, right?

[@cppevents]

Thank for finding a bug in my slide! You are right, that was a miss on my part. I was also trying to organize for the size of the slides as well. Definitely created a memory leak though.

[@ZHDINC]

@@cppevents All the more reason to use almost always std::vector!

[@Roibarkan]

1:00:28 Herb Sutter chiming in on this very point (call site safety checks): kzbin.info/www/bejne/Y2iaq6WMm7VksKc

[@szirsp]

2:30 Well, right from the start that's debatable. It depends what do you mean by size? If you want to print the allocated memory size then it's pretty easy to do that for C arrays... I hate STL use of "size". C has a keyword sizeof. sizeof(foo) returns the SIZE of foo, meaning the allocated memory in bytes. That what size means to me (and C). vector (and other STL/std containers) return the element count when size() method is called. In other words it returns the length of the vector/array in element count and not allocated size of memory. I think it was a mistake calling it size instead of length or capacity . (Actually vector does have a capacity() which returns the allocated storage in element count, and that is the size of the vector... + bookkeeping data). Other sane programming languages (Pascal, Java, Python, C#, Go, Rust...) don't try to confuse the developers and avoid using the same word for 2 different things [1]. They use "length" (or len) to query the number of elements. [1] in C size means byte size in sizeof, but in C++ size means element count in STL containers.

[@BigLongRandomNumberNameM-kf9vy]

I'm pretty sure he's talking about putting the size in the square brackets, which... he's also wrong about, even in C++23 line 5 is totally valid. That's not to say I didn't find a bug in that slide, on line 10 there's a closing bracket with no opening bracket.

[@AtomicAndi]

what was this benchmark bs at 50:55 ??? doing 10x the work in 2x time obviously means you have been doing something else

[@Roibarkan]

I would guess that the majority of the time difference between the two runs is inside the json parser, or perhaps around memory allocation. To some extent, it exemplifies Kevin’s point that using std::vector and std::accumulate take so little of the total runtime - as compared for example to a case where some node based container (list, map, unordered_set, …) would have been used.

[@AlfredoCorrea]

yeah, there is no point in that benchmark. the factor 2 just tells how slow allocations are, not how fast vectors are.

[@mariushusejacobsen3221]

Some of the earlier examples that just filled a vector with a few elements took around half a second. There's a lot of OS load time and perhaps disk access going into that timing.

[@cppevents]

@@AlfredoCorrea I do agree that is probably showing more the speed of allocation vs the speed of vector, I am not a memory allocation expert, still learning. However I also thing that speed in allocation and the way vector manages is part of the point. Especially if you haven't reach the point that you're thinking about allocations, cache lines, hot vs cold memory etc.

[@AlfredoCorrea]

@cppevents Don’t get me wrong, it was an excellent talk. The benchmark was simply off with the rest of the talk. Another pet peeve I have is that the reason to choose between list and vector is almost never about performance, in a list you usually put uncopyable/unmovable (or hard to copy objects) or when you have elements whose existence depends on each other (in a certain direction of the list). The point is that when you really need a list, semantically speaking, you don’t have a choice. This gets lost when people compare vector of ints with a list of ints, for example. It is an artificial example.

[@azdinator]

Pas mal.

[@letsbegin_staytrue]

The quality of people who you meet over coffee is amazing.❤

[@countchocula7985]

I don’t understand the point of this talk. It seems to be about how vector is convenient, which isn’t particularly interesting. Not to mention, a lot of his examples are horribly contrived especially the strange code he calls c-style which nobody would ever want to write. I just don’t think I understand this talk

[@Roibarkan]

Hi, this is a “back to basics” talk. Perhaps you found this talk too basic for your level, and hopefully it’s helpful for others

[@toby9999]

I use C style whenever it's applicable, and it often is. I'm practical and not a language purist. I'm in charge. I don't let a language dictate.

[@cppevents]

You are right, I had a hard time writing it (the C style code). The point was to show what we used to have to do. Which is why I argue the point of when in doubt, almost always choose vector to start! Thanks for checking out the talk.