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

Originally Posted by Paul Panks

What's the difference between C and C++? I've always wondered.

Paul

In one way, not a lot. In another way, lots.

The big difference comes with the philosophy behind the language, C++ is an object oriented language. C is a procedural langues, and not intended as an object oriented language (although it can technically be hammered into something that resembles object orientation).

C++ is based on C, which means most C code can be compiled as C++, but "proper" C++ can not be compiled in a C compiler.



To understand more of the differences, you probably need a better understanding of at least ONE of the languages.

--
Mats

Are you suggesting that I run a program built on a machine that may have a virus?

No. I do most of my development on my laptop or personal desktop. I just happened to be on the possibly infected desktop named Scratch, where I have a very casual approach to security, when I posted. I didn't really think about it until after I posted. And... well... better late than never.

Oh and by the [...] I'll post that code as well.

No. I haven't even started working on that. I wanted to cleanup the source first--utilizing more of the C++ STL to simplify the implementation.

On the other hand, we should probably finish what we've already started before moving on to making it fully C++.

*shrug*

Fine with me, but I'm not back-porting my parser changes. I couldn't handle all the `std::string' to `char *' conversion problems. It would make me cry.

We can clean things up near then end. Go on and post what you have.

No, but I will post a new source... say version 1.4 that has a few fixes and a couple of back-ports. Well... okay, I will not do that either because the version 1.3 source I'm working from has some IO bugs that prevent me from testing the work as I go.

*shrug*

Instead, here is my version 1.4 (from the posted 1.3) with a few bug fixes and a completely different set of changes. If you can apply your IO fixes to this source, I'll take the time to look over it and figure out the approach you and matsp have taken so than I can apply my other fixes and back-port what bits will go smoothly.

*sigh*

Okay, the IO bits have problems enough that I can't even back-port the removal of the `std::longjmp'/`std::setjmp' stuff--I'd be flying blind. I'll wait for the IO update to play with that.

Edit: Also, as a matter of interest, I wasn't thinking clearly when I started my design and I've had to change parts of it pretty significantly. I'm just used to having tools like `???::bind', `???::function', and `boost::any' available. Yea, so... I need a different approach to support user-defined functions. (I could code a simple "drop in" that could equate to `boost::any' and `???::function' easily enough, but `boost::bind' requires a pretty significant set of primitives.)

Edit: I've taken time to mark most of the changes I've made with "(ZSV)" so you can find them easily enough. There are also a few questions there one of you can probably answer from the original assembler--which I'm not touching again. A few notes as well are marked.

Edit: And many of the changes are purely conformance fixes--now support several more Windows targeting compilers.

Soma

(For the curious, I typed my post on my laptop as I was playing with the source on my desktop... hence the rambling tone.)

Well, I've been quite busy, but I have managed to fix the input issues with a major rewrite (99% complete). Besides that, I haven't had any time to incorporate Soma's changes yet, and the program needs a good once over before it'll be ready to release. All in all, I would say we're about 85% complete, barring any major problems. I'll post an update of the code soon, though.

When I last looked at the code about three weeks back, it was nearly all C, but not entirely.

But I'd certainly like to move it further towards C++.

--
Mats

I've just taken the 1.4 code posted above, and it has a fair bit more C++ style things in it. It's still not "good" C++ tho!

I couldn't compile the current code, becuase INPUT is defined in winuser.h, and conflicts with our use of "INPUT". I'm inclined to fix this (and a few other things like it, e.g. DEBUG) by:
1. Moving all the "commands" into a separate .cpp file.
2. Putting those bits into a namespace.

--
Mats

Originally Posted by phantomotap

It sure isn't; it's far from it. I was going to do more, but the IO stuff was blocking me and I didn't want to duplicate the work Sebastiani was/is doing. (I could load existing code, but for whatever reason I couldn't write new code to drive/test my changes.)

I say don't touch the 1.4 code I posted until we see what Sebastiani has done for the IO.

Soma

Well, I have just split everything up. I may have to do more work, but my feeling is that I need to start doing stuff here, or I will be out of the loop forever!

I have split the code up into "mbcommands.cpp", "mbcommands.h" and "mbutil.h" (the latter being just a header to share declarations between the main and the commands source files.

It compiles and appears to work. I'd like to reduce the use of globals - I will have a look at how we can do that now.

I'm also going to rewrite the copy-loops for Peek/Poke!

--
Mats

Major changes to code-structure - new files:
mbcommands.cpp
mbcommands.h
mbutil.h

It is by no means finished, but I've restructured the code a bit. I've also rewritten (as promised) the copy loops for variables and peek/poke values to use memcpy - and memset to clear the new part.

I've one done some rudimentary testing, but I've not found any new bugs [that's not to say there aren't any!]

--
Mats

Originally Posted by Paul Panks

Looking good. What other changes are being made?

Paul

Not much - some clean-up of the code, but that's about it. I spent about 2 hours in total doing that splitting work. I have probably not spent much more than 15-20 hours on the total project.

--
Mats