[5.10] Native types can't be used with pointers

[grabiller]

Hi,

here is why I consider this new 'addition' as a total failure.

I'm importing a lot of C libraries and each time, I like to keep track of libraries types (C typedefs,etc..) to be consistent with the libraries documentations and samples. For instance, with the DevIL library (I'm using it just to import OpenEXR images):

Until now I had (just an excerpt with the first 5.10 encountered error):

Code: Select all

Macro ILubyte
  a
EndMacro
Macro ILuint
  l
EndMacro
PrototypeC.ILint fReadProc( *buf, a.ILuint, b.ILuint, hnd.ILHANDLE )
ImportC "DevIL.lib"
ilCompressDXT.i ( *data_.ILubyte, Width.ILuint, Height.ILuint, Depth.ILuint, DXTCFormat.ILenum, *DXTCSize.ILuint ) ; returns ILubyte*
EndImport

This was working beautifully until now. But with v5.10 I now get the "Native types can't be used with pointers" on the ilCompressDXT function declaration.

If I change:

Code: Select all

Macro ILuint
  Long
EndMacro

I now get a "Syntax Error" on the fReadProc Prototype declaration, but ilCompressDXT will work. If I want to keep the original Macro, I then have to change the ilCompressDXT method to:

Code: Select all

ilCompressDXT.i ( *data_.Ascii, Width.ILuint, Height.ILuint, Depth.ILuint, DXTCFormat.ILenum, *DXTCSize.Long ) ; returns ILubyte*

Great, I totaly lost the connection with the library types.

I have to either use PB long syntax types that can't be used on non-pointer variables, or I have to create 2 different Macros (ex: pILuint) or I have to embed the type in the pointer name..

Elegance of the previous PB versions is broken, this new 'addition' leads to messy code, and all this, just for 'confused beginners' ?!

To me this is a bug, not a technical one, but a design one.

ps: Aside from that I love everything else in the 5.10+ version. That's why I'm even more angry about this.

[Fred]

Not a bug, i already explained why we changed that, i won't repeat myself.

[grabiller]

Not a bug, i already explained why we changed that, i won't repeat myself.

Then why v.Long, v.Ascii, etc.. give syntax error on non-pointer variables ?

Where is 'consistency' here ?

[DarkDragon]

Not a bug, i already explained why we changed that, i won't repeat myself.

Then why v.Long, v.Ascii, etc.. give syntax error on non-pointer variables ?

Where is 'consistency' here ?

With *v.Long you can access the value through *v\l, but with *v.l you can't, as "Long" is a structure and "l" is a native type. So why should you ever specify a native type to a pointer? It makes no sense at all, as *v.a, *v.l, *v would make no differences.

[EDIT]
Sorry Fred you're too slow today .

[Fred]

'Long' is a Structure defined like that:

Code: Select all

Structure Long
  l.l
EndStructure

You can't assign a structure to a procedure parameter (if it's not a pointer indeed), so yes, that's consistent.

[grabiller]

Ok,

I understand the technical consistency, but:

- Where is it specified in the documentation that Long, Ascii, etc.. are such structures (I may have missed this one) ?

@DarkDragon
- It makes perfect sense to have *v.a, *v.l because even if it makes no difference internally and we all know it's 4bytes on x32 and 8bytes on x64, it shows you which Peek* function to use on the pointer. Or else, how do you keep track if you have to use PeekL or PeekA, tell me ? (aside embedding the pointed type in the pointer name ?)

- Consistency should also be regarded on a syntax level:
Having v.Long and *v.Long is as consistent as having v.l and *v.l
For the user (us, developers), this is very consistent.
But I understand 'Long' is a structure, 'l' is a native type, consistency here is internal, it's just convenient for the parser/compiler, not for the user reading the code.

Anyway, I wont argue anymore. To me, something elegant has just been broken in PB with this v5.10, whatever the internals reasons, and in practice I'll have to 'rethink' all my libraries declarations. Fortunately there is UndefineMacro now.. but still lot of precious time wasted on this.

[DarkDragon]

I understand the technical consistency, but:

- Where is it specified in the documentation that Long, Ascii, etc.. are such structures (I may have missed this one) ?

They are defined inside resources, and the structures defined in resources can be viewed inside the structure viewer.

@DarkDragon
- It makes perfect sense to have *v.a, *v.l because even if it makes no difference internally and we all know it's 4bytes on x32 and 8bytes on x64, it shows you which Peek* function to use on the pointer. Or else, how do you keep track if you have to use PeekL or PeekA, tell me ? (aside embedding the pointed type in the pointer name ?)

How about using the structures? Anyway using Peek isn't appropriate in many situations and any line of code which uses Peek could also be written without.

- Consistency should also be regarded on a syntax level:
Having v.Long and *v.Long is as consistent as having v.l and *v.l

No, because if there's no technical difference between accessing the values behind *v.l and *v without ".l" it will imply the pointer datatype would be long then (just like a near and a far pointer).

[idle]

you can still use an empty structure to define a pointer type to aid code documentation

Code: Select all

Structure puInt  : EndStructure 
Structure puByte : EndStructure 

Macro uByte
  a
EndMacro

Macro uInt
  l
EndMacro

PrototypeC.uInt fReadProc( *buf.puByte, a.uInt, b.uInt, hnd.I)

Procedure ReadProc(*buf.puByte,a.uByte,b.uInt, hnd.I )
   Debug *buf 
   Debug a 
   Debug b 
   Debug hnd 
EndProcedure 

Define pRead.fReadProc  
pRead = @ReadProc() 

pRead(123,1,2,3) 

Debug SizeOf(Long)
Debug SizeOf(puInt)    ;<---------beware, won't report a sizeof  

[PMV]

Hi,

here is why I consider this new 'addition' as a total failure.

Just a side note. This is not an addition ... it is just a syntax-check
that should be implemented right at the beginning.
You are just mousetrapped. A star is just another way to
define the type of a variable. It is another way as the other types
are defined with a dot. Why should it be possible to define one
variable with two different types? If you want to commend your code to track
library types ... use commends as you would do in any other language.


MFG PMV

[grabiller]

Hi,

here is why I consider this new 'addition' as a total failure.

Just a side note. This is not an addition ... it is just a syntax-check
that should be implemented right at the beginning.
You are just mousetrapped. A star is just another way to
define the type of a variable. It is another way as the other types
are defined with a dot. Why should it be possible to define one
variable with two different types? If you want to commend your code to track
library types ... use commends as you would do in any other language.


MFG PMV

In 'any other language' such as C, there is a way to declare the type of the data a pointer is pointing at:

Code: Select all

char* buf;
/* or */
char *buf

We don't use 'comments'.

[grabiller]

I understand the technical consistency, but:

- Where is it specified in the documentation that Long, Ascii, etc.. are such structures (I may have missed this one) ?

They are defined inside resources, and the structures defined in resources can be viewed inside the structure viewer.

@DarkDragon
- It makes perfect sense to have *v.a, *v.l because even if it makes no difference internally and we all know it's 4bytes on x32 and 8bytes on x64, it shows you which Peek* function to use on the pointer. Or else, how do you keep track if you have to use PeekL or PeekA, tell me ? (aside embedding the pointed type in the pointer name ?)

How about using the structures? Anyway using Peek isn't appropriate in many situations and any line of code which uses Peek could also be written without.

- Consistency should also be regarded on a syntax level:
Having v.Long and *v.Long is as consistent as having v.l and *v.l

No, because if there's no technical difference between accessing the values behind *v.l and *v without ".l" it will imply the pointer datatype would be long then (just like a near and a far pointer).

I remember Fred talking about confused beginners.

Well, if you consider my PureBasic time compared to yours, I'm the beginner right ?

Then when I first saw *v.l I knew right away it meant a pointer pointing at a data of type Long. Not a 'Long pointer'. So your assumption *v.l imply the pointer datatype would be long is wrong, especially for someone used to, say, C.

Regarding the Ascii,Long,.. structures defined inside resources, it isn't clear from the documentation itself. And from a beginner point of view, I'm not sure having to use *v.Long is less confusing than *v.l.

I wasn't confused at all with *v.l at first and knew right away it was a pointer pointing at a data of type Long and it was very simple and intuitive, and consistent, syntactically, with v.l. Like in C with char *v, and char v.

[luis]

Just for the sake of discussion ...

In 'any other language' such as C, there is a way to declare the type of the data a pointer is pointing at:

Code: Select all

char* buf;
/* or */
char *buf

And there is a reason for that. The compiler knows from the definition "buf" will point to a "char" and it will use that information.

It will issue warnings if the use you will make of that pointed data it's not coherent with a char, and you'll have to cast the pointer if you want to go against it.

Moreover it will use the information for pointer arithmetic, moving the pointer as required in memory based on the data type you defined.

But PB ?

PB never checked to what a pointer point, and it has never had complex pointer arithmetic like C (we have to use sizeof to correctly increment a pointer based on the pointed data for example, and we can't even increment a pointer in an expression and use the resulting address to access some data, we have to alter the pointer value).

So the previous syntax had at best a 'cosmetic' value, but nothing more. No checkings from the compiler, no different code generated based on the type. You can just use a properly named variable to carry the same 'cosmetic' information.
And was confusing if you knew you had predefined structure for the basic data types.

On the other end I agree with you the equivalence between a .i var and a .Integer structured var should have been stressed in the manual.
As I said before, part of the PB documentation is really "programming by example" and that part of knowledge is only available in the forum.
Slowly something find its place in the manual, but it's not rare months or years pass for that to happen, if ever.

But this nonsense needed to be fixed.

[PMV]

I wasn't confused at all with *v.l at first and knew right away it was a pointer pointing at a data of type Long and it was very simple and intuitive, and consistent, syntactically, with v.l. Like in C with char *v, and char v.

And that's the trap ... because it isn't.
The compiler never knows what is behind a pointer.
A pointer with a structure just helps by accessing
the memory behind the pointer ... it will not prevent
you by miss-using it in any way.
... short version of luis post

MFG PMV

[Psychophanta]

Requested for years about this needed fixation for consistence and readability, and finally here it is.

However, there is still the buggy feature:
Native types really STILL CAN BE USED with pointers.
Look & see:

Code: Select all

Structure so
  *locationinmem.b; <- ??
EndStructure
f.so\locationinmem=78

Debug f\locationinmem

[luis]

Native types really STILL CAN BE USED with pointers.

Yep, since you really can't define a structure named like a native type, this should be ideally forbidden.
You better report it but don't know if Fred will fixed it, since this is probably due to the fact PB doesn't check by design for an existing definition of a structure when one is referenced using pointers inside a structure.