Errors, bugs, questions - page 2566
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
With this casting, there is no data loss. Either it is 0 or it is not 0.
Another case is when double -> any integer type (up to and including int32)
You're playing with warnings a bit too much in my opinion, there is a lack of consistency in your judgement
You've gone a bit overboard with the warnings in my opinion, there is a lack of consistency in judgement
Agreed
Here too,there is no data loss in this sense(either 0 or not 0)
but there is a warning. A uniform approach was expected
Result of an attempt to access a property of a class instance from a static function of the same class:
The compiler was silent before this.Does not initialise an empty string with a terminal null.
Result
Expected
Note in the help for the StringInit function
In fact, there is no distribution.
I.e. allocation in this way, ten spaces
is not the same as.
The help text marked in red does not correspond to logical behavior.
You're overdoing it with the warnings in my opinion, not enough consistency in judgement
Warnings don't work on boolean operations, now I accidentally noticed a typo in my code, so I reproduced it:
Does not initialise an empty string with a terminal null.
Result
Expected
Note in the help for the StringInit function
In fact there is no distribution.
I.e. allocation in this way, ten spaces
is not the same as.
And it doesn't seem to match the logic of the behaviour, highlighted in red in the help text.
You missed the StringBufferLen function - it returns the size of the allocated buffer. StringLen returns the string length, i.e. up to the terminal character, respectively, if it is at the very beginning - length 0. Buffer != string.
You have overlooked the StringBufferLen function - it returns the size of the allocated buffer. StringLen returns the length of the string, i.e. up to the terminal character, respectively, if it is at the very beginning - length 0. Buffer != string.
Otherwise it doesn't know itself.
You have overlooked the StringBufferLen function - it returns the size of the allocated buffer.
StringLen returns the length of the string, i.e. up to the terminal character, respectively, if it is at the very beginning - length 0. Buffer != string.
This is clear, we're talking about initializing a string with terminal zeros.
Why not fill stringInit(str, 10, 0); with ten terminal zeroes ? And return the actual string length.
If you want to initialize an empty string, without filling it! for example with 100 characters,
then either 100 spaces as str = " many pokes at the keyboard ", or initialize rubbish StringInit(str, 100, 65)
I don't understand why I need to initialize with rubbish, there's already enough of it ))
It's understandable, we're talking about initializing the string with terminal zeros.
Why not fill in StringInit(str, 10, 0); with ten terminal zeros ? And return the actual string length.
If you want to initialize an empty string, without filling it! for example with 100 characters,
then either 100 spaces as str = " many pokes at the keyboard ", or initialize rubbish StringInit(str, 100, 65)
I don't understand why I need to initialize it with rubbish, there's already enough of it ))
What makes you think it's not filled in? It's just that the length in the µl string is not stored, it's recognised by the terminal zero.
no?
And if you need zeros, there is a String class somewhere in the bowels of µl std.
What makes you think it's not filled in? It's just that the length in the µl string is not stored, it's recognised by the terminal zero.
isn't it?
And if you need zeros, there is a String class somewhere in the bowels of the µl std.
Nah... It returns zero that way too. And third parameter ushort, requires integer character code.
If I initialize as str = " "; and then pass data from dll, everything is ok.
But if I initialize it as StringInit(str, 10, 0) then data won't arrive. That's because the code does not allocate memory for string with needed size.
If I had code for space, probably would have worked, but that I have not found such code in different tables.
We need to allocate memory for number of future characters which then will go to already initialized empty string.
But rubbish to initialize the string, not kommelpho.
StringInit(str, 100, 0); should be filled with terminal nulls and return the length 100.