namespace ANN {

template<class T>
class vector : public std::list<T> {
public:
	vector()  : std::list<T>() {};
	vector(int n, const T& value = T() ) : std::list<T>(n, value) {};

	T &at(const unsigned int &iPos) {
		assert(iPos < this->size() );
		unsigned int i = iPos;
		for(typename std::list<T>::iterator it = this->begin(); it != this->end(); it++) {
			if(i == 0) {
				return *it;
			}
			i--;
		}
	}

	const T at(const unsigned int &iPos) const {
		assert(iPos < this->size() );
		unsigned int i = iPos;
		for(typename std::list<T>::const_iterator it = this->begin(); it != this->end(); it++) {
			if(i == 0) {
				return *it;
			}
			i--;
		}
		return T();	// error return
	}

	T& operator[](const unsigned int& iPos) {
		return this->at(iPos);
	}

	const T& operator[](const unsigned int& iPos) const {
		return this->at(iPos);
	}
};

#include <iostream>
#include <ANVector.h>
#include <vector>

#include <sys/times.h>

using namespace std;

int main(void) {
	unsigned int max = 100000000;

	long T1, T2;
	struct tms start_time, stop_time;

	T1 = times(&start_time);
	ANN::vector<int> vec;
	for(int i = 0; i < max; i++) {
		vec.push_front(i);
	}
	T2 = times(&stop_time);
	printf ("Execute Time for Loop: %d\n", T2-T1);

	T1 = times(&start_time);
	std::vector<int> vec2;
	for(int i = 0; i < max; i++) {
		vec2.push_back(i);
	}
	T2 = times(&stop_time);
	printf ("Execute Time for Loop: %d\n", T2-T1);

	/*
	for(int i = 0; i < max; i++) {
		std::cout<<vec.at(i)<<std::endl;
	}
	*/
	return 0;
}

Execute Time for Loop: 381
Execute Time for Loop: 39

PS: vector von list erben ist mal eine ganz schlechte Idee, was hast du dir denn dabei gedacht?

Der Standard sagt zu den modifizierenden Memberfunktionen:

Causes reallocation if the new size is greater than the old capacity.

Die Kapazität, die durch die Memberfunktion capacity() zurückgegeben wird, bestimmt, wie viele Elemente der vector noch aufnehmen kann bevor eine Reallokation stattfinden muss.
Standard:

size_type capacity() const noexcept;

1 Returns: The total number of elements that the vector can hold without requiring reallocation.

Was auch in diesem Zusammenhang sehr wichtig ist, ist die Memberfunktion reserve() , die schon im Voraus eine Reallokation erzwingen kann:

void reserve(size_type n);

2 Effects: A directive that informs a vector of a planned change in size, so that it can manage the storage
allocation accordingly. After reserve(), capacity() is greater or equal to the argument of reserve if
reallocation happens; and equal to the previous value of capacity() otherwise. Reallocation happens
at this point if and only if the current capacity is less than the argument of reserve(). [....]

Das ist sehr nützlich, falls man weiß das gleich der Vektor sehr groß werden wird, und in bspw. einem Schleifendurchlauf die ganze Zeit neue Elemente, vielleicht sogar einzeln, bekommt.
Dann ist es entspannt, wenn man im Voraus die Kapazität entsprechend groß macht und dadurch eine Reallokation möglicherweise ganz umgeht (was z. T. viel Zeit spart).

Und dann erbst du von std::list und überschreibst irgendwelche Methoden... Damit zerstörst du evtl. die interne Struktur der std::list und lässt sie erst so ineffizient werden.

Mein Vorschlag: Nimm was aus der STL und programmier erst mal weiter. Sollte es später tatsächlich Probleme geben, kannst du das ganze noch immer austauschen.

Es macht mich bei theoretisch 10^7 möglichen re-alloks alelrdings schon stutzig, dass vector 10x schneller ist, als list.

Wenn du den gcc/clang verwendest, die libstdc++ Implementierung allokiert immer doppelt so viel. Also nichtmal annähernd so viele Allokationen.

Dabei ist Faktor 2 eine schlechte Idee, wie hier erklärt wird: https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

Und dann erbst du von std::list und überschreibst irgendwelche Methoden... Damit zerstörst du evtl. die interne Struktur der std::list und lässt sie erst so ineffizient werden.

Er überschreibt nix ... at() und operator[] wurden absichtlich bei std::list nicht implementiert, weil eine Liste eben nur extrem ineffizient random-access anbieten kann.

std::list<int> list = ...;
for(int i = 0; i < n; ++i)
    do_something(list[i]);

hätte eine Komplexität von n!, totale Katastrophe also.

Edit: Nix Fakultät, gerade etwas daneben, aber immer noch katastrophale Laufzeit.

Es kann nicht bei jeder typ-größe dermaßen vorreserviert werden.

Warum kann nicht?
Ob

#include <vector>
#include <iostream>
int main()
{
    std::vector<int> v;
    auto c(v.capacity());
    // Wir push_backend tausend mal was in einen Vector.
    for (int i(0); i < 1000; ++i)
    {
        v.push_back(i);
        // Wenn sie die Kapazitaet geaendert hat,
        // also neu allokiert und umkopiert wurde ....
        if (v.capacity()!=c)
        {
            c = v.capacity();
            // ... geben wir das aus.
            std::cout << c << std::endl;
        }
    }
}

oder

#include <vector>
#include <iostream>
#include <array>
int main()
{
    std::vector<std::array<int,3000>> v;
    auto c(v.capacity());
    // Wir push_backend tausend mal was in einen Vector.
    for (int i(0); i < 1000; ++i)
    {
        v.push_back(std::array<int,3000>());
        // Wenn sie die Kapazitaet geaendert hat,
        // also neu allokiert und umkopiert wurde ....
        if (v.capacity()!=c)
        {
            c = v.capacity();
            // ... geben wir das aus.
            std::cout << c << std::endl;
        }
    }
}

die Ausgabe des executables, das mein Compiler daraus macht, ist in beiden Fällen diese:

1
2
4
8
16
32
64
128
256
512
1024

Reservier halt mit reserve(). Dann kannste in den vector vermutlich mehr reinstopfen.

Das bringt nichts. reserve() vergrößert max_size() nicht. reserve() kann lediglich viele Reallokationen verhindern.

Ich wusste allerdings nicht, dass der std::vector in zweierpotenzen von allein reserved

MSVC nimmt soweit ich weiss 3/2.
Es muss aber immer abhängig von der vorherigen Grösse sein - mit fixen Schritten könnte man die Forderungen des Standards nicht hinbekommen (amortisiert konstante Zeit für push_back ).

Es muss aber immer abhängig von der vorherigen Grösse sein - mit fixen Schritten könnte man die Forderungen des Standards nicht hinbekommen

Könnte auch abhängig von den Ticks seit Systemstart sein. Oder abhängig von den bisher erledigten Reallokationen des Vektors (ist unabhängig von der Grösse wenn es durch swap() nicht verändert wird).

Jedenfalls muss immer mehr allokiert werden je grösser der Vektor wird.

Wir können uns aber auch gerne darauf einigen dass es keine sinnvolle Alternative gibt als die Wachstumsschritte von der alten Grösse abhängig zu machen.

Könnte auch abhängig von den Ticks seit Systemstart sein. Oder abhängig von den bisher erledigten Reallokationen des Vektors (ist unabhängig von der Grösse wenn es durch swap() nicht verändert wird).

Beides erfüllt die Vorgaben des Standards über das Laufzeitverhalten der Operationen auf std::vector nicht, also könnte das gerade nicht sein.