M
machine99
how do you resize an array allocated with new?
machine99 said:how do you resize an array allocated with new?
You don't. Yo have to allocate a new block of memory of the target size
and then move the data there and deallocate the original array.
Any reason why you don't use std::vector, which handles resizing for
you?
machine99 said:I do use std::vector quite extensively but there will always be special
cases
Thomas said:Actually, the situations where an array is preferred or required
over a std::vector are few and don't require resizing.
Some of these situations are code / memory space and execution time.
However, time spent developing (and development cost) usually
outweighs any premature optimization issues and all problems
involved with an array when a std::vector should have been used.
The programming priorities (listed with highest priority first):
1. Quality & robustness
2. Development time (also related to cost).
3. User interaction or interaction with the environment.
4. Code space and execution time (i.e. optimization).
If a program can't correctly turn a motor, turning it faster
or using less code to turn it is a mute point.
Thomas Matthews said:Actually, the situations where an array is preferred or required
over a std::vector are few and don't require resizing.
Some of these situations are code / memory space and execution time.
However, time spent developing (and development cost) usually
outweighs any premature optimization issues and all problems
involved with an array when a std::vector should have been used.
The programming priorities (listed with highest priority first):
1. Quality & robustness
2. Development time (also related to cost).
3. User interaction or interaction with the environment.
4. Code space and execution time (i.e. optimization).
If a program can't correctly turn a motor, turning it faster
or using less code to turn it is a mute point.
--
When it comes to a point where compatibility to arrays comes into theHoward said:[snip]Thomas Matthews said:machine99 wrote:
You're missing one of the most important priorities for many of us:
compatibility with existing code. We don't all get to choose how we
would write code. Much of it is forced upon us by what was written
before, (or by what our operating system or third-party API's
require).
-Howard
Howard said:message
Why does the need to resize an array mean that it is no longer neccessary to
use an array instead of a vector?
You're missing one of the most important priorities for many of us:
compatibility with existing code. We don't all get to choose how we would
write code. Much of it is forced upon us by what was written before, (or by
what our operating system or third-party API's require).
-Howard
Rolf Magnus said:You don't. Yo have to allocate a new block of memory of the target size
and then move the data there and deallocate the original array.
Any reason why you don't use std::vector, which handles resizing for
you?
Christopher said:Just for curiosity's sake, why isn't there something like realloc()
for new? Wouldn't that make situations like this one easier to manage?
Just for curiosity's sake, why isn't there something like realloc() for new?
When it comes to a point where compatibility to arrays comes into the
game, I usually stick with std::vector, as I can easily pass the content
of a vector into a legacy function (&vector[0]) and converting a
returned array into a vector normally doesn't affect performance in the
stuff that I do. (If it does and it was proven by a profiler, then that
is another story!)
--
game, I usually stick with std::vector, as I can easily pass the content
of a vector into a legacy function (&vector[0]) and converting a
returned array into a vector normally doesn't affect performance in the
stuff that I do. (If it does and it was proven by a profiler, then that
is another story!)
I wasn't aware you could do that. Is the memory for the objects stored in
the vector guaranteeed to be contiguous?
If so, that would definitely allow
me to use vectors in some places where I've avoided them. But how does the
vector handle the case where re-sizing has moved the data in memory?
Overriding the [] (or &) operator?
Howard said:When it comes to a point where compatibility to arrays comes into the
game, I usually stick with std::vector, as I can easily pass the content
of a vector into a legacy function (&vector[0]) and converting a
returned array into a vector normally doesn't affect performance in the
stuff that I do. (If it does and it was proven by a profiler, then that
is another story!)
--
I wasn't aware you could do that. Is the memory for the objects stored in
the vector guaranteeed to be contiguous?
If so, that would definitely allow
me to use vectors in some places where I've avoided them. But how does the
vector handle the case where re-sizing has moved the data in memory?
Overriding the [] (or &) operator?
Howard said:I wasn't aware you could do that. Is the memory for the objects stored in
the vector guaranteeed to be contiguous? If so, that would definitely allow
me to use vectors in some places where I've avoided them. But how does the
vector handle the case where re-sizing has moved the data in memory?
Overriding the [] (or &) operator?
Howard said:I wasn't aware you could do that. Is the memory for the objects stored in
the vector guaranteeed to be contiguous? If so, that would definitely allow
me to use vectors in some places where I've avoided them. But how does the
vector handle the case where re-sizing has moved the data in memory?
Overriding the [] (or &) operator?
Technically the standard is mute on the subject, but you can sort of intuit that it
has to be. This will be corrected in the TC1. Nobody knows of any implementations
that don't do it "right."
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.