OK. I'm not sure I follow you on that one. No. I'm certain I don't.
In theory, definition of vector<> complies with standard, so typing above will work anywhere. While vector itself is very well tested, it's not completely portable.
It includes, for example, std::allocator. Implementation of that allocator may be stateful or stateless, which affects the rest of the code and algorithms.
But how is allocator itself implemented? It might need to make a syscall somewhere or call malloc which does the same. Malloc is not defined, it's provided by OS kernel. And OS kernel needs to manage these blocks. And blocks themself are defined arbitrary by OS writers, so there's a linked list somewhere. And this linked list will be making some special ring-0 calls specific to CPU. And the output of all of this is determined by C++ compiler which generates assembly while itself uses same implementation.
Or, C++ code might be compiled to an OS which has no strict kernel and no virtual memory, so vector's allocator would map directly to DRAM, causing slightly different behavior on edge cases, such being unable to support same handling of invalid memory accesses.
C and C++ do not come with abstraction layer that would allow code to be reliably reusable, it depends on everything, from compiler implementation, OS design, build toolchain and standard library implementation. Standard library works pretty well, but just about any other code is completely bound compiler settings and version of OS kernel. Change any of that and things can break in a million ways, while remaining standard-compliant C or C++ code.