The new MQL4 syntax - page 3

I have a question about the variable types, int, uint, char, short ushort etc. The new compiler gives warnings about possible data loss due to type conversion, so is it best practice to;

a) use whichever one best fits the requirements of the variable or,

b) avoid converting between types and therefore use int for everything. (well, everything that wont need a floating point)

If you need an unsigned long an int won't cut it . . . use the correct type and explicit type conversion. IMO

by explicit type conversion you mean to do the conversion before any calculations between different types ?

Agree.

See here : https://www.mql5.com/en/docs/basis/types/casting

Good article thanks angevoyageur I will read that properly when I get home from work.

No, I mean you can convert an ulong to an int like this . . .

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  

OK yes that is what I thought you meant.

Except I wasnt really asking about ulong. I would rarely if ever need to work with such large values as could not be accomodated by a 32 bit integer. I dont even know how to say the number a 64 bit integer can hold lol...

I probably should have been more specific, I didnt have the time this morning to write out my question propertly but now I am home I will.

In old mql4 we used integer for everything. We would write for(int i=0; i<100; i++) We dont need negative values, and we dont need a bigger value than 100 so we could use a uchar for that. Does that mean that is what we should do ?

When I look at other programmers code, a lot of them seem to use 32 bit integer types across the board. Is there a valid reason for that ? What do they know that I have yet to find out ? Does using the smallest footprint variable types throughout a program create a headache of typecasting issues for no reason other than a slightly smaller file size ? Or does it save a lot of RAM ? Is it safe to assume that as long as the value of one type can be accomodated by another type it is ok to do it ? Does typecasting between different types use a lot more CPU than to use the same type?

Update: I have been looking this up I read this reply to a similar question on stackoverflow.com

"Performance-wise, an int is faster in almost all cases. The CPU is designed to work efficiently with 32-bit values.

Shorter values are complicated to deal with. To read a single byte, say, the CPU has to read the 32-bit block that contains it, and then mask out the upper 24 bits.

To write a byte, it has to read the destination 32-bit block, overwrite the lower 8 bits with the desired byte value, and write the entire 32-bit block back again.

Space-wise, of course, you save a few bytes by using smaller datatypes. So if you're building a table with a few million rows, then shorter datatypes may be worth considering. (And the same might be good reason why you should use smaller datatypes in your database)

And correctness-wise, an int doesn't overflow easily. What if you think your value is going to fit within a byte, and then at some point in the future some harmless-looking change to the code means larger values get stored into it?

Those are some of the reasons why int should be your default datatype for all integral data. Only use byte if you actually want to store machine bytes. Only use shorts if you're dealing with a file format or protocol or similar that actually specifies 16-bit integer values. If you're just dealing with integers in general, make them ints."

uchar - Unsigned Character, why would you use this for a loop ? it doesn't make sense to me . . . use an int. You will be working with ulongs, that is what a new datetime is . . . and when you typecast without thinking about it in future you will get warned . . . deal with the warning or ignore it. Don't just hope for the best though, do as you are doing now, learn and understand

The stuff you posted from stackoverflow makes sense to me, I think it is good advice.

Between different sizes uses more CPU, not a lot more. Just different instructions like the mentioned 32 bit fetch, isolate, operate, place, write, when modifying char in a structure. Just like multiply by 0.5 uses slightly less CPU than divide by 2.0

Saving 16 bits per array element doesn't make sense on GB machines, I did that when I implemented application, database, GUI (vt100) in 8 KB (sic.) Going to 64 bits per (for everything,) won't make sense until 128 bit platforms are common place.

Signed vs unsigned there is no difference. It's just an assignment, no bits are changed. The difference is the code that uses the variable. E.g A[index] does Address(a) + index * sizeof(a[0]) where the plus is a signed or unsigned addition.

For coding clarity, I'd use uint for indexing arrays since A[-1] make no sense but then counting down is problematic FOR(uint iA=n; iA >= 0; iA--){} iA>=0 is always true.

Use int (or uint) unless you must for other reasons.