Why does the debugger show only one element from my array pointer? - c++

First off: I know that new is the C++ way of doing this. I am simply showing that there is more than one way to reproduce this error, and both are incredibly frustrating.
I have two forms of this source file. I'm trying to debug yet another programming assignment, but I'm not asking for help on that. Basically, I'm trying to re-implement set as a class with fields for size and a pointer to an int array. Here's the code using new:
testnew.cpp
int main()
{
int size = 1;
int *elements = new int[size];
elements[0] = 0;
size++;
int * temp = new int[size];
for (int i = 0; i < (size - 1); i++)
{
temp[i] = elements[i];
}
delete[] elements;
temp[size] = size;
elements = temp;
elements[1] = 1;
delete[] elements;
}
and again, using the less-preferable alloc functions:
testalloc.cpp
int main()
{
int size = 1;
int * elements = (int *) malloc(sizeof(int) * size);
elements[0] = 0;
size++;
elements =(int *) realloc(elements,size * sizeof(int));
elements[1] = 1;
free(elements);
}
In both cases, my goal is to create an array, and then append to it. However, in both cases, after building and running it in Visual Studio 2010, the array is not grown at all, and only has 1 "slot" for my items to go into. In VS's debugger, I have watches on the elements array pointer; attached is a screenshot. It is the same for both versions of the code.
-- the breakpoint is at the delete[]/free() call.
Seriously, what am I doing wrong? This has to be a logic error, and I've combed through a quarter dozen examples of both malloc/realloc and new, and read and re-read my textbook, and I can't see what's wrong!
I feel like I should have a line that splits the allocated memory into an array, but doesn't the new int[] call do that?

Besides any other issues with the code, you must either do what JoeG mentions and have multiple watches, or set a watch like this:
elements,5
will result in:
I don't know if there is an updated list for VS2010, but this still works:
Symbols for Watch Variables
And:
View array in Visual Studio debugger?

Other answers have pointed out the bug in your code (temp[size] = size;), however your confusion is coming from the fact that you're misreading the debugger's output.
As far as the type system and debugger are concerned, elements isn't an array, it's a pointer. The debugger has no way of knowing whether or not it's a pointer to the first element in an array or a pointer to a single element.
If you want to see the value of elements[x] in your debugger, use the expression *(elements+x).

In the first example, this is wrong:
temp[size] = size;
This will translate to:
temp[2] = 2;
And since arrays are zero-indexed you are writing outside your allocated area.

First of all C++ is 0 indexed, so temp[size] = size; is an off by one error. And to answer your question, the type of elements is int*. That it's actually an array is not knowledge which is available to VS without code analysis. So, what you need to do is either use for example std::vector<>, boost::array or make sure that your array never detoriates to int*.

The file testnew.cpp allocates memory for size elements in temp but then sets temp[size], which is the size+1 element. Perhaps this should be
temp[i] = size;
The file testalloc.cpp commits the common error of reassigning memory to the same variable without verifying that thte call to realloc succeeds:
elements =(int *) realloc(elements,size * sizeof(int));
If realloc fails, elements will be set to null, and its original memory will be orphaned.

Related

Problem implementing a dynamically-sized array

I'm writing an implementation of a dynamically-sized array. The code compiles without errors, but the array elements don't get copied properly. They seem to just get erased (overwritten with 0's). Trying to call a getter on an array element causes a segfault.
The array holds pointers to some basic class objects; this is the main difference between my code and the examples I looked up.
This is the function:
// Pointer to array of pointers
SomeClass** mainArray = new SomeClass[1];
int numItems = 0;
void AddItemDynamic(SomeClass* newVal) {
SomeClass** tempArray = new SomeClass*[numItems+1];
// Copying pointers to bigger array
for (int i = 0; i < numItems - 1; i++) {
tempArray[i] = mainArray[i];
}
numItems++;
// Adding the new value
tempArray[numItems] = newVal;
delete [] mainArray;
mainArray = tempArray;
}
The code should copy the array elements over, then reassign the pointer to the newly created array. Instead, the pointer seems to be set to something else.
If the current array have numItems element in them, then the loop
for (int i = 0; i < numItems - 1; i++)
will copy one less than numItems elements.
And when you add the new element, you go out of bounds of the new array, because you increase numItems to early.
So two off-by-one errors in the same function, one in each direction.
And as mentioned in a comment (thanks Ayxan) the first off-by-one error will mean that the first two times you call this function, the copying loop won't happen. That's actually good when doing it the first time as then there's nothing to copy, but the second time there should be something to copy and yet the loop (currently) won't run.

dynamic memory allocation c++

I have the following dynamically allocated array
int capacity = 0;
int *myarr = new int [capacity];
What happens if I do something like this:
for (int i = 0; i < 5; ++i)
myarr[++capacity] = 1;
Can this cause an error if the for loop is executed many times more than 5? It worked fine for small numbers, but I'm wondering If this is maybe a wrong approach.
You are setting memory outside of the bounds of the array. This might overwrite memory being used in another part of the program, it is undefined behavior. To fix this you should declare your array like this:
int* myArray = new int[5];
which will make it so you don't allocate out of the bounds of the array.
However, it is better to use std::vector. It will prevent situations like this from occurring by managing memory itself. You can add items to a std::vector like this:
Vector.push_back(myItem);
and you can declare a vector of ints like this:
std::vector<int> Vector;
You can read more about std::vector here.
It will cause out of bounds access. This is just undefined behaviour. Your program may crash, your car may not start in the morning, you see the pattern here.
It happens to work fine in your case because usually the OS allocates more than you ask it for, usually in multiples of 2, so probably here it allocates like 8/16..256 bytes at least. But you should not rely on this kind of behaviour.
EDIT The car issue was (almost) a joke, however undefined behaviour really means undefined. C++ standard decided to not enforce compiler checking of many of such issues, because checking takes time. So it declares the behaviour as Undefined Behaviour (UB). In this case, absolutely nothing is guaranteed. If you work e.g. on some small embedded system that controls the rudder of a plane, well, you can guess what may happen.
This approach is wrong in c++. Allocating memory with new allocates memory for new "capacity" objects that you can access without running in run-time error.
Here is a better way to manage the raw array in c++:
int capacity = 10;
int *myarr = new int [capacity];
for (int i = 0; i < 20 ; ++i) {
if (capacity < i) {
// allocate more memory and copy the old data
int *old_data = myarr;
myarr = new int [capacity * 2]
for (int j = 0; j < capacity; ++j) {
myarr[j] = old_data[j];
capacity *= 2;
}
delete [] old_data;
}
myarr[i] = 1;
}
And its always better to call delete []at the end. Another way to use pre-made dynamic array in c++ is to use the std:array(supported in c++11) or std::vector(or legacy support and the preferred option as of me) library which automatically reallocates more memory.
More for the vector and array and examples here for vector here
and here
for std::array.

How to allocate array of pointers to arrays

int (**test)[4][4] = new ???[64];
for (int i = 0; i < 32; ++i)
{
test[i] = new int[4][4][4];
}
I'm trying to create a "list" of pointers that will be initialized to NULL and then later assigned the address of a new multidimensional array of int. The for loop will (eventually) vary in number of iterations, anywhere from 0 to the full 64. I expect to end up with an array of pointers where some are valid and the rest are NULL. The problem is that I can't figure out the syntax for allocating this array of pointers. Basically, what could I put in place of those question marks?
In the name of readability, may I suggest using a typedef?
typedef int (*t)[4][4];
t* test = new t[64];
You will thank me next week when you have to maintain that horrible piece of code ;)

Arrays and pointers in a template

I am attempting to write a template/class that has a few functions, but I'm running into what seems like a rather newbie problem. I have a simple insert function and a display values function, however whenever I attempt to display the value, I always receive what looks like a memory address(but I have no idea), but I would like to receive the value stored (in this particular example, the int 2). I'm not sure how to dereference that to a value, or if I'm just completely messing up. I know that vectors are a better alternative, however I need to use an array in this implementation - and honestly I would like to gain a more thorough understanding of the code and what's going on. Any help as to how to accomplish this task would be greatly appreciated.
Example Output (running the program in the same way every time):
003358C0
001A58C0
007158C0
Code:
#include <iostream>
using namespace std;
template <typename Comparable>
class Collection
{
public: Collection() {
currentSize = 0;
count = 0;
}
Comparable * values;
int currentSize; // internal counter for the number of elements stored
void insert(Comparable value) {
currentSize++;
// temparray below is used as a way to increase the size of the
// values array each time the insert function is called
Comparable * temparray = new Comparable[currentSize];
memcpy(temparray,values,sizeof values);
// Not sure if the commented section below is necessary,
// but either way it doesn't run the way I intended
temparray[currentSize/* * (sizeof Comparable) */] = value;
values = temparray;
}
void displayValues() {
for (int i = 0; i < currentSize; i++) {
cout << values[i] << endl;
}
}
};
int main()
{
Collection<int> test;
int inserter = 2;
test.insert(inserter);
test.displayValues();
cin.get();
return 0;
}
Well, if you insist, you can write and debug your own limited version of std::vector.
First, don't memcpy from an uninitialized pointer. Set values to new Comparable[0] in the constructor.
Second, memcpy the right number of bytes: (currentSize-1)*sizeof(Comparable).
Third, don't memcpy at all. That assumes that Comparable types can all be copied byte-by-byte, which is a severe limitation in C++. Instead:
EDIT: changed uninitialized_copy to copy:
std::copy(values, values + currentSize - 1, temparray);
Fourth, delete the old array when it's no longer in use:
delete [] values;
Fifth, unless the code is going to make very few insertions, expand the array by more than one. std::vector typically increases its size by a factor of 1.5.
Sixth, don't increment currentSize until the size changes. That will change all those currentSize-1s into currentSize, which is much less annoying. <g>
Seventh, an array of size N has indices from 0 to N-1, so the top element of the new array is at currentSize - 1, not currentSize.
Eighth, did I mention, you really should use std::vector.
This line is wrong:
memcpy(temparray,values,sizeof values);
The first time this line is run, the values pointer is uninitialized, so it will cause undefined behavior. Additionally, using sizeof values is wrong since that will always give the size of a pointer.
Another issue:
temparray[currentSize] = value;
This will also cause undefined bahavior because you have only allocated currentSize items in temparray, so you can only access indices 0 to currentSize-1.
There is also an error in your array access.
temparray[currentSize/* * (sizeof Comparable) */] = value;
Remember that arrays start at index zero. So for an array of length 1, you would set temparray[0] = value. Since you increment currentSize at the top of the insert function, you will need to do this instead:
temparray[currentSize-1] = value;

C++ - is a pointer to a single value same as a size 1 dynamic array?

I have this snippet of code which I am considering to simplfy:
if (numberOfResults > 1)
{
trackResult_ = new TrackResult[numberOfResults];
for (int i=0; i < numberOfResults; i++)
{
// Make a deep copy
TrackResult tempResult = result[i];
TrackResult * clone = new TrackResult(tempResult);
trackResult_[i] = *clone;
}
storeJointResults(trackResult_, numberOfResults);
}
else
{
trackResult_ = new TrackResult(*result);
}
(I have 'no choice' but to use a simple dynamic array here. Vectors are deemed 'too complicated' at my workplace)
I am wondering if I can get away with
// even if we just have one result, we init an array size of one
trackResult_ = new TrackResult[numberOfResults];
However, I have in several points check for the number of results and act accordingly
if (numberOfResults_ == 1)
{
velocity = trackResult_.velocity;
}
Would those code still work? If not, why?
The array of size 1 does not need to be a special case.
When you allocate a dynamic array you are given a pointer to the first element. If the array is of size 1, this is pretty much indistinguishable from just having allocated a single instance of the object.
Your special case usage would work if you changed the . to an ->
However I'd recommend not special-casing it and just use trackResult_[0].velocity
No, you need to ensure you match the correct scalar delete or array delete[] depending on whether you say new TrackResult[n]; or new TrackResult;.
Also, this leaks memory for each loop iteration:
TrackResult tempResult = result[i];
TrackResult * clone = new TrackResult(tempResult);
TrackResult_[i] = *clone;
How are vectors too complicated? If anything, the simplify your code.
I agree with Alex, using the . operator on a pointer is not my recommended style either, so those other points ought to be changed anyhow, and thus not discourage you from simplifying the piece of code you mention.