BBCBASIC and C++

[Ivan]

I prefer to use lower case because it's easier for my eyes and to read.

I think it's normal today that the cursor is not changing shape from overwrite versus insert and I often forgot, but CodeBlocks is using shape shift.

What kind of programs are you writing?

[KenDown]

All sorts of things that I find useful. My biggest project is "NewDisplay" which is a sort of "PowerPoint" that does what I want it to do, including all sorts of clever things that PP doesn't do (underlining or drawing on the screen live, for example). It is optimised for church presentations. See www.nwtv.co.uk/display/

On the whole I tend to write Windows programs - that's what I find most useful - using my own BasicOutline that does most of the hard work handing windows and dialog boxes for me; I just(!) need to write the code for what happens when I click on a particular button. If you would find it useful let me know - but be warned: I wrote it to please myself, so spaces are kept to a minimum and BASIC commands are in upper case!

[Ivan]

Oh oh uppercase

Thanks anyway, but I will rather use consoles. I’m only using Windows as little as possible. I might change to Linux because I'm fed up with MS after installing Window for three decades. The latest version 10 takes a long time to de bloat and if they force users to change hardware in the next version I will spend some serious time with Linux. C++ can be used on almost any system.

I have been inspired among by a guy named Uncle Bob. He had made very good videos about Clean Code.

The ordering system build on my own design a relations database (4 files) with editing facilities in each field and instant file updates is almost converted from BBCBASIC to C++.

The C++ libraries have anything you can think of, but I want to learn the language to some detail. I coded my own instr and mid function in a very short time and it's very satisfying. And if they don't behave as you like you just change their properties and you are not tied up a specific way to use a function.

For now I think I will continue my transition to C++ mostly because BBCBASIC seems to have stopped evolving. I’m pleases to find that the transition goes more smoothly that I expected.

[KenDown]

Yes, not everyone loves Windows - I disapprove of it, but find it too useful and even relatively easy. Of course, not a patch on Risc-OS, where you really could do anything you wanted. I still look with longing at the four volume guide on my bookshelves ... Ichabod about sums it up!

That's the great thing about programming; you create the programs *you* want, which do the things *you* want, in the way that *you* want. I can see the arguments for super-duper, slick, professional programs, easy to use off the shelf, but what's the good of that if it almost but not quite does what you want?

I really don't know what you mean by complaining that BB4W has "stopped evolving". Richard has stopped "tweaking" it because it now does everything that you could expect from a Basic; it has all the commands and more than any other version of the language I know of, it can do more than any other version (that I know of). If it "evolved" any more, it would no longer be Basic!

Still, you can always get into Richard's SDL version and add to or ammend it as much as you please (if I understand correctly). It is not linked to Windows and there is a Linux version. If you are able to evolve that into something better, I'm sure we'd all be very interested.

[Ivan]

As you clearly can see, English is my second language I had to learn as an adult. Am I wrong when "complain" is a little negative - if so, it's is more meant as an observation. I think Basic today should evolve more:

A few features that spring to mind that I would welcome:

Redim or dynamic arrays
Strict typing
Enumeration
Constants
Access to structs without curly braces
No reuse of variable name in the same scope

Maybe some inspiration from Basic256 - it’s the most intuitive Basic I had ever encountered.

I had a try at SDL Basic and it's not for me.

Of topic - I suppose you live in England. I hope your supply of petrol and consuments is been better?

[KenDown]

No, I didn't pick up that English was not your native tongue - though I suppose I should have guessed from your name.

Given the way BBC BASIC handles its variables, I think that altering array sizes would be very difficult and very wasteful of memory if done. You do have DIM LOCAL which would allow you to create temporary arrays within a procedure, potentially of a different size each time.

I'm not sure what you mean by "strict typing". If you mean that input is constrained to upper or lower case or that is must follow a particular template, that is easily done by the user (if he considers it important).

Code: Select all

REM Upper case
FORi%=1TOLENstring$:c%=ASCMID$(string$,i%,1):c%=c%AND223:MID$(string$,i%,1)=CHR$c%:NEXT

REM Lower case
FORi%=1TOLENstring$:c%=ASCMID$(string$,i%,1):c%=c%OR96:MID$(string$,i%,1)=CHR$c%:NEXT

Actually, you would need an IF statement in there as characters outside the normal ascii range of 33-126 are messed up.

I haven't a clue what you mean by "Eumeration" or "Constants" and I fail to see what the problem is with curly brackets.

Yes, it might be useful if there was error checking built in to pick up reused variable names. I guess the solution is to make everything LOCAL so that it wouldn't matter if you did happen to re-use a variable name.

No, I live in Wales, where so far, at least, the garages are open and I personally have not been affected by empty shelves in the supermarkets. Once or twice we have noticed empty shelves, but they have been for things we don't buy like meat or fish. There are advantages to being vegetarian! (The papers predicted the awful prospect of nut roast instead of turkey for Christmas. Sounds delicious! Who would want to eat a dead animal?)

[DDRM]

Hi Kendall and Ivan,

Your case conversion functions are likely to cause problems for any characters outside the alphabetic ones, so you'd need to wrap them in a test that they lay in the range 65-90 (Upper case) and 97 - 122 (lower case). Having done that, you can switch between U/C and L/C by toggling the bit equal to 32.

That's not what Ivan meant by strict typing, though - he meant that variables were forced to be of a particular type. Actually that IS the case for BBC BASIC: string variables MUST end in $, 32 bit integer variables must end in %, and 64 bit integers must end in %%. The water is muddied slightly by the "variant" type: anything not ending with $ or % is a variant: this includes 80-bit floats, but will also handle integer values as 64 bit integers, which allows faster integer functions to be used where possible. It is up to the user whether they want to use this muddiness: you are welcome to consider all variants as floats.

You are right that there aren't (enforced) constants: by convention, variables all in uppercase are considered as constants, but there's no enforcement of this- you are free to change them!

REDIM/Dynamic arrays: as Kendall says, you can do this to some extent by wrapping things in a procedure if you only need them temporarily - or you could "roll your own" by using Windows memory allocation functions, using the SYS command? You could even make a library available for others to use...

Similarly with enumerations: you could implement this, but I suspect it would be significantly slower and more complicated. Enumerations are, I think, generally a feature of compiled languages, where the compiler can swap them for their "real" values at compile time?

Variables within scope: actually, this is the case, but scope is generally pretty broadly drawn (global vs within a procedure or function) - so loops etc don't have their own scope. Variables used within a procedure/function will be the global ones unless a local version is declared.

Structs without {}: OK, but they were added late to a language which didn't already have them, so Richard had to find a syntax that would allow them to be identified without breaking existing programs! Once you've declared the structure you no longer need the curly braces: so you can have myPoint.x_coord, for example.

In my limited experience of other languages (C/C++, Python, Java), declaring structures needs a special syntax anyway, so the curly brace approach doesn't feel too onerous to me...

Best wishes,

D

[Ivan]

@Ken I think you are being nice regarding my English

I live in Denmark and the BBC Micro was popular and so was Acorn User and MIcro User.

Vegetarian - my wife and I are flexitarians - we eat mostly vegetarian food > 95% and consume only ecological products.

My next BBCBASIC code will have as much local variables as possible.

DDRM explains it well.

@DDRM I was not aware of using structs without curly braces - it makes it a lot easier for me to read.

Defining a simple struct in C++ looks much as a BBCBSIC struct. You can also initialize structs with data when defining and also have a kind of local/global functions inside struct as well as variables and much more.

When i code with structs in reality classes which are much the same the IDE will only show member variables/function if had defined the struct/class correct. Again it prevent a lot of errors.

With dyslectic issues as I have, strict typing takes many of my typos, because the IDE/compiles catch them.

[KenDown]

Yes, I recognise that problems are possible but if, for example, someone is typing in an English address or name, they are unlikely to be using umlauts or acutes. Otherwise, you are correct that one would need to check for alphabetic characters. Well, just checking, c%AND223 returns upper case or useful characters between 64 anad 126, likewise c%OR96. Below 64 you get problems.

Thanks for clarifying the other points - though I'm still not clear on what an enumeration is!

[KenDown]

Denmark!? Is Ivan a typical Danish name?

Yes, as my Display program has grown, I've had to rewrite using LOCAL variables just about every procedure or function, as even the loop variables kept getting confused otherwise! The only problem is that LOCAL variables can be "inherited", as illustrated by this sample program:

Code: Select all

      PROCone
      PROCtwo
      END

      DEFPROCone:LOCALi%
      i%=6
      PROCthree
      ENDPROC
      :
      DEFPROCtwo
      PRINT"Two" i%
      ENDPROC
      :
      DEFPROCthree
      PRINT"Three" i%
      ENDPROC

In other words, because PROCthree is called from within PROCone, the LOCAL value of i% is passed onwards, whereas PROCtwo, which is called outside PROCone, does not receive the LOCAL value. Of course, if you declared i% to be LOCAL in PROCthree, it would be local.