[Implemented] Suggestion to avoid a PB incoherence

[Psychophanta]

Code: Select all

*var2.b=AllocateMemory(100); *var2 is a pointer (i.e. in a 32 bit architecture *var2 is a long -32 bit- ), which is suposed to point to a byte variable.
*var3.s=AllocateMemory(100); *var3 is a pointer (i.e. in a 32 bit architecture *var3 is a long -32 bit- ), which is suposed to point to a string variable.

As you can see I can not define a pointer to a string and assign it a pointer value

The idea to solve it might be to allow pointers to strings normally, but internally treat them as *var.c.
This would solve the incoherence and at the same time it would not touch anything in PB.



Another related point is:
At the PB manual is written:

assigning a type to a pointer (*Pointer.l , *Pointer.b …) makes no sense

The point to understand here is that there are no fields inside native types like .l or .b, so why would you make a pointer to such a type? Only structured types, user or native, make sense.

But well; It also makes sense for standard native types just for readability.

[Trond]

The string problem is a reported bug, pointer to string simply doesn't work all right in PB. (Fred said he's "looking".)

It also makes sense for standard native types just for readability.

Well, I think it looks horrible.

[Psychophanta]

It also makes sense for standard native types just for readability.

Well, I think it looks horrible.

Readability has nothing to do with beauty.

[Trond]

It also makes sense for standard native types just for readability.

Well, I think it looks horrible.

Readability has nothing to do with beauty.

If I look away in horror, I can't read it!

[Psychophanta]

Horrible or not, readability means in this case to know what is pointed by a pointer variable when reading a code.

[Trond]

In my opinion, if you can't access it, it doesn't matter what it is.

[Psychophanta]

In my opinion, if you can't access it, it doesn't matter what it is.

Can't access it???, ermh..., i think we are not talking about the same thing
Read above.
Why do you say can't access?

[Trond]

With *Pointer.b you can't access the byte, so it could be an elephant and I wouldn't care.

[Psychophanta]

With *Pointer.b you can't access the byte, so it could be an elephant and I wouldn't care.

I don't see the point, that's wrong.
The ususal way to access is PeekB(*Pointer.b).
Sorry but this discussion is void, or i miss something

[Trond]

If you need to access it, it's much faster to do *Byte.Byte\b than Peek(). The only reason for Peek() in that context is when you, for some strange reason declared a pointer to .b instead of .Byte.

It really doesn't make sense to use a slower method, when you have proper, faster method available.

[Kale]

An interesting thread:
http://www.purebasic.fr/english/viewtopic.php?t=22242

There is an inconsistency with strings in PB when dealing with pointers because of the way the strings are handled internally. Basically when you define a string like 'MyString.s' you are actually returned a pointer pointing to the string buffer. But it's all handled automagically without you knowing.

Have a search, there are lots of threads detailing this.

Plus (just for Trond) i have all this fully clarified in my book with a whole section dedicated to pointers and PB.

But well; It also makes sense for standard native types just for readability.

No it doesn't.

[Psychophanta]

There is an inconsistency with strings in PB when dealing with pointers because of the way the strings are handled internally.

Sorry, but i must warn this http://www.purebasic.fr/english/viewtopic.php?t=22709 is called bug, not simple inconsistence.
And surely it would be solved if every *whatever.s was converted to *whatever.c in compilation time (this is the reason of be of this thread -read first post- ).
About readability it is explained above.

[Trond]

And surely it would be solved if every *whatever.s was converted to *whatever.c in compilation time

Not really.

If everything was working correctly, these two would work the same:

Code: Select all

*String.s = "Test"
*Char.c = @"Test"

Of course, if you convert the *String.s to *String.c then it won't work the same any more.


Edit:

assigning a type to a pointer (*Pointer.l , *Pointer.b …) makes no sense

It makes sense for *String.s.

[Psychophanta]

@Trond, i don't know if you don't read or don't understand or what the hell... and sorry...

surely it would be solved if every *whatever.s was converted to *whatever.c in compilation time

That is probably the cleanest solution to the current problem of pointers to strings like *var.s or *var$.

Code: Select all

*String.s = "Test"

should not work and it would not work if that solution was performed in PB.

[GedB]

Psychophanta,

Given the code:

Code: Select all

*var3.s=AllocateMemory(100);

What should be returned by the following?

Code: Select all

len(*var3)

How would this be affected by Unicode and Ascii settings?