Inclusion of the Assert Macro found in the manual

[Kruno]

I know it takes a mere 5 seconds to copy/paste it from the manual, but surely this could be added into the library itself? It requires no maintenance, maybe naive of me to think this, but how could this innocent, and yet infinitely useful macro, cause maintenance issues?

I modified it by making "Expression" into "Not Expression", and then by adding "RaiseError", and it is cross platform compatible as I am raising an error that works on Windows, Linux, and Mac.

Code: Select all

Macro DoubleQuote
    "
EndMacro

Macro Assert(Expression)
    CompilerIf #PB_Compiler_Debugger  ; Only enable assert in debug mode
        If Not Expression
            Debug "Assert (Line " + #PB_Compiler_Line + "): " + DoubleQuote#Expression#DoubleQuote
            RaiseError(#PB_OnError_Breakpoint)
        EndIf
    CompilerEndIf
EndMacro

I wrote my own little testing library, and so I will not ask for a unit testing library. Unit tests for the win:

Code: Select all

CompilerIf #DEBUG_PROCESS
    IncludeFile "test.pb"
    RunTests()
CompilerEndIf

RunProgram()

[luis]

As you said you can paste it very easily, so I don't see the point.
If for some reason this wish will be granted, I just hope I can use UndefineMacro on it since I would like to keep calling my version of assert "ASSERT"
BTW: welcome.

[Little John]

I would like to keep calling my version of assert "ASSERT"

... which can be found here.

[rsts]

I would like to keep calling my version of assert "ASSERT"

... which can be found here.

And I like luis' version also

[freak]

I wrote my own little testing library, and so I will not ask for a unit testing library.

There is already a framework for unit testing. Have a look in SDK\PureUnit in your PureBasic folder.

[Kruno]

Holy mother of...

There are a lot of interesting things in the PureBasic folder, and why did it not occur to me to look in there just to peruse?

There is a library maker, and I did not know the PB team used NASM. I really would like to know how the process of how this compiler works. The code it generates is fast, and the compile times are instant, and has tail call optimisation. Prehaps I should start another new thread for this discussion?

OMG I found PureUnit.
DUDE! You have got to make this stuff available through the IDE.

I would also love to learn to make custom gadgets.

[luis]

I did not know the PB team used NASM

I think NASM on Mac and FASM on Windows and Linux.

The code it generates is fast, and the compile times are instant

It's true enough, partly because the language is simple to parse and to translate to asm, more then C for example (and C is *relatively* simple).
Also the compiler is single pass, so that helps to make it quick.

and has tail call optimisation.

Are you sure ?
AFAIK tail optimization means the frame stack of the calling procedure is used when invoking another procedure from it, if that proc is the last one called and there is no more code in the body of the calling procedure after that last call.
And instead of using a CALL you use a JUMP to enter the body of the "called" procedure and use its own RET to exit from the caller.
I never saw that in the code generated by PB, but I could be wrong (obviously).
Do you have an example of where you saw it ? I tried some code that should be ripe for that optimization and I didn't see any trace of it.

[Kruno]

I did not know the PB team used NASM

I think NASM on Mac and FASM on Windows and Linux.

The code it generates is fast, and the compile times are instant

It's true enough, partly because the language is simple to parse and to translate to asm, more then C for example (and C is *relatively* simple).
Also the compiler is single pass, so that helps to make it quick.

and has tail call optimisation.

Are you sure ?
AFAIK tail optimization means the frame stack of the calling procedure is used when invoking another procedure from it, if that proc is the last one called and there is no more code in the body of the calling procedure after that last call.
And instead of using a CALL you use a JUMP to enter the body of the "called" procedure and use its own RET to exit from the caller.
I never saw that in the code generated by PB, but I could be wrong (obviously).
Do you have an example of where you saw it ? I tried some code that should be ripe for that optimization and I didn't see any trace of it.

I think I may be wrong. It just so happens that I never ran out of stack space when doing long recursive computations, and so I assumed it was doing TCO. Unfortunately I have spent a lot of time using interpreted languages and assumed because I didn't run out of stack that the compiler was doing TCO.