Remember yourself next time

Well, let me try to explain in more details In the code that I pasted I wanted to resize the vector if the new index doesn't fit it. Basically, I want to check the size and if it smaller, call resize. But, I will probably need to resize it further in the future, so there are two options: 1) resize allocates memory for a vector of given to resize size (capacity = size). then any next push_back or resize to a bigger size will call another rellocation 2) resize will allocate more memory than the given size (capacity > size). something like capacity = size * 2. So my question basically is: is the first case true or the second is true? If first than I need to manage it myself how I did in my code example. Otherwise every resize will trigger reallocation.

this check is already done in push back

Well, let me try to explain in more details In the code that I pasted I wanted to resize the vector if the new index doesn't fit it. Basically, I want to check the size and if it smaller, call resize. But, I will probably need to resize it further in the future, so there are two options: 1) resize allocates memory for a vector of given to resize size (capacity = size). then any next push_back or resize to a bigger size will call another rellocation 2) resize will allocate more memory than the given size (capacity > size). something like capacity = size * 2. So my question basically is: is the first case true or the second is true? If first than I need to manage it myself how I did in my code example. Otherwise every resize will trigger reallocation.

yes, but it does it only when needed and all at once

it is not inconcievable to implement resize as a loop of push_backs

well, if I have vector of size 3, then I have 100 empty objects that I don't care about, and then I want to insert 101-st. then - resize (or reserve+resize) will make 1 allocation - push_back will make more allocations (~6?)

why would you ... push them into a vector?

/warn non-english

K bye

http://yosefk.com/c++fqa/defective.html

All arguments are literally named by the convention: Defective + *literally every cpp feature* And all the arguments themselves are either non-sense or they resolve around duplication of C code (false no matter from where you look at it) or marketing (yeah, really... 😂)

"you can't printf to an iostream" ummmm literally what

BWHOOHOOOHOOO :(:(:( WHY ISNT OLD STUFF COMPATIBLE TO NEWER BETTER STUFF :(:(:(

he wants to be able to specify an ostream to the printf function probably

Gn

google the syntax for for

hello*

In naturally written C++ code, changing the private members of a class requires recompilation of the code using the class. When the class is used to instantiate member objects of other classes, the rule is of course applied recursively. This makes C++ interfaces very unstable - a change invisible at the interface level still requires to rebuild the calling code, which can be very problematic when that code is not controlled by whoever makes the change. So shipping C++ interfaces to customers can be a bad idea.

that's why people distributes software with C API sometimes

I doubt this is the reason why C APIs are shipped. This problem applies to C as well if you make a previously "exported"/availabe function static. C makes it really easy to call functions from different languages since no name mangling is needed.

I doubt this is the reason why C APIs are shipped. This problem applies to C as well if you make a previously "exported"/availabe function static. C makes it really easy to call functions from different languages since no name mangling is needed.

but.. if you change a private method you change the vtable

what I mean is that he talk about recompiling if you change a private method

if you change a static function only visible in a .c in C language do you have to recompile the calling application?