Thread: Converting MINI-BASIC in MASM over to C++?

>> But it's still WRONG to do it that way, even if it's easier/cleaner. minibasic still isn't "IS-A" token_scanner, per se.

Having minibasic derive from token_scanner isn't necessarily saying that it "IS A" token_scanner so much as it is simply "importing" the object into it's namespace, so to speak. Parsers written in C employ this technique quite often, in fact: rather than passing a parameter to the scanner routines, they define global pointers to the text being parsed, so that instead of having to use constucts such as parse_expression(char**), they can omit the parameter altogether. The point is, the object-oriented "IS A" relationship shouldn't be taken to far here - it's just a matter of convenience.

>> And we certainly shouldn't really have two (different ones) of them when "compiling", do you think?

How so? As far as I can tell, the compiler just needs one. Can you elaborate?

>> Inheriting certainly will fail the "multiple types of console" thingy

In that case, it makes more sense to keep the singleton accesses as is, make the console class a virtual base class, define whatever console classes are needed and then in the minibasic constuctor, have the proper one instantiated, something to the effect:

Code:

class minibasic
{
	std::auto_ptr<console*> the_console;
	
	minibasic(int, char**)
	{
		// ...stuff...
		while (*(++argv))
		{
			// ...stuff...
			if (string(*argv) == "-s")
				the_console = new studio_console();
			else if (string(*argv) == "-c")
				the_console = new normal_console();				
		}
		if (the_console.get() == 0)
			the_console = new normal_console();
		// ...stuff...
	}	
};

Note that no other changes would be necessary in the rest of the code.

OK, I've pushed an update. For now, I've changed PRINT_TEXT to do exactly what PRINT_NUMBER does, although I'm not sure if that's 100% correct. And I did remove the padding reset within show_pad, since the setting should remain in effect until the entire print statement has been executed.

OK, it seems by fixing one bug I created another. I've pushed the newest bugfix.

There were just a few more functions that haven't been implemented yet. I've added 'NEW' (just unloads the program from memory). 'SIZE" seems to be meaningless in this context, so I simply return numeric_limits<int32>::max() (any better ideas?). I'm not yet sure how to implement 'EDIT', though. Besides that, it there anything I've missed?

Ok, I'll leave the inheriting of token_scanner as is for now. (By having two, by the way, I mean that there is one in minibasic itself and another in the compiler).

I'll be looking at having long variable names.

--
Mats

I've pushed up some minor "fix warnings" changes - I'm using Visual Studio 2008 Express edition as well as gcc-mingw 3.4.5, and VS is stricter on some things - so I fixed those.

It also asserts on this bit:

Code:

			pchar end = pchar(&buffer[size]);

so I made it:

Code:

			pchar end = pchar(&buffer[0] + size);

I still get another assert [I just discovered when test-loading pitman] that has to do with accessing outside of a string in "empty" - I will try to fix that too.

Edit: fixed several minor "trying to go past end of string" and similar problems.

--
Mats

>> I still get another assert [I just discovered when test-loading pitman] that has to do with accessing outside of a string in "empty" - I will try to fix that too.

I just found that, too. I just changed the line in empty() to: if (skip_ahead && seq != fin), and it seems to work fine.

Or maybe not. More testing needed, I guess.

OK, never mind, that was the problem, sorry.

Have you push your latest changes? I just want to pull them so that I can incorporate what you've done before I push my changes.

I think I've fixed those asserts and a few others, yes.

I also refactored a bit of the compile-code [as I was trying to understand it to enable long variable names]. So, I moved the for and next generation out into separate functions.

--
Mats

OK, great. I'll go ahead and pull it now.

OK, the only change I made to your update was in the current() function: I had it throw an exception rather than return 0 (ie: if we get to that point it indicates a premature end-of-input condition).

The latest update implements the last functions that I know of.

EDIT works, if only slightly different from the original program: the existing line is not printed simply because that would require a major (and unecessary) overhaul of console::get(string). As it is, the user simply needs to use the LIST function to view the existing line. Does there need to be an escape mechanism, though, in case the user wants to abort the edit?

Also fixed the way the console is reset after a program is run (before it was clearing the screen), as well as a few other minor changes.

The current version is at 1.99, so I guess the next change should bring it to 1.991.

Well, I undid the change I made - seems you had it right.

I'll go ahead and push the latest update.