Debug Assertion Failed

I am trying to get a program I wrote to work but I am having a problem. The program is supposed to make use of multiple levels of indirection so that I can get more familiar and comfortable with pointers, but when I run it I get the error: "Debug Assertion Failed! Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse).

The program is supposed to take a file, read the input from it into an array and a vector, then output the data. The vector is to be accessed by a pointer to a pointer to a pointer to the vector, and the array by a pointer to a pointer to the array.

Here is part of the program; I am fairly certain that the error is in here. The rest just outputs the data and deletes the dynamic memory. I may be doing the dereferencing incorrectly at some point; I'm not sure. If someone could take a look and point me in the right direction, that'd be great.

Code:

#include <iostream>
#include <fstream>
#include <vector>
#include <string>
#include <new>
using namespace std;

bool readInput(vector<string>***, string**, int);
bool allocateArray(string**, int&, int);

int main()
{
	vector<string>*** p = new vector<string>**; //Defines the pointers to the vector
	*p = new vector<string>*;
	
	string** r = new string*; //Defines the pointers to the array
	
	int size = 10; //For the array size
	bool flag = true;

	flag = readInput(p, r, size);
	
	//The rest is omitted
	

}

// Defines the vector, calls the allocateArray function, and puts the data 
//into the vector and array.
bool readInput(vector<string>*** vec, string** arr, int s)
{
	bool flag = true;
	int count = 0;
	ifstream inFile;
	string name, input;
	inFile.open("TopicAin.txt");

	while (!inFile)
	{
		cout << "Please enter a valid file name" << endl;
		cin >> name;
		inFile.open(name);
	}
	**vec = new vector<string>; //Define the vector 
	flag = allocateArray(arr, s, count); //Define the array
	
	if (!flag)
	{
		cout << "Error allocating array." << cout;
		return false;
	}

	while(!(inFile.eof()))
	{
		inFile >> input;
		(***vec).push_back(input); //Put the word into the vector
		if (count == s) //Call the allocateArray function if the array is full
		{
			flag = allocateArray(arr, s, count);
			if (!flag)
			{
				cout << "Error allocating array." << cout;
				return false;
			}
		}
		*((*arr) + count) = input; //Put the word into the array
		count++;
	}
	if(inFile.fail())
		flag = false;
	inFile.close(); //Close the file
	return flag;
}

//Allocates the array and reallocates it as necessary
bool allocateArray(string** arr, int &size, int count)
{
	if (count == 0) //Runs the first time through
	{
		*arr = new (nothrow) string[size];
		if (*arr == 0) //Tests if the allocation was successful
			return false;
		else
			return true;
	}
	
	if (count != 0) //Runs every time after the first
	{
		string *ptr = new string[size];
		for (int i = 0; i < size; i++) //Allocates a new array to hold the current words
			ptr[i] = *((*arr) + i);
		delete *arr;
		size *= 2;
		*arr = new string[size]; //Allocates a new array double the size of the old one
		for (int i = 0; i < (size/2); i++) //Puts the words back into the array
			*((*arr) + i) = ptr[i];
		delete ptr;
	}
	if (*arr == 0) //Tests if allocation was successful
		return false;
	else
		return true;
}

Uh oh, we've got ourselves a three-star programmer

Hold on a sec whilst I try and close my agape mouth, and I'll repost shortly.

Edit: Okay, this is not a good place to use pointers. Although understanding of pointers is important, you should learn about single pointers first, rather than pointer-to-pointer-to-pointer.
Once you're very comfortable with single pointers, you'll probably understand double-pointers no trouble.
Triple pointers are however bad news. Using such a thing is a design no-no.
See if you can reduce things down to using references where possible and reduce the number of stars.

Where you do choose to go even so far as a pointer-to-pointer it is almost certainly going to be clearer using typedefs.
Take advantage of the fact that *(a + i) is the same as a[i] and use a clearer syntax. Likewise, (*p).m is the same as p->m
Turn your compiler warning level up and pay attention to all warnings.

iMalc's is perfectly correct in pointing out that too many levels of indirection make code very difficult to get things right. Wrapping one's mind around too many levels of indirection is a difficult task. In a learning setting it is not a good idea. In a production environment, it is a recipe for chaos.

One of the things you've managed to get wrong is to use the non-array operator delete to release memory allocated with the array form of operator new. That is undefined behaviour.

I haven't looked closely enough to identify any other errors, but I wouldn't exclude the possibility of them being there.

Mixing nothrow operator new with throwing operator new is usually not a good idea either. Not so much because it is wrong, as it is another opportunity for confusing yourself.

While it is true that the a[i] is equivalent to *(a+i) you gain little by using the *(a+i) form except the opportunity for more confusion. So change lines like "*((*arr) + i) = ptr[i]" to the equivalent "(*arr)[i] = ptr[i]".

The fact you are using pointers (to pointers to pointers) to standard containers also increases your opportunities for self-confusion. Standard containers - particularly vector - are designed to be used as an alternative to dynamically allocated arrays, not as objects to be manipulated through raw pointers.

Thanks for the responses. I fortunately was able to find my error and the program now works. The only problem I had left was not including the [] in my deletes of arrays. I did it in one case but forgot it in the other two, woopsies. Thank you for pointing that out.

As for using using *(a + i) instead of a[i], I just felt like doing it that way. Is there any benefit other than clarity to using a[i] instead of *(a + i)?

Originally Posted by Freddy92

Is there any benefit other than clarity to using a[i] instead of *(a + i)?

No. Conversely the only (negative) benefit in using *(a+i) instead of a[i] is a reduction of clarity.

Some people view ability to perplex other programmers as a benefit. I do not.