My attempt on a vector class

[delicate ocean]

https://github.com/stley/vector

I'm beginning to understand pointers, memory allocation, etc. First implementations used default data types such as int, float and double in conjunction with malloc.
Last commit implemented non-trivial support for classes and struct types (therefore, new and delete operators are used).
There are some methods to be reimplemented tho (such as those that use iterators, something that I couldn't get a hold yet).
Maybe making safer methods (in order to prevent some of the UB that std::vector doesn't prevent)

[molten lava]

make it constexpr!

[cobalt trench]

https://github.com/stley/vector/blob/main/vector.hpp#L79 , if capacity is 1, then the new capacity would still be 1 ?

[cobalt trench]

I dont think it can work, unless capacity is fixed at compile time.

[delicate ocean]

Since vector constructor sets both size_ and capacity_ = 0, operation would be basically size_t new_cap = 0 + (0/2), that gives me 0. Next line just takes care of it by defaulting new_cap to 2 if the old capacity was 0 (which in most cases means the vector was just created).

[molten lava]

why? std::vector itself is constexpr

[cobalt trench]

wait, that only works for transient allocation right ?

I think im conflating it with static_vector, which has fixed capacity

[vestal wolf]

https://github.com/stley/vector/blob/main/vector.hpp#L55

size_t max_size() const { return return SIZE_MAX / sizeof(T); }
double return
I noticed because I wanted to compile an example to talk about the issue of capacity == 1

[vestal wolf]

I'm not a big fan of these kind of setups, because it forces you to really track how your capacity can change and make sure the "forbidden" value can never come up
usually a vector has some feature that let the user "control" the capacity to some extent, so I went to check and you offer those features as well
if you create a new vector (capacity 0) then resize or reserve to 1, the issue can manifest

https://godbolt.org/z/xM1rcdnzn

berkeley::vector<int> vec;
vec.reserve(1);
vec.push_back(0);
vec.push_back(1);

either you special case "capacity == 1" everywhere, or you should force grow to also work from capacity 1

one suggestion amongst a lot of possible options, would be to go for

size_t new_cap = 1 + capacity_ + (capacity_/2);

which doesn't quite have the exact growth factor of 1.5, though close enough, but more interestingly (imo) you either get a bigger value, or you've grown to such immense sizes that you're wrapping around and you should probably fail/throw
so I guess you'd replace the if(!capacity_) new_cap = 2; by if(new_cap <= capacity_) return false; or something

or you assume/force these sizes to never happen and kick out the if

right, might as well go with

size_t new_cap = std::min(1 + capacity_ + (capacity_/2), max_size());
if (new_cap <= capacity_ && capacity_ < max_size())
  new_cap = max_size();

considering that you do ::operator new( (sizeof(T)*new_cap) ) right after

this bit is a tad weird

    T* new_ptr = static_cast<T*>(::operator new( (sizeof(T)*new_cap) ));

    if (!new_ptr) return false;

maybe you're using some specific compiler extensions/options, but the specific version of ::operator new you are using is meant to throw an exception on allocation failure, in standard conforming c++ it can never give you a null pointer

if you want a null pointer on allocation failure, I would recommend to ::operator new( size, std::nothrow ) instead

[delicate ocean]

Hey there, really appreciate the feedback!

[delicate ocean]

Yeah, pretty sure I saw some documentation on microsoft learn about new operator returning a null pointer, however when looking for it again I noticed that it says that it can either return a null pointer or throw an exception.

[delicate ocean]

At first I only changed the logic comparison for (capacity_ <= 1), still trying to get a hold of how your proposed code work

[delicate ocean]

however this should be enough to get rid of if(!capacity_) new_cap = 2;, right?

[vestal wolf]

it depends on what overload is used

it just so happens that the overload you used (maybe unintentionally) throws on failure
skipping some details, the standard explicitly mandates this behaviour for this specific overload, and compilers may take advantage of that no matter what you do

;asm -O2

#include <new>

extern void* one_time_emergency_memory;

void* my_allocate(std::size_t to_allocate)
{
  void* allocation = ::operator new(to_allocate);
  if (!allocation)
    return one_time_emergency_memory;
  else
    return allocation;
}

[gentle phoenix]

Assembly Output

my_allocate(unsigned long):
  jmp operator new(unsigned long)

slybach | 78ms | c++ | x86-64 gcc 15.2 | godbolt.org

[vestal wolf]

this is a disfunctional function, but it's to illustrate the point, the generated code for my_allocate "just" leaves everything to operator new

as in, the compiler completely eliminated the branch where operator new returns nullptr because it cannot legally happen

[vestal wolf]

I made multiple suggestions in a row so I'm not sure which one you're currently looking at

[vestal wolf]

that would be the last version, and yes it gets rid of the if(!capacity_) new_cap = 2;, though it includes other checks

I haven't read your whole code, and I kinda need to go, but feel free to ask for clarifications about what I said, I'll check back later