Subject: Re: [boost] GSoC '15 Enhanced Vector and Deque
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-03-13 13:33:30
On March 12, 2015 2:39:58 PM EDT, Pranav Vaish <pranav.vaish_at_[hidden]> wrote:
> My name is Pranav. I had sent an email on this mailing list earlier
> regarding some doubt in the implementation of the programming
> test for this project. I have gone ahead and written some code.
> The code is incomplete. Iterator code has not yet been written and
> container methods and some error handling is left. I would appreciate
> it if
> someone could review my code and tell me what else I will need to
I've provided a few comments, but only as a bystander. I'm not invoked in GSoC.
> #ifndef BOOST_VECTOR
> #define BOOST_VECTOR
> struct exception_push_back_capacity_exceed : public std::exception
That's quite the name. Wouldn't "capacity_exceeded" do?
> const char * what () const throw ()
> return "Vector Capacity Exceeded";
Why title case?
> namespace boost
> template<typename T> class vector
> void push_back(T);
> T operator(const int& pos)
> return *(mem_start+pos);
> T* mem_start;
> int size;
> int capacity;
I suggest a making convention to differentiate data members from other variables. I use a trailing underscore.
> template<typename T> vector<T>::vector(int capacity_constr)
"_constr" is a strange convention to disambiguate parameters from other variables. I use a leading underscore.
> mem_start = new T[capacity];
I'd prefer to see use of an initializer list.
> template<typename T> void vector<T>::push_back(T val)
> throw exception_push_back_capacity_exceed();
> catch(exception_push_back_capacity_exceed& e)
Why in the world would you throw an exception from a conditional just to catch it after one statement and report an error? Why doesn't the caller get the exception?
You could, of course, give the programmer the ability to ascertain the capacity and simply make staying within it a precondition of push_back().
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk