I call bools**t

[cire]

The files, assembly programs, are all tab-delimited.

So, there never occurs a line where the first token found, on lines that don't begin with a tab/comment indicator, is not followed by a tab?

How about empty lines? Any of those?

By the way, it still freezes, even if I take your suggestion!

What suggestion?

In fact, if I create other program and throw this code in it, I get

What code?

[Hotice]

The only lines that don't have a '\t' in them are the comment lines (preceeded by a '.' or the space lines. The space lines can be taken care of by the main() function (after a slight modification), so those are not of issue. As for the suggestions, I tried checking to see if there is even a '\t' at all! (I make program throw error if a line of actual code in the file is not tab delimited.) As for the code, the minimal code needed for a test run. It works (as in freezing later) if I check for comment lines or '\t' being the first character in the findlabels(). (Maybe I should make a boolean function iscomment(), and then conditionally run findlabels()? That would seem to not only make coding a little more clear, but maybe defer or eliminate the uncaught error.)

[Hotice]

It's crashing no matter what I do! But, this time, it only crashes after findlabels() finds the first label (and prints it to the screen)! Making a bool assemblytoopcode::iscomment() (which checks for comments and empty lines) did make the code more algorithmically efficient (and simplified findlabels()). Both findlabels() and findoperands() only make it through eight lines of the following assembly program:

 	LDS	#3	.Initialize Register S to 3
	LDT	#300	.Initialize Register T to 300
	LDX	#0	.Initialize Index Register to 0
ADDLP	LDA	ALPHA, X	.Load Word from ALPHA into Register A
	ADD	BETA, X	.Add Word From BETA
	STA	GAMMA, X	.Store the Result in a work in GAMMA
	ADDR	S, X	.ADD 3 to INDEX value
	COMPR	X, T	.Compare new INDEX value to 300
	JLT	ADDLP	.Loop if INDEX value is less than 300

ALPHA	RESW	100
BETA	RESW	100
GAMMA	RESW	100

Note that any entries in the first column are labels...
Here are the updated functions:

bool assemblytoopcode::iscomment()
{
    if ((aline[0] == '.') || (aline == ""))
    {
        aline = "";
        return true;
    }   //end if
    else return false;
}   //end iscomment

void assemblytoopcode::findlabels()
{
    //Maybe this could be made more algorithmically efficient...
    if (aline.at(0) != '\t')
    {
        cout <<"Am I going to freeze, yet?"<<endl;
        pos = aline.find_first_of('\t');
        if (pos != aline.npos)
        {
            templabel = aline.substr(0, pos);     //Extract the label to temporary variable
            cout << "This is what got saved to templabel: "<<templabel<<endl;
            //Erase the label from the parsed line (ease of coding at the price of added algorithmic complexity, of O(l), where l is length of file)
            aline.erase(0, pos);
        }
        //Store to a vector (if it isn't already!);
        if (templabel != "")
        {
            labels.push_back(templabel);
            cout << "Did I make it?"<<endl;
            if (labels.size() != 0) for (int j = 0; j < (int)labels.size(); j++) cout<<"labels["<<j<<"] == "<<labels[j]<<endl;
        }   //end if
    }   //end outer if
    else
    {
        //aline.erase(aline.begin()); //delete the tab character
    }   //end else
}   //end findlabels 

(For some reason, commenting out the statement in the else part of findlabels() makes the program go from three processed lines to eight...)
Oh, and just making another program with all the functions called and the file being automatically inputted into ifstream takes away the crash. Is the crash happening because the stack the compiler is using is being overloaded?

[Hotice]

Problem resolved! The problem is where I pointed initially, at the way I was asking the user to input a file and then using that file to generate the machine code. It turns out that whenever you are declaring an instance of ifstream, the constructor value must be a C-style string, which is a dynamic array! Any dynamic array must be deleted for more dynamic memory to be allocated (especially to future dynamic arrays). What I was doing was making a heap of objects based on data obtained via the dynamic array that was my file. In short, all I had to do was create a vector storing the lines of the files, and in my while (myfile.good()) loop, push each line into the vector! Then, I am done with the file and don't need to use it anymore, which means no more *complicated* calls, which means no overloading of the compiler's stack/heap, which means no crash! I will leave this topic unmarked, so discussion can commence, or for someone to correct me on this answer (if necessary). I could always learn more.

[Hotice]

Just when I get it to stop crashing, it wants to crash when I put it on my flash drive (and run it from there), or if it is in a different folder. Does this have anything to do with ifstream using a search tree to find the file?

[Hotice]

I think I found the source of the error. I went to a computer running Windows XP, and it seems to run without crashing, but on any Windows 7 computer, it crashes. I wonder why this is.

[Hotice]

When I try to debug, I get the following error:

Unhandled exception at 0x770615de in assembler main(2).exe: 0xC0000005: Access violation reading location random location

The location the compiler is trying to read seems to randomize each time. I am still a newbie with using a compiler. I don't get what this will tell me that I don't already know, or what I can change about my program. Here is the updated C++ program: http://www.megafileupload.com/en/file/374328/assembler-main-2--cpp.html The compiler I am using is just the standard GCC compiler and my debugger is in Visual Studio 2010. I MUST find this error if I am to go any further, and I have spent days (without overall success) trying to find it. Every time I think I found it, or have made it work, the success is only temporary, as I run it somewhere else (with the same settings) and it crashes again!

[cire]

  cout << "The crash happens here!"<<endl;
    cout << "a[n].checkduplicates() == " << a[n].checkduplicates()<<endl;
    a[n].PressEnterToContinue();

n is the number of elements in a. The valid indices for a are 0 - n-1.

n is superflous anyway. If you used a.size() everywhere you used n, this mistake would've been much more obvious. n doesn't need to exist.

[Hotice]

This solved the problem! I got too much into the analysis, and started seeing problems where none existed. Thanks for this! Now, it is time for me to go onward!!