http://www.purebasic.com
https://www.purebasic.fr/english/
I think "for a better compiler" is a pretty weak and generic supporting statement.mk-soft wrote:I think it's better to remove the autocasting strings for a better compiler.
Exactly so ~ I think we can all get carried away with unnecessary criticism at times.If you don't like it, don't use it and you're good
Not really. Autocast in some cases is used even if you are not asking for it, so it's not always a choice like the answer above seems to imply.IdeasVacuum wrote:Exactly soFred wrote:If you don't like it, don't use it and you're good
Code: Select all
Define a.String, *p.String
a\s = "world"
*p = @a
; explicit string concatenation
Debug "hello " + *p\s ; "hello world"
; the autocast hides the fact you forgot the \s
Debug "hello " + *p ; "hello 123456789"
It's generally the same thing, unless the number to be autocasted is a constant, in that case probably is trapped by the constant folding optimization and the target string (or at least the numeric part of it) is created at compile time.ts-soft wrote:I love the autocasting and i think, because it is a compiler function, it will be also quicker, than the call of str().
Code: Select all
a$ = "hello"
i = 123
b$ = a$ + i
b$ = a$ + Str(i)
b$ = a$ + 123 ; const
Code: Select all
; a$ = "hello"
MOV edx,_S1
LEA ecx,[v_a$]
CALL SYS_FastAllocateStringFree
; i = 123
MOV dword [v_i],123
;
; b$ = a$ + i
MOV edx,dword [v_a$]
PUSH dword [_PB_StringBasePosition]
CALL _SYS_CopyString@0
MOV edx,[_PB_StringBasePosition]
PUSH edx
PUSH edx
MOV eax,dword [v_i]
CDQ
PUSH edx
PUSH eax
CALL _PB_Str@12
POP eax
PUSH dword v_b$
CALL _SYS_AllocateString4@8
;
; b$ = a$ + Str(i)
MOV edx,dword [v_a$]
PUSH dword [_PB_StringBasePosition]
CALL _SYS_CopyString@0
MOV edx,[_PB_StringBasePosition]
PUSH edx
PUSH edx
MOV eax,dword [v_i]
CDQ
PUSH edx
PUSH eax
CALL _PB_Str@12
POP eax
PUSH dword v_b$
CALL _SYS_AllocateString4@8
;
; b$ = a$ + 123
MOV edx,dword [v_a$]
PUSH dword [_PB_StringBasePosition]
CALL _SYS_CopyString@0
MOV edx,_S2
CALL _SYS_CopyString@0
PUSH dword v_b$
CALL _SYS_AllocateString4@8
;
During the last weeks, there have been some discussions here where several people wrote about the problems with string autocasting. I don't have a complete list of all those discussions, but for example seeFred wrote:What is the problem exactly ?
This is not an argument. The behaviour of string autocasting is built into the current version of the PB compiler. A PureBasic programmer doesn't have the choice to switch it on or off. There actually was a feature request for allowing the user to enable/disable string autocasting (see second link above) -- which I personally do not support, because it probably only would increase the confusion.Fred wrote:If you don't like it, don't use it and you're good.
In the past few weeks, several people have expressed here that for them string autocasting causes more problems than it's worth.Fred wrote:It's a very common feature on all other major compilers and ease the string concatenation.
Yes, but those features don't have any ambiguities or inconsistencies. Apart from Luis' example, expressions in parenthesis are also not supported.Fred wrote:It's a very common feature on all other major compilers and ease the string concatenation.
Not true.Fred wrote:What is the problem exactly ? ..............It's a very common feature on all other major compilers and ease the string concatenation......
+1 -- I wish it were something (like EnableExplicit) we can turn off/on -- If I want a number to be with a string, I want to use str() (Yes, I know I can still do that) -- I want the compiler to complain if I try to misuse a numeric value and a string value -- because, the way I program, if I have used a numeric to concatenate with a string, it is not what I intended...BorisTheOld wrote:Please, please, please, allow this feature to be disabled.
If I am testing something out, I like the feature. If I have a tiny little program that serves a purpose, I might use it to save time typing.jassing wrote:+1 -- I wish it were something (like EnableExplicit) we can turn off/on -- If I want a number to be with a string, I want to use str() (Yes, I know I can still do that) -- I want the compiler to complain if I try to misuse a numeric value and a string value -- because, the way I program, if I have used a numeric to concatenate with a string, it is not what I intended...BorisTheOld wrote:Please, please, please, allow this feature to be disabled.
Whilst I absolutely have to agree that the above is a perfect example of PB auto-casting a value, I don't agree that you would necessarily forget the \s -you have just typed-in a pointer id which obviously would be a number 100 times out of 100, so if you wanted the string it points to, why would you forget the \s?Define a.String, *p.String
a\s = "world"
*p = @a
; explicit string concatenation
Debug "hello " + *p\s ; "hello world"
; the autocast hides the fact you forgot the \s
Debug "hello " + *p ; "hello 123456789"
That's a specious argument.IdeasVacuum wrote:Whilst I absolutely have to agree that the above is a perfect example of PB auto-casting a value, I don't agree that you would necessarily forget the \s -you have just typed-in a pointer id which obviously would be a number 100 times out of 100, so if you wanted the string it points to, why would you forget the \s?
Still, if others are adamant that they do forget these things and their forgetfulness is critical, then the choices are:
1) Roll-back to PB4.61 and remove new string auto-casting ~ example above would result in compile error;
2) Enhance string auto-casting ~ example above would trigger a warning that a pointer id is being cast to a string;
3) Provide a switch option/keyword similar to EnableExplicit;
Of the three, at the moment I think (2) is probably the best solution, even though I don't want to use auto-casting anyway. The potential problem with (3) is that it makes the underlying compiler code even more complex, which could lead to much more innocuous errors?