|Anonymous | Login | Signup for a new account||2017-07-21 19:53 BST|
|My View | View Issues | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006351||Runner||[All Projects] Functions||Public||2012-08-31 14:54||2017-05-18 08:52|
|Assigned To||Mike Dailly|
|Priority||Low||Severity||C - General||Reproducibility||100%|
|Platform||Windows, HTML5||OS||Windows 7 x64 Professional||OS Version||7|
|Summary||0006351: string concatenation with non-string values is inconsistent across platforms|
|Description||I've only been able to test this on HTML5 and Windows, but if I do something like the following:|
number = 7;
my_string = "This part is a string" + number;
It works if I build an HTML5 game. It throws an error at runtime if I build to Windows.
The fix for windows of course is to use the string() function to cast the number variable to a string:
my_string = "This part is a string" + string(number);
The reason I consider this a bug is that the code should compile and execute as close to identically as possible regardless of build target.
In my opinion, the ideal fix for this would be for the Windows runner to automatically cast numeric values to string when the + operator is used in a statement where one of the arguments is a string. This would make the identical running code work on Windows or HTML5.
I have not been able to test the behavior on any other platforms.
|Steps To Reproduce||write a GML statement that adds a number to a string. Build to Windows and run, it errors at run time. Build to HTML5 and it works.|
|2.x Runtime Version|
|2.x Runtime Version Verified In|
|Attached Files||StringConcatenation.gmz [^] (903,902 bytes) 2014-06-16 16:35|
Neil Wicker (Updater)
This still occurs in 1.3.1354
Interestingly, the program runs on Windows YYC but the string is not concatenated. Which means the behavior on Windows, Windows YYC and HTML5 are all different. I've uploaded a sample program which allows the problem to be seen.
Mike Dailly (Manager)
The only way to change this to make things consistent with Native (and not the other way around) is to add checking code above which would slow everything down.
Since everyone (pretty much) uses the Native version, that is considered the correct version, and if it works there should work in HTML5 - language issues aside.
So this is not something we'll look to "fix" as it would hit HTML5 performance.
|Copyright © 2000 - 2017 MantisBT Team|