09:19:36	 From Andres Vargas : is p a copy of a pointer to the begining of a?
09:20:38	 From Andres Vargas : I mean, p is still a copy, is that way p = 0 doesn't have any effect?
09:20:59	 From Andres Vargas : why*
09:21:50	 From Kurt Biery : Yes, it is a copy, so within the context of the function, the pointer gets set to zero, but in the main program, nothing changes
09:22:15	 From Andres Vargas : Thank you 
09:37:56	 From Becky Kowalski : What is meant exactly by "constant time" and "linear time"? 
09:38:03	 From Andres Vargas : The default initialization of "int a[n]" does depend on the compiler? I'm runing it within root and it takes longer the bigger the n
09:38:12	 From Marc Paterno : Constant time means the time taken does not increase as the array gets longer.
09:38:37	 From Marc Paterno : Linear time means the time taken increases linearly (as opposed to say quadratically) with the size of the array.
09:38:52	 From Becky Kowalski : Ah, thank you 
09:39:25	 From Marc Paterno : For “constant time” one will often see the notation O(1), and for linear one often sees O(n).
09:57:47	 From Marc Paterno : A fairly thorough description of different kinds of iterators (called iterator categories) is available at https://en.cppreference.com/w/cpp/iterator. Note that a pointer into an array *is* a random-access iterator, as is a vector iterator.
10:00:58	 From Andres Vargas : Thank you, I'm curious about the way to declare it vector<int>::iterator is like vector<int> like a template for the iterator? 
10:02:13	 From Marc Paterno : vector<T> is a class template, as opposed to a class. vector<int> is a class; you can make objects of type vector<int>, but not of vector<T>.
10:02:56	 From Andres Vargas : so vector<int>::iterator is a class explicitely defined, or defined through a template?
10:03:00	 From Marc Paterno : vector<int>::iterator is a class. It happens to be defined inside the class vector<int>, which is why you need to use the “qualified name” to access the name of the type.
10:03:33	 From Andres Vargas : Oh I see, so vector<int> is the namespace?
10:03:49	 From Marc Paterno : The class template vector<T> defines the nested type vector<T>::iterator, so for every type T, there is a type vector<T>::iterator.
10:04:24	 From Marc Paterno : And yes, in this way vector<int> is a namespace. All C++ classes (and structs) are also in this namespaces.
10:04:48	 From Andres Vargas : Oh Thank you, now makes sense the use of :: 
10:04:51	 From Andres Vargas : :) 
10:35:22	 From Andres Vargas : is std::array still on stack?
10:37:36	 From Marc Paterno : The sequence of objects contained by std::array are on the stack. The std::array object itself is also on the stack. Both assuming that the std::array is not created using “new array”, which would be legal but probably silly. In that case, std::vector is likely a better choice.
Darn, that was supposed to be public.
10:41:51	 From Andres Vargas : thank you again
10:42:09	 From Marc Paterno : You’re welcome, Andres.
10:45:02	 From Jaiden Parlone : Does anyone know where the notes Glenn writes are stored please? 
10:45:27	 From Andres Vargas : https://gitlab.com/gpdowning/oopl-fnal/
10:45:43	 From Andres Vargas : Is line 228 typename instead of template?
10:46:05	 From Jaiden Parlone : Great, thank you Andres
10:46:57	 From Marc Paterno : Andres, can you point to which file you’re talking about?
10:47:30	 From Andres Vargas : the shown in screen Marc :)
10:47:37	 From Andres Vargas : is 230 now
10:47:48	 From Jaiden Parlone : I think in the current one, it reads: template <template T, int N>
10:48:17	 From Marc Paterno : Yes, that should read template <typename T, int N>
10:49:37	 From Andres Vargas : Thank you Marc, Jaiden
10:53:14	 From Andres Vargas : Are we missing N in line 233? T _a[N]?
10:54:12	 From Marc Paterno : Yes, line 233 should say T _a[N];
11:23:07	 From Andres Vargas : Marc, does begin(t) just call t.begin()?
11:30:51	 From Lorena Lobato Pardavila : Sorry I didn’t realize I was muted !
11:33:26	 From Marc Paterno : Andres, sorry for the delay. Yes, std::begin(t) will call t.begin() for a vector, list, etc. In addition, the function is inlined, so the compiler will not add any function call overhead.
11:34:54	 From Andres Vargas : Thank you Marc
11:35:25	 From Jaiden Parlone : Sorry, What is a function call overhead? 
11:35:28	 From Marc Paterno : Every function call creates whatever stack space is needed by that function, and that space gets “cleaned up” after the function is done, right before the return.
11:36:41	 From Jaiden Parlone : Thank you! 
11:36:54	 From Marc Paterno : Function call overhead is the (generally quite small) time taken to invoke a function, as distinct from the time taken actually executing the body of the function. This overhead is quite small. My point was that even that small extra cost is not incurred by using std::begin rather than vector::begin, etc.
11:38:50	 From Rishabh Uniyal : What is difference between a heap and a stack?
11:42:04	 From Marc Paterno : Stack space I described a few questions ago. Heap space is memory that is accessed by using new. The important difference is that stack space is managed automatically; so a variable declared on the stack is destroyed automatically, without the user writing code. A variable declared on the heap (with new) must be destroyed manually, by the user calling delete.
11:53:43	 From Rishabh Uniyal : thanks marc
11:54:06	 From Marc Paterno : You’re welcome, Rishabh.
11:59:46	 From Becky Kowalski : Is there some benefit to using heap space vs stack space? 
12:00:54	 From Andres Vargas : Heap is dynamic, size can changed based on user input
12:01:03	 From Andres Vargas : can be changed*
12:01:21	 From Becky Kowalski : Thanks 
12:02:31	 From Marc Paterno : In addition, for very large objects, is can be important that stack space is much more limited than heap space. An array of a billion integers can be created on the heap easily on modern machines; on most implementations, a stack array of a billion integers would probably cause a program failure.
12:03:04	 From Becky Kowalski : Ah I see, thank you 
12:04:41	 From Andres Vargas : Mark, why is that failure? are the stack and the heap "physically" separated?
12:04:59	 From Andres Vargas : or physically different?
12:06:53	 From Marc Paterno : Common implementations have them at different locations in the program’s memory space. And usually, stack space is limited (perhaps megabytes in size) while heap space is only limited by either the actual memory on the machine, or what amount of that memory the OS allows each process to use (often many gigabytes).
12:08:12	 From Andres Vargas : Thanks Marc, Do you recommend any resource to learn more about these differences from a hardware level?
12:09:05	 From Chris Green : Andres, there is no difference at the hardware level: it’s all the same memory. It’s a question of how the use of the memory is organized within a running program.
12:09:20	 From Diana Kafkes : can you explain the wrong step size being used with a parent pointer?
12:10:39	 From Chris Green : It’s the difference between having a bunch of boxes of fixed size with a function name labelling each (stack), or (as the D&D parlance goes) a Bag of Holding.
12:12:48	 From Marc Paterno : Andres, I don’t know of a good introductory reference. Often it is an operating system reference that will describe this. Perhaps Glenn will have a suggestion; please ask when he gives you a chance.
12:14:07	 From Andres Vargas : Thank you Marc, Chris
12:19:20	 From Chris Green : Andres, you’re welcome.
12:23:25	 From Jaiden Parlone : Hi, where are the recordings of the sessions stored? I have a feeling I'm going to need to go over this again haha.
12:25:57	 From Lorena Lobato Pardavila : Me too
12:27:44	 From Ala Zglam : You can find them here (https://indico.fnal.gov/event/44790/timetable/?view=standard)
12:28:11	 From Jaiden Parlone : Fantastic, thank you Ala
12:30:49	 From Andres Vargas : Me too, thank you :)
12:31:30	 From Andres Vargas : If unique_ptr can't be assigned what's the use of make_unique?
12:32:04	 From Marc Paterno : The videos are typically posted by the end of the day of the class; it takes a little while to do the processing for them.
12:33:07	 From Marc Paterno : Andres, Glenn will explain more thoroughly when we get to move semantics. However, you can use something like:
12:33:44	 From Marc Paterno : unique_ptr<Thing> p = std::make_unique<Thing>(…);
12:35:08	 From Marc Paterno : Where … is the argument list to be passed to the constructor of T.
12:36:11	 From Marc Paterno : For everyone who is interested in reviewing the material through the recordings: please remember that Glenn has office hours Tuesday and Thursday, and will be very happy to see you there!
12:40:15	 From Andres Vargas : Thank you Marc
12:54:57	 From Chris Green : We do in fact package and distribute valgrind for supported platforms.
12:56:14	 From Marc Paterno  To  Liz Sexton-Kennedy(privately) : Liz, is valgrind available in the CMS computing environment or does CMS use something else?
12:56:31	 From Liz Sexton-Kennedy  To  Marc Paterno(privately) : CMS uses Valgrind extensively
12:56:41	 From Marc Paterno  To  Liz Sexton-Kennedy(privately) : Thanks
12:57:03	 From Liz Sexton-Kennedy  To  Marc Paterno(privately) : the memcheck function runs on each pull request
13:06:58	 From Marc Paterno : Here is a demo of the address sanitizer as found in g++ version 10:
13:06:58	 From Marc Paterno : $ cat santizer.cc
	
int main()
{
	int* p = new int(3);
	// we do not delete p, so it is leaked.
}

$ g++-10 -fsanitize=address  -o santizer santizer.cc
$ LSAN_OPTIONS=detect_leaks=1 ./santizer

=================================================================
==75163==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x10c2a47a7 in wrap__Znwm (libasan.6.dylib:x86_64+0x4d7a7)
    #1 0x10bf14ed1 in main (santizer:x86_64+0x100000ed1)
    #2 0x7fff6c3bacc8 in start (libdyld.dylib:x86_64+0x1acc8)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).