Features of the mql5 language, subtleties and tricks - page 160

New comment
 
Alexey Viktorov:

NULL is such an ambiguity that you have to deal with it carefully.

void OnStart()
{
  uchar Bytes[];

  Print(StringToCharArray(NULL, Bytes)); // 0
  Print(StringToCharArray("", Bytes));   // 1
}

Once again, an input string cannot be NULL (forced by ""). The other strings can.

 
fxsaber:

Once again, the input string cannot be NULL (forced by ""). The other strings can.

input is almost synonymous with const, const must be initialised
 
fxsaber:

Once again, the input string cannot be NULL (forced by ""). The other strings can.

Again, why do you think there shouldn't be such a conversion? My knowledge and experience are not enough to explain all this. So stick to your opinion. I hope the developers will not go along and change it.

 
Alexey Viktorov:

Again, why do you think there should be no such conversion?

I know exactly why this conversion happens. We're talking about a feature here, not a bug.

 
Maxim Kuznetsov:
input is almost synonymous with const, const must be initialized

NULL is initialisation. The example purposely shows a non-input string.

 
fxsaber:
It is a good idea to generate a warning at compile time.

Yes, this behavior is probably just "foolproof".
Apparently, because an input variable must be initialized,= NULL is artificially equated with ="" when the variable already occupies at least one byte in memory.

In MQL5 the entries:

string str=NULL;
string str;

Are absolutely identical. No memory is allocated for the variable. Anyway, I haven't found any differences.
In java, for instance, such records are slightly different, despite the fact that no memory is allocated for the variable in both cases, too. The first variant (String str = null;) will be considered initialized, although no memory is allocated for the variable and the variable can be printed as empty. In the second case (String str;) when you try to print the variable, an error of uninitialized variable will be generated.
I.e. MQL5 is more tolerant in this regard.
Which is better, I don't even know.

 
Nikolai Semko:

Apparently, because an input variable must be initialized, the= NULL is artificially equated to ="", when the variable already occupies at least one byte in memory.

NULL is not an initialization, it's a value. You may assign NULL to any non-const string variable in the middle of code. And it will be equal to NULL.

Input is not equal to NULL because at startup an invisible set-file is created. From this file variable values are "parsed" into inputs. Parsing cannot output NULL anyway and therefore it places an empty string there.

Only input-string has this behaviour. For const-string and others, it's fine, of course.
 
fxsaber:

NULL is not an initialisation, but a value. You can assign any non-const string variable to NULL in the middle of the code. And it will be equal to NULL.

Input is not equal to NULL because at startup an invisible set-file is created. From this file variable values are "parsed" into inputs. Parsing will not output NULL at all and therefore will place an empty string there.

Well, that's what I mean. I agree.
The only thing is that there's no point in assigning a NULL value to a string at the variable declaration stage:

string str1 = NULL;
string str2;
PRINT((str1==NULL));   // true
PRINT((str2==NULL));   // true

It only makes sense to do this to zero the already initialized variable in memory.

 
Nikolai Semko:

Well, that's what I'm saying. I agree.
The only thing is that there's no point in assigning a NULL value to a string at the variable declaration stage:

only makes sense to do this to null a variable in memory.

#define  DEFAULT_VALUE NULL

string Str = DEFAULT_VALUE;

if (Str == DEFAULT_VALUE)
  ...

Here NULL initialization makes sense.

 
fxsaber:

NULL initialisation makes sense here.

yes

1...153154155156157158159160161162163164165166167...275
New comment