Why is this code now broken in v6.12?

[Randy Walker]

use sizeof(integer)

Tried it and got Line 2: syntax error:

Code: Select all

a.i = 42
Debug SizeOf(a.i)

[Randy Walker]

See the different sizes:

Code: Select all

Debug SizeOf(Integer)
Debug SizeOf(Long)
Debug SizeOf(Word)
Debug SizeOf(Byte)

And last but Not least:
A PureBasic pointer variable should be ALWAYS a Integer like:

Code: Select all

myPointer.i

Oh welll. That's quite a different story. I thought i had to put the variable itself in to replace the word "integer".
Silly me.

[Paul]

use sizeof(integer)

Tried it and got Line 2: syntax error:

Code: Select all

a.i = 42
Debug SizeOf(a.i)

If you formatted like this you would get the result of 8 when compiled as 64bit or 4 as 32bit

Code: Select all

a.i=42
Debug SizeOf(a)

[Randy Walker]

If you formatted like this you would get the result of 8 when compiled as 64bit or 4 as 32bit

Code: Select all

a.i=42
Debug SizeOf(a)

Indeed you are correct. Can't specify integer variable inside the SizeOf function. Who would of guessed?

[Quin]

If you formatted like this you would get the result of 8 when compiled as 64bit or 4 as 32bit

Code: Select all

a.i=42
Debug SizeOf(a)

Indeed you are correct. Can't specify integer variable inside the SizeOf function. Who would of guessed?

This is completely expected, you should only put the type of your variables like that once, when you first declare them. The only thing that goes against this is the $ to indicate string variables, that's required should you try to use it. .s isn't, though.
This makes sense when you think about it, because if you know anything about C, you know this makes no sense:

Code: Select all

int a = 42;
DEBUG(sizeof(int a));

[Randy Walker]

This makes sense when you think about it, because if you know anything about C, you know this makes no sense:

Code: Select all

int a = 42;
DEBUG(sizeof(int a));

I know nothing about C except it is unreadable and useless to me.
{ATTENTION NEW pureBasic USERS] DO NOT TRY to use PureBasic until you are proficient in C programming!!!!!

[PBJim]

Indeed you are correct. Can't specify integer variable inside the SizeOf function. Who would of guessed?

This is completely expected, you should only put the type of your variables like that once, when you first declare them. The only thing that goes against this is the $ to indicate string variables, that's required should you try to use it. .s isn't, though.
This makes sense when you think about it, because if you know anything about C, you know this makes no sense:

Code: Select all

int a = 42;
DEBUG(sizeof(int a));

Personally I wouldn't really agree with that — while C may be of interest from the point of view of comparison, this is not the C language.

... you should only put the type of your variables like that once, when you first declare them.

This is a matter of programming style. There's an argument for appending the variable type throughout code, to avoid ambiguity. We do it in some parts of our code as we have a lot of mixed types in a complex application and eventually others are going to maintain that code. I wouldn't want another programmer to have to keep referring back to all the var. definitions, or mistake a type.

[Randy Walker]

... you should only put the type of your variables like that once, when you first declare them.

This is a matter of programming style. There's an argument for appending the variable type throughout code, to avoid ambiguity. We do it in some parts of our code as we have a lot of mixed types in a complex application and eventually others are going to maintain that code. I wouldn't want another programmer to have to keep referring back to all the var. definitions, or mistake a type.

Seems PBJim an I think alike on this matter. With 28000+ lines of code -- It's ridiculous not to add clarity throughout the code. One reason I'm still stuck on the JaPBe -- it has a very useful popup list when you [F1] on any variable, array (even procedure calls) giving line numbers of each occurrence in the file. I'll take all the clarity I can get.

[PBJim]

This is a matter of programming style. There's an argument for appending the variable type throughout code, to avoid ambiguity. We do it in some parts of our code as we have a lot of mixed types in a complex application and eventually others are going to maintain that code. I wouldn't want another programmer to have to keep referring back to all the var. definitions, or mistake a type.

Seems PBJim an I think alike on this matter. With 28000+ lines of code -- It's ridiculous not to add clarity throughout the code. One reason I'm still stuck on the JaPBe -- it has a very useful popup list when you [F1] on any variable, array (even procedure calls) giving line numbers of each occurrence in the file. I'll take all the clarity I can get.

That's it, when we're maintaining code over time, mistakes are easily made. The thing with commercial software is that programmers' time is expensive and clarity saves time. Here's an example where the code looks perfectly fine at first glance, until you realise it ain't.

Code: Select all

Define chr.a
Define value.i

; -----------------------------------------------------------------------------
;  Much further down in the long forgotten annals of historic code, where
;  we haven't realised that chr is an unsigned type.
; -----------------------------------------------------------------------------

value = -10

;
;

chr = value

Debug chr
; If only we'd used chr.a   :-( 

[Randy Walker]

But this code actually do not delete or insert an element. The array size keeps constant, it just moves the data.
If you insert an element in a full array, this code shifts out the last element.

Here is my version for DeleteArrayElement and InsertArrayElement, written as a macro, to allow multiple atomic data types for the arrays. However, such code (as well as the linked code) are not working with string-arrays or structured arrays.

Code: Select all

Macro DeleteArrayElement(ArrayName, Index)
	If Index >= 0 And Index <= ArraySize(ArrayName())
		If Index < ArraySize(ArrayName())
			MoveMemory(@ArrayName(Index+1), @ArrayName(Index), @ArrayName(ArraySize(ArrayName()))-@ArrayName(Index))
		EndIf
		If ArraySize(ArrayName()) > 0
			ReDim ArrayName(ArraySize(ArrayName())-1)
		Else
			FreeArray(ArrayName())
		EndIf
	EndIf
EndMacro

Macro InsertArrayElement(ArrayName, Index, Value)
	If Index >= 0
		If ArraySize(ArrayName()) = -1
			Dim ArrayName(Bool(Index>=0)*(Index))  ; Bool(Index>=0) is needed here to prevent compiler error for index < 0
		ElseIf Index > ArraySize(ArrayName())
			ReDim ArrayName(Bool(Index>=0)*(Index))  ; Bool(Index>=0) is needed here to prevent compiler error for index < 0
		Else
			ReDim ArrayName(ArraySize(ArrayName())+1)
		EndIf
		If Index < ArraySize(ArrayName())
			MoveMemory(@ArrayName(Index), @ArrayName(Index+1), @ArrayName(ArraySize(ArrayName()))-@ArrayName(Index))
		EndIf
		ArrayName(Index) = Value
	EndIf
EndMacro

Macro ViewArray(ArrayName)
	For I = 0 To ArraySize(ArrayName())
		Debug "[" + I + "] = " + ArrayName(I)
	Next
EndMacro

;- Example

Define Dim MyArray.f(3)

MyArray(0) = 1.0
MyArray(1) = 2.0
MyArray(2) = 3.0
MyArray(3) = 4.0

ViewArray(MyArray)

Debug "Delete:"
DeleteArrayElement(MyArray, 2)
ViewArray(MyArray)

Debug "Insert:"
InsertArrayElement(MyArray, 0, 3.25)
ViewArray(MyArray)

Debug "Insert:"
InsertArrayElement(MyArray, 7, 100)
ViewArray(MyArray)

This is one glorious piece of work! THANKS STARGÅTE !!!!!!