My own std::vector

• operator=

  Obviously, this part of the code has never been exercised. An attempt to use operator= fails to compile:

  error: invalid conversion from ‘int’ to ‘int*’ [-fpermissive]
           buffer=obj.getBuffer();
  

  and indeed getBuffer returns T.

  What's worse, operator= badly leaks memory:

          buffer=new T[capacity];
          buffer=obj.getBuffer();
  

  and whatever has been allocated with new is lost forever.

  What was probably intended is

          buffer = new T[capacity];
          std::copy(obj.buffer, obj.buffer + capacity, buffer);
  

  (same as you do in a copy constructor).

• operator[]

  returns a non-const pointer, that is

  foo[x] = y;
  

  will compile even if foo is a const vector. To work correctly with const objects you need two flavors of a subscript operator:

  T& operator[](int);
  const T& operator[](int) const;
  

  BTW, an index argument shall be of size_t. Integers are not suited to express what index is. Along the same line, you throw exception() if the index is above capacity, but allow access with a negative index.

Use of new []

At least in my opinion, this provides a good demonstration of why the array form of new should normally be avoided.

The problem in this case is that when you allocate space with buffer = new T[capacity];, you not only allocate space but also create objects occupying all that space.

Then when you do (for example) a push_back, it doesn't create a new object as a copy of whatever you pass to push_back. Instead, it assigns the value of what you pass to push_back over the object that was already there.

This means, among other things, that all the objects you store in this collection must support default construction, rather than (for example) only copy construction or move construction like std::vector can support.

Support for iterators

You only support access to the contents of the collection by index, not by iterator. This means (among other things) that you can't use any of the standard algorithms with it. At least in my opinion, that's quite a serious handicap.

Exceptions

When you receive an out of range subscript, you throw an exception. That's a good idea. Unfortunately, you throw just about the most generic possible exception--std::exception. That doesn't tell a user much about what went wrong. I'd rather throw a more specific exception, and (especially) one that supports a description of the problem. In this case, it seems to me that it would make a lot more sense to throw an std::out_of_range exception:

    if (index>=capacity){
        throw out_of_range("Bad subscript");
    }

This pretty much eliminates any need for the out of range comment you had there as well.

getBuffer()

I'd almost rather eliminate this completely. Using a pointer to an object's internal state tends to be a problem. On the other hand, that is only a tendency, not an absolute certainty, so while I'd rather provide alternatives that render this unnecessary, removing it without providing alternatives may be premature.

operator []

Personally, I'd generally prefer to return a proxy in this case. The problem is that even with the overload suggested by @vnp, you can run into problems. What you'd normally like is that given some code like:

a[i] = b[i];

...that the left side use the non-const overload, and the right side use the const overload. That's not quite how things work though. Instead, what happens is that the overload that gets used is based solely on whether this is a T * or a T const *. As shown by std::vector, that works out well enough most of the time, but we can still do better.

With a proxy, we can overload operator T and operator= to get exactly the behavior we really want.

Buffer Growth Strategy

Right now, every single time you use push_back, you re-allocate the buffer and copy the entire old buffer to the new one. This means push_back has linear complexity on the number of items already in the collection. That, in turn, means that creating a collection of N items has a complexity of \$O(N^2)\$.

We can do quite a lot better than that. In fact, we can make each push_back (amortized) constant complexity, so creating a collection of N items has a (amortized) complexity of \$O(N)\$. To do that, the buffer growth needs to follow a geometric progression instead of an arithmetic progression--that is to say, instead of adding some fixed amount each time it needs to grow, we instead multiply the size by some fixed factor. There's room for argument over the truly optimum factor, but most real implementations use either 1.5 or 2 (personally, I tend to favor 1.5).

Note that this will require changing a few other parts as well. Right now, you're tracking the size of the buffer. With this change, you'll need to keep track of both the size of the buffer itself, and the number of items in that buffer that are currently in use. You only resize the buffer if push_back is called and the entire buffer is currently in use. When only part of the buffer is in use, you can create the new object in that empty space without reallocating or copying other objects.

#ifndef __STDVECTOR__
#define __STDVECTOR__

Avoid Leading/Double Underscores. From the C++ Standard:

17.6.4.3.2 Global names [global.names]

Certain sets of names and function signatures are always reserved to the implementation:

• Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
• Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

#include <iostream>

#include as little as possible and avoid #include <iostream> in library code. Most implementations will include static constructors into every translation unit whenever you #include <iostream>. Don't impose this cost on those that use your library. <iostream> is used your test code, so you should relocate #include <iostream> there.

unsigned int capacity;

Consider std::size_t instead of unsigned int. From the standard,

18.2 Types [support.types]

6. The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.

StdVector(){
    capacity=0;
    buffer=new T[capacity];
}

Spacing helps distinguish different language constructs. Consider adding spaces where appropriate (e.g. before the { and surrounding the =).

You should prefer member initialization lists instead of assignment in a constructor body. You'll get a performance increase from non-POD types, increased readability from the uniform initialization across all members (const/references require member initialization), and prevent common errors (e.g. use before set errors).

void push_back(T obj){
    StdVector oldSV(*this);
    int i;

    capacity++;
    delete []buffer;
    buffer=new T[capacity];
    for (i=0; i<oldSV.getCapacity(); i++){
        buffer[i]=oldSV[i];
    }
    buffer[i]=obj;
};

Consider what types of values can be passed into the function. While things like primitive types and small objects (2-3 words) are cheap to copy, not everything will be cheap. In the case of a templated type, you don't know the size of the object passed in. Pass the object by const-reference.

Don't introduce a variable until you actually need to use it. int i doesn't need to be declared at the top of the function and all you are doing is asking readers to track variables that aren't needed until later in the function. Declare it before the for loop.

Consider offering users the strong exception guarantee (should failure to append have side effects?). What happens if new throws some variation of the std::bad_array_new_length exception?