Disallow use of '$' when it isn't part of a variable name

[Demivec]

If there is no speed improvement or bug fix involved in this pursuit, then it is only harmful to legacy code and a larger source of confusion. I cannot see the logic as presented.

A pointer is either structured (to make dereferencing possible) or it isn't. The syntax has previously allowed specifying a type for a pointer which was ignored (except in the case of .s or $). The bug, or quirk rather, is that it was allowed to be done. Sometimes it caused problems and sometimes not. The problems were due to confusion many times.

I'm glad you were able to make use of a quirk to help remind you of what you were using the pointers for. That is a weak reason to keep it though.

Here another way to help your memory using the same number of characters:

Code: Select all

; 4 - include type in pointer's name
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata_f,    *ydata_f,    *res1_d,     *res2_d)
; or conversely
PrototypeC.l somedllfunction(handle.l, nPts.i, *f_xdata,    *f_ydata,    *d_res1,     *d_res2

Prototypes don't care what the names of the variables are, only their types or structures. The function itself will determine if a pointer is going to be structured (and what that structure will be). It would also seem that since the functions that you are prototyping are using the pointers simply as addresses, they also don't care because they aren't even dereferencing them.

[skywalk]

Thanks for the explanation Demivec.
However, I strongly disagree this is a weak argument
A. I and others would have to change lots of code.
B. I and others would have to change variable names to retain some form of self-documentation.
C. No bugs are eliminated or speed improved by this change.

What burdens are there to changing the syntax for all users?
I know it has been done for some gadget commands and maybe a few default settings in higher functions.

[Danilo]

I think the mapping idea where '*ptr.l' would compile to '*ptr.Long' would be a mistake. 'l' is not the name of that structure and there are enough ways to get confused in coding without introducing another one.

The mapping of basic data types to the structure types would be internal for pointers within the compiler.

The end user does not need to know how it is done internally. He/She would just read in the documentation
how to use pointers to structures and how to use pointers to PB's basic data types.

We could just use basic data types with pointers:

Code: Select all

Procedure DisplayMemory( *mem, size )
    Protected *p.b = *mem
    
    For i = 1 To size
        Debug Hex(*p\b ,#PB_Byte)
        *p + 1
    Next
EndProcedure

Procedure DisplayChars( string$ )
    Protected *p.c = @string$
    
    While *p\c
        Debug Chr(*p\c)
        *p + SizeOf(*p\c)
    Wend
EndProcedure

quad.q = $8899AABBCCDDEEFF

DisplayMemory( @quad, 8 )

Debug "----"

DisplayChars("Hello!")

I would call it an feature to use basic data types with pointers. It is not possible now, it would be possible after the change.
No need to use the structures (Integer, Byte, Character) as workaround anymore, you could just use it with basic data types.

• It would not hurt somebody (you are not forced to use that feature)
• It is easy to read and understand: *p.b is a pointer to PB's data type .b
• It is intuitive: many people who use pointers for the first time wonder why basic data types do not work with pointers, because everybody tried it intuitively at first
• It is less to type and PureBasic syntax: *p.a, *p.b, *p.c, *p.d instead *p.Ascii, *p.Byte, *p.Character, *p.Double
• It is fully backward compatible

[TI-994A]

It would make more sense to disallow the use of '$' in these instances to declare the type when it is not directly associated with a variable name.

Perhaps not as important for declaration purposes, but I have a sentimental attachment to the $ symbol in string variable names; wouldn't be BASIC without it.

It could be turned into a feature, just map the PureBasic basic types to the corresponding structures internally:
*p.a -> *p.Ascii
*p.c -> *p.Character
*p.i -> *p.Integer

This is definitely a good idea, bringing more flexibility to PureBasic syntax. And it may be better than updating the language to disallow such declarations altogether, making them syntactically wrong, and forcing massive re-writes. However, if they were mapped to their corresponding structures, would it pose any problems to existing code that uses such pointers purely as pointers?

[Fred]

No, it would be confusing. '.a', '.b' are no structure, so it would be wierd to be able to access a field from it. If you want access a data, just use the structure '.Ascii', '.Byte' etc.

[skywalk]

Fred, as it stands now, we can already do both. Have any bugs been reported because of this?
Really frustrating to learn of a syntax change that doesn't solve a bug.

[Regenduft]

Not to be taken too seriously!
By the way, this is my first code using regular expressions.

Code: Select all

EnableExplicit

Define Source$        = GetClipboardText()
Define RegExpPattern$ = "\*\w{1,}\.[abcdfilqsuwABCDFILQSUW]\b"
Define DotReplace${1} = "_" ; "*somepointer.s" to "*somepointer_s"
Define RegExpFlags    = #PB_RegularExpression_AnyNewLine

Define i, Hits, a$, b$
If Source$
  If CreateRegularExpression(0, RegExpPattern$, RegExpFlags)
    Dim Results$(0)
    Hits = ExtractRegularExpression(0, Source$, Results$())
    FreeRegularExpression(0)
    If Hits
      Hits - 1
      If ArraySize(Results$()) = Hits
        For i = 0 To Hits
          a$ = Results$(i)
          b$ = Left(Results$(i),Len(Results$(i))-2) + DotReplace$ + Right(Results$(i),1)
          If StringByteLength(a$) = StringByteLength(b$)
            ReplaceString(Source$, a$, b$, #PB_String_InPlace | #PB_String_NoCase)
          Else
            Source$ = ReplaceString(Source$, a$, b$, #PB_String_NoCase)
          EndIf
        Next
        SetClipboardText(Source$)
        MessageRequester("Source changed", "Changes have been sucessfully done to source code. New source code has been copied to clipboard.")
      Else
        MessageRequester("RegExp Extraction error", "Hits - 1 <> ArraySize(Results$())")
      EndIf
    Else
      MessageRequester("No changes needed", "No changes needed")
    EndIf
  Else
    MessageRequester("Regular expression error", RegularExpressionError())
  EndIf
Else
  MessageRequester("Empty clipboard", "Empty clipboard")
EndIf

[chris319]

If you don't like "$", don't use it.