For WinFBE users

[deltarho[1859]]

When starting a new project, I always make the first statement '#Console On. The reason is that if we choose a GUI build configuration and use a Print statement, we get into trouble and have to end the task via Task Manager. I say 'always' but I do forget every so often. We can always comment out the first statement if we don't use Print.

What I have wanted was a File>New with a blank opening but with '#Console On as the first statement. I now have a way to do that. I wanted to go one step further and add my integer datatype syntax conversions.

This is how it can be done.

Copy the following and Paste into a text editor:

Code: Select all

2
FBCONUI
.bas
.Console On
'#Console On
#ifndef Uint8
  #define Uint8 = Uinteger<8>
#endif
#ifndef Uint16
  #define Uint16 = Uinteger<16>
#endif
#ifndef Uint32
  #define Uint32 = Uinteger<32>
#endif
#ifndef Uint64
  #define Uint64 = Uinteger<64>
#endif
#define Uint3264 = Uinteger
#ifndef int8
  #define int8 = Integer<8>
#endif
#ifndef int16
  #define int16 = Integer<16>
#endif
#ifndef int32
  #define int32 = Integer<32>
#endif
#ifndef int64
  #define int64 = Integer<64>
#endif
#define int3264 = Integer
 

and save as ConsoleOn.fbtpl

Drop the resulting file into WinFBE's Templates folder.

In WinFBE's Templates window you will now see this.

Choose '.Console On' and you are good to go.

Needless to say, you are now armed with a method to devise other templates to your heart's desire. You could, of course, rip out my integer datatype syntax conversions if you do not want them.

[deltarho[1859]]

You may have some definitions/macros that you use very frequently in your code. Drop them into your '.Console On' template.

I use these two by MrSwiss quite a lot.

Code: Select all

#Define IsFalse(e)  ( Not CBool(e) )
#Define IsTrue(e)   ( CBool(e) )

They should be built into fbc - they are in PowerBASIC.

[Munair]

IsTrue is another way of testing if an expression is not null?

[deltarho[1859]]

IsTrue is another way of testing if an expression is not null?

Yep.

With regard 'ConsoleOn.fbtpl' you could, for console applications, forget that and go with 'GenericConsoleTemplate.fbtpl' plus some of your additions.

Has 'GenericConsoleTemplate.fbtpl' always been there? I don't think it has. It may have been sneaked in without telling us. Perhaps Paul used to work for Microsoft. Just kidding, Paul.

[Munair]

They should be built into fbc - they are in PowerBASIC.

While cbool isn't an expensive conversion, what is the benefit of if IsTrue(UpperBound) then ... over if UpperBound <> 0 then ...?
Strictly speaking, a number being 0 or not 0 doesn't make it false or true. Defining it as such would only lean on the definition of TRUE and FALSE generally agreed upon. Not to mention code readability. Just my two cents.

[PaulSquires]

IsTrue is another way of testing if an expression is not null?

Has 'GenericConsoleTemplate.fbtpl' always been there? I don't think it has. It may have been sneaked in without telling us. Perhaps Paul used to work for Microsoft. Just kidding, Paul.

the whole file template system came from Jose Roca and his PB editor.

[marcov]

While cbool isn't an expensive conversion, what is the benefit of if IsTrue(UpperBound) then ... over if UpperBound <> 0 then ...?

Istrue() can be completed by an IDE, parentheses included. In more complex IF statements you need to type the parentheses and <> or ! yourself.

[Munair]

Istrue() can be completed by an IDE, parentheses included. In more complex IF statements you need to type the parentheses and <> or ! yourself.

It's a minor detail and almost any IDE supports highlighting of matching parentheses, which would happen either way. It's also a misuse of the TRUE/FALSE concept IMO (I use it exclusively for boolean flags). But if such a construct is preferable, I would suggest something similar to (not) IsNull().

[deltarho[1859]]

We are off topic now.

With PowerBASIC 'Print %True' returns 1 and 'Print %False' returns 0.

With FreeBASIC True and False are intrinsic constants with a size of 1. 'Print True/Print False' returns true/false. So, we cannot use them numerically in a statement as we can with PowerBASIC.

Consider these:

#Define IsFalse(e) ( Cint(Not CBool(e)) )
#Define IsTrue(e) ( Cint(CBool(e)) )

They are numeric and return either 0 or -1.

Code: Select all

Dim As Long x = 35
Print 10*IsTrue(x)
Sleep

returns -10.

Code: Select all

Dim As Long x = 0
Print 10*IsFalse(x)
Sleep

also returns -10.

Code: Select all

Dim As Long x = 21
If IsTrue(x) Then Print "OK"
Sleep

returns 'OK'.

[deltarho[1859]]

Any objections to these?:

#Define IsFalse(e) ( Cint<8>(Not CBool(e)) )
#Define IsTrue(e) ( Cint<8>(CBool(e)) )

[deltarho[1859]]

We need to be careful when using the above numerically and remember that True returns -1.

In C/C++ 'Not 0' returns 1 but in FreeBASIC 'Not 0' returns -1.

From Help: "Nevertheless the definition under the hood for a FB boolean remains an unsigned 1-bit integer, zero extended to fill larger integer types."

Ideally, then we should use these:

#Define IsFalse(e) ( -Cint<8>(Not CBool(e)) )
#Define IsTrue(e) ( -Cint<8>(CBool(e)) )

The boolean aspect is maintained, but numerically we now have either 0 or 1 returned. We don't have to be careful now.

If x is false, and we want it to be increased by 8 then we can use

x += 8*IsFalse(x)

Without the negation in the definitions, we would have to use

x -= 8*IsFalse(x)

Obviously, we can have more complex statements, but we now don't have the unreadable complication of remembering True returns -1.

I am going to settle on these last two definitions.

[Munair]

QuickBASIC also used -1 to define TRUE and I've seen programmers using it numerically in algorithms in an attempt to shorten their code. Personally, I think it's a bad habit.

[dodicat]

deltarho
You have to use positive to get the required size.

Code: Select all

#Define IsFalse(e) ( Cint<8>(Not CBool(e)) )
#Define IsTrue(e) (  -Cint<8>(CBool(e)) )


#print typeof(isfalse("a"="b"))
#print typeof(istrue("a"="b"))


 

Also (e) looks like it could be any old parameter but it can only be 1,-1, or 0, so it is confusing.
maybe sgn(e) to avoid an overload.
It can get messy quickly

Code: Select all

#Define IsFalse(e) (( Cint<8>(-(Cint<8>(Not CBool(sgn((e))))))) )
#Define IsTrue(e) (( Cint<8>(-(Cint<8>(CBool(sgn((e))))))) )


#print typeof(isfalse("a"="b"+"c"))
#print typeof(istrue("a"="b"+"c"))

print isfalse("a"="b"+"c")
print istrue("a"="b"+"c")
print istrue(10*("a"="a"))
sleep


  

[deltarho[1859]]

QuickBASIC also used -1 to define TRUE...

We also lost the consistency of BYTE type when the negation was introduced, necessitating using Cint twice.

So, I have gone back a step and removed the negation.

dodicat's 'sgn(e)' for 'e' to avoid 'Overflow in constant conversion' warning has been added.

This gets us to:

#Define IsFalse(e) ( Cint<8>(Not CBool(sgn(e))) )
#Define IsTrue(e) ( Cint<8>(CBool(sgn(e))) )

with false as 0 and true as -1.

So, with numerical use, we need to remember that True returns -1.

Thanks, guys.

[deltarho[1859]]

Using sgn(e) is throwing up its issue.

Code: Select all

Dim As Boolean a,b
a = False
b = Brue
Print IsTrue( a and b )
Sleep

I am now getting 'Invalid data types, found ')' in 'print istrue( a and b)'.

In fact I get it with: Print Sgn( a and b )

The reason, I reckon, is because 'a and b' is not a number but an intrinsic constant. In other words, the compiler cannot cope with Sgn(True).

Having said that, Sgn("a" = "a") works.

Anyway, I am dropping Sgn(e) – we don't need it having dropped the negation.

What about this 'Overflow in constant conversion' issue?

We get it with:

Code: Select all

Print IsTrue(10*("a"="a"))

That '10' is the problem as with CBool(10*("a"="a"))

In fact, we get this warning with CBool(10).

The manual has an example: CBool(1) which is OK.

I think we have a bug.

So I am now back to:

Code: Select all

#Define IsFalse(e) ( Cint<8>(Not CBool(e)) )
#Define IsTrue(e) ( Cint<8>(CBool(e)) )

with false as 0 and true as -1 and with numerical use, we need to remember that True returns -1.

Ignore the overflow warning – we seem to be getting the correct answers.