Questions from a "dummy" - page 14

New comment
 

Here's another thing to think about. Do it!// Report the results. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

I'm honestly baffled, guys. You're just messing around on a level playing field. Totally flat.

I just wanted to apologize and interject myself into this "serious" conversation. But while I was out getting cigarettes, I was beaten to it.

And it's not like we're "dummies," is it? And this "boo-boo-boo" was just a bunch of boo-boos.

In the CExpert class, I'll correct it to ulong.

 
Renat:

You are wrong.

Yes, I forgot about the type conversion.

 
uncleVic:

And it's not "dummies", is it?

I'm a dummie in many respects. So I don't understand how functions intended to return long will return ULONG_MAX-1. The pitfalls of superficial handling of integer types are written about almost in the Handbook itself. sergeev has correctly grasped the reason for the question: order control. If I set request.magic to type ulong, then I expect that the HistoryDealGetInteger(), PositionGetInteger() and OrderGetInteger() functions will also return ulong type. Without any explicit-implicit type conversions.

However, ifhis examples explain that conversions of long<->ulong type do not cause loss of values (unlike double -> int, for example), then the further thought process becomes clear.

uncleVic:

And such a "boo-boo-boo" was created on an empty space.

Actually the "Dummie's Questions" thread was chosen to get explanations, not admonishments.

 
Yedelkin:

I'm a dummy for a lot of things. So I don't understand how functions meant to return long will return ULONG_MAX-1. The pitfalls of superficial handling of integer types are written about almost in the Handbook itself. sergeev has correctly grasped the reason for the question: order control. If I set request.magic to type ulong, then I expect that the HistoryDealGetInteger(), PositionGetInteger() and OrderGetInteger() functions will also return ulong type. Without any explicit-implicit type conversions.

However, ifhis examples explain that conversions of long<->ulong type do not cause loss of values (unlike, for example, double -> int), then the further thought process becomes clear.

Actually, the "Dummie's Questions" thread was chosen for the purpose of elucidation, not reprimand.

Offended? Sorry, I couldn't help it.
 
uncleVic:
Are you offended? Sorry, I couldn't help it.
No, I'm not. I've had my share of internet battles. I just always try to steer the discussion in a constructive direction, so to speak.
 
sergeev:

Actually it is not 64 but only 63 bits (i.e. an incomplete 8 bytes). 8 bytes would be if the whole long range was used.

But unfortunately...

On the one hand, magic ulong is passed into MqlTradeRequest structure. It means that only positive values can be set.

On theother hand, the PositionGetInteger/OrderGetIntegerfunctions return the long type . It means that half of the ulong range is cut off.

All in all, we have 63 bits instead of the 64 bits described above. Actually, it is not so much bad as great inconvenience to the principles of order checking.

It would be much more convenient to use the same system as in MT4 - allow magicians with a sign. Since many trading systems are based on a simple principle using the very symbol of a magician. Since it is much easier to divide one system into two and filter out your orders using the usual MathAbs( OrderMagicNumber() ) function.

all 64. As a matter of fact. Do not cling to signed or unsigned type. This is for compiler to make sure that arithmetic operations are correct (and there is a right bit shift to logical or arithmetic, depending on signed values).

No information is lost during transfer (assignment) and signless-unsigned castings of data of the same size. Try bouncing ULONG_MAX back and forth. Try long-ulong assignment and back. Try structure copying.

The best thing is to make sure for yourself. Then the question will be solved once and for all.

 
MetaDriver:

Here's another thing to think about. Do it!// Report the results. ;)

Done! Replace line 14 in the code with L.l = 4548887299649496524.

It follows from description of MqlTradeRequest structure that magic is of ulong type, i.e. it can be assigned values greater than LONG_MAX constant value. However, functions of the ...GetInteger() functions are designed to work with long type, so magic values will be implicitly cast to long type by these functions. But as there is one-to-one correspondence between variables of long and ulong types, when comparing magic value with the result returned by functions of ...GetInteger() functions , we can safely use an explicit type conversion (for example: magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Thanks for repeatedly showing examples.

 

stringo:

No information is lost anywhere during data transfer (assignment) and sign-unsigned castings of data of the same size. Try bouncing ULONG_MAX back and forth. Try long-ulong assignment and back. Try structure copying. Convince yourself and do not spread myths.

I've already tried it and it returns the necessary result when forcing the type (well, maybe one more "dancing with diamonds" will have to be done additionally). But it's not so important).

uncleVic:

I will change the CExpert class to ulong.

I think it's a good idea, those who use negative values in magic will have to forcibly specify what they must return/set.

It would also be very nice if the documentation indicated not just long or ulong, but both of those types (e.g. so "long / ulong").

 
stringo:

No information is lost anywhere during data transfer (assignment), or during character-unsigned castingsof data of the same size.

An additional question: is there any elegant way to preserve information when transferring double -> long?
1...789101112131415161718192021...277
New comment
Reason: