I make an argument for type-rich interfaces, compact data structures, integrated resource management ...
light-weight abstraction with direct and efficient mapping to hardware, suitable for infrastructure code
I took some sentence from the description of Bjarne description, because I am trying to find ressources, materials tutorials that show how to acheive this. For the previous standart or c++11. Anybody know good reference where i can find this now?
First of all Thanks for your answers. My question was more about the academic side, what to say to programmers.
I usually say, "Look, it's contiguous. This is space-efficient, and processors love blasting through memory in a straight line", and leave it at that. That's all you need to know when you're starting out.
I totally agree with this, but how long can you go on without giving then the explanation even Bjarne (I re listen to the keynote this morning) didn't gave support to this fact without talking of locality.
Locality is really a generic term that means related stuff from different point of views. For example, and array or linked list ( array has it's memory more local) or caches L1, L2 (L1 is closer to registers than L2).
And this concept is amazingly important. And overlooked to many times. I understood a lot better what to thrive for when writing efficient code, when need be. For fun I asked fellow programmer today how many were told at school how locality of memory (and their different manifestation example: data structures ( vector), memory caches) is important. And for most of it is that they didn't know. Until they wrote creepy slow code/architecture because of caches misses.
My point is, I think those concept need to be introduce to student early enough, so that they can start think how to write with the hardware not against it. And for this reason before they graduate you need to tell them. This was my misunderstanding. How you can say vector is awesome because of memory locality and never teach them why so that they can reproduce this awesomeness.
On personal thought, some will call that early optimization, I wouldn't. This kind of choice in design need to be done at an early stage of a design. You need to know early enough where things will reside, who own what and how you will traverse it. If not at the end it is too late.
First I think it was an amazing day and made me think alot! I am a game developer (thanks Andrei for the mention and care about locality, cache and cache misses. I don't know if my question will get an answer but here it is.
I was confused by something Bjarne said. I am confuse on how you can talk about the difference between list and vector in performances because of their layout and design and at the same time say that you shouldn't teach student about cache lines, and the low hardware stuff. I think I miss undertstood him but anybody can clarify?
I don't think those need to be reflected on the language but they have to be reflected in the learning material because they are parts of the first things you need to consider when designing librairies, systems, frameworks..., games and applications. I can only refer to all the material about concurrency that Herb put on the net about those issue. I don't see them as optimization but as design. (usually when you are at optimizing it is too late to optimize those things).
I know I am kind of mixing things here like performance of vector and list, with concurrency code, but to me they share some of the same concern. I could call that the reconstructed family of locality memory, which are cache misses, memory layout, sequence iteration, cache lines and caches. I believe that every programmer should know about this because as good compiler will be they will never rewrite your architecture. If one day a compiler change my code from a tree to a vector or a list to vector i would be shock.
So to me it kind of contradict to say you should use vector because of this and that and then say you shouldn't know why. And then I surely misunderstood.