PureBasic Forums - English

Posted: **Sun Jan 13, 2013 3:30 pm**

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.

Posted: **Sun Jan 13, 2013 3:55 pm**

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

Posted: **Sun Jan 13, 2013 4:07 pm**

Fred wrote: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 ?

Posted: **Sun Jan 13, 2013 4:10 pm**

grabiller wrote:
Fred wrote: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

.

Posted: **Sun Jan 13, 2013 4:10 pm**

'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.

Posted: **Sun Jan 13, 2013 4:39 pm**

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.

Posted: **Sun Jan 13, 2013 5:19 pm**

grabiller wrote: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.

grabiller wrote:@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.

grabiller wrote:- 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).

Posted: **Sun Jan 13, 2013 5:27 pm**

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

Posted: **Sun Jan 13, 2013 6:17 pm**

grabiller wrote: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

Posted: **Sun Jan 13, 2013 9:12 pm**

PMV wrote:
grabiller wrote: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'.

Posted: **Sun Jan 13, 2013 9:25 pm**

DarkDragon wrote:
grabiller wrote: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.

grabiller wrote:@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.

grabiller wrote:- 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.

Posted: **Sun Jan 13, 2013 11:21 pm**

Just for the sake of discussion ...

grabiller wrote: 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.

Posted: **Mon Jan 14, 2013 12:05 am**

grabiller wrote: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

Posted: **Wed Jan 16, 2013 11:42 pm**

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

Posted: **Thu Jan 17, 2013 12:23 am**

Psychophanta wrote: 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.

PureBasic Forums - English

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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