BBCBASIC and C++

[DDRM]

Can I suggest gently that this conversation is wandering away from relevance to a BBC BASIC forum?



D

[Ivan]

Absolutely you can. One of my thoughts was that others maybe was a bit lost when Richard decided not to continue this version of BBC BASIC. So it was an attempt to encourage others not to be too worried to switch to C++, because many of the features from BBC BASIC can be reused.

And I will not make more “noise” unless requested, but of course still related to BBC BASIC as I think my writing have done until now.

[KenDown]

I think there may be some things - graphics, mainly - which would be faster in C than in BASIC. What I would like would be the ability to write snippets of code for those specific tasks and incorporate it into my BASIC program. So the subject is not entirely irrelevant, methinks.

[DDRM]

Mixing C and BASIC, as suggested by David Williams, would definitely be on topic: if he (or anyone else!) wanted to offer a tutorial on how to do it I think that would be very welcome. I'd suggest that is more likely to be C than C++ (the latter is very much object-oriented, and mixing that in probably wouldn't be easy) - though of course C programs will run in C++, since it's an extension of it.

I felt it was drifting off into a discussion of the merits of C++, which is off-topic.

BW

D

[KenDown]

One obvious way of doing so is to use OSCLI. From inside my "Display" program I can execute programs or program snippets by simply OSCLI("progname.exe"). The executable runs, terminates and then I am returned to my own program. It is useful to add a semi-colon to the filename as that signals that your own program is not to suspend operations while the executable does its thing.

OSCLI("progname.exe;")

[Ivan]

Mixing C and BASIC, as suggested by David Williams, would definitely be on topic: if he (or anyone else!) wanted to offer a tutorial on how to do it I think that would be very welcome. I'd suggest that is more likely to be C than C++ (the latter is very much object-oriented, and mixing that in probably wouldn't be easy) - though of course C programs will run in C++, since it's an extension of it.

I felt it was drifting off into a discussion of the merits of C++, which is off-topic.

BW

D

It's off-topic if one is satisfied to agree that BBC BASIC is not evolving anymore as I see the situation respectfully

A while ago I suggested even to paid for small extensions but Richard refused to do anything than correcting errors.

From my view I love BBC BASIC and it's almost 40 years ago I tried BBC BASIC for the first time.

Otherwise I think BBC BASIC could be extended and be better with a small amount of features - especially the debugger.

I want to learn much more despite I'm a senior and extending my skills.

I do not know much of C but I'm pretty sure that C++ is more secure.

Some other paided Basics are still evolving and I had hoped that someone could continue BBC BASIC - even for an upgrade fee. I would pay instantly, but maybe BBC BASIC is becoming a niche language for few people...

[KenDown]

In fairness to Richard, he has put all his effort recently in the SDL version, which is available in flavours for IBM, Apple, Android and probably others. In addition, as I understand it, the language has been created so that users can make their own modifications and extensions.

Personally I find BB4W does all I need, but if there is some extension to the language that you feel would be useful, play around with SDL and add the extension in, then post it somewhere and over time I guess it might become standard if enough people find it useful.

[Ivan]

I did a BB4W program a while ago and it is about 3000 lines. For me it's large program and I might had separated in smaller parts. Debugging is a nightmare, because it have start from beginning each time and I can't chose which variables/arrays/structs I want to watch/check. If the indention and debugging have been modernized I would have stayed with BB4W, because it have tons of good qualities.

I tried to setup SDL and never figured out how to use it.

Respect to Richard, but he is only one man and does he have anyone to back him up?

And I don’t understand why it’s necessary to all these platforms.

I have came across another basic – sdlbasic. Also a multiplatform basic.

[KenDown]

Debugging is always a problem, but it is greatly eased by following simple techniques such as structured programming, lots of REM statements, meaningful variable names and so on. You can easily set up a warn box and then have that come up on screen to inform you of the value or state of variables and arrays while the program is running. Or you can set breakpoints using STOP or - my favourite - the nonsense word RUM which will bring your program to a crashing halt and allow you to discover the value of variables or which line is causing the problem.

I don't know what your complaint is with the indentation; it seems just fine to me. Can you be more specific?

I'm afraid that I don't get on with SDL either, but others give it glowing reports, so the problem is probably with me rather than with the language.

Yes, it is a problem that Richard is a one-man-band, which makes the future of both these languages doubtful.

If you write a program that you want to sell or distribute widely, it can be useful to have it available for Windows and also for those odd people who use Apple's products. If you want to write and distribute apps, then being able to provide an Android compatible version is vital. Of course, if you only ever write for your own amusement, then there is no need to compile for these other platforms.

Just in case it is useful, below is the dialog box setup, the procedure to handle the warn dialog box, and a typical use for the dialog box to display the value of the variable variablename% Create the dialog box as part of your initialisation routine, put PROCtwarn somewhere in your program, and call the procedure whenever you want to inform the user of something. (In this case, you are the user and the information is the value of a particular variable.)

Code: Select all

      PROCtwarn("Clock Error",STR$variablename%)
      :
      REM Handles a temporary warning window that closes automatically
      DEFPROCtwarn(title$,mess$):LOCALT%,g%,mb%
      PROC_showdialog(warn%)
      SYS"SetWindowText",!warn%,title$
      SYS"SetDlgItemText",!warn%,900,mess$
      T%=TIME+300
      REPEAT:g%=INKEY(0):MOUSEmx%,my%,mb%:UNTILTIME>T%ORmb%>0ORg%>0
      PROC_closedialog(warn%)
      ENDPROC
      :
      REM Warn dialog box
      warn%=FN_newdialog("Warning",80,0,280,80,10,10*50)
      PROC_static(warn%,"",900,4,4,272,50,1)
      PROC_pushbutton(warn%,"OK",901,114,64,54,12,1)

[DDRM]

There are a number of debugging resources available in these versions of BASIC: there's a "List Variables" windows, as well as the option to trace execution, in the Utilities menu, as well as options to introduce breakpoints. You can use the Cross Reference utility to identify variables which are unused/don't follow naming conventions, are out of scope, etc.

As you say, if your program is getting unwieldy to edit and debug, why not break it up into chunks by splitting some of it out into custom libraries? Then you can get one bit at a time right.

Best wishes,

D