Typing question - page 7

New comment
 
Dmitry Fedoseev:

What a problem people have))) I'll live a long life!

By the way, writingd=array[5].to_double() is much easier thand=(double)array[5] Just a point to press. But we are not looking for easy ways.

Why write d=(double)array[5]? That's the idea - not to bother with this trivia. Here is a piece of real code:

MYCRTMFLT(i+1, chart[MYSEG(MYSCNT-i).start].time,
               chart[MYSEG(MYSCNT-i).start].price,
               chart[MYSEG(MYSCNT-i).top].time,
               chart[MYSEG(MYSCNT-i).top].price, 
               chart[MYSEG(MYSCNT-i).top].price>chart[MYSEG(MYSCNT-i).start].price?
                 MYCLRUP : MYCLRDOWN, STYLE_SOLID, true);

chart[index] returns struct {price; time} And why do I keep adding .time/.price to it, when in most cases you can understand it from the context? Yes, sometimes you will need to prompt (as in the penultimate line), but in most cases life will be easier and there will be less writing.

 
Dmitry Fedoseev:

What a problem people have))) I'll live a long life!

By the way, writingd=array[5].to_double() is much easier thand=(double)array[5] Just a dot to press. But we're not looking for easy ways.

Yes, of course, one must necessarily write d=(double)array[5] when one already knows at compilation time that d cannot be anything but double. The mice cried and begged but kept on biting the cactus...

 
Ilya Malev:

Yes, of course, it is obligatory to write d=(double)array[5], when it is already known during compilation that d cannot be anything but double... the mice cried and begged, but kept on gnawing the cactus...

In C++ they overload Oregatog<=> for d, gnaw and don't cry ;-)

PS/ and in view of associativity and priorities use << operator as a more suitable one
 
pavlick_:

Why write d=(double)array[5]? That's the idea - not to bother with this trivia. Here is a real code fragment:

chart[index] returns struct {price; time}. And why do I keep adding .time/.price to it, when in most cases we can understand it from the context? Yes, sometimes you will need to prompt (as in the penultimate line), but in most cases life will be easier and there will be less writing.

The programmer intends to overload (double) so thatarray[5] returns number double instead of some object. Isn't it so?

Where is this context in the given example where we can understand it? Is it MYCRTMFLT parameter type? This is an overload on the type of the return value.

 
fxsaber:

If you really want to, you can do this

etc.

 _W(Color)[2] = (uchar)230;              // Записали по смещению 2 значение (uchar)230.
  PRINT(Color)                           // Убедились, что Color теперь C'241,248,230'
Isn't it the same asPrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)); ?

I'm afraid that I'll break my brain if I continue studying your codes.

I mean that everything in your methods is admirable (no joke) except abundance of capital letters with underscores and context resolution operations:)

I think, that if it (operation of a context resolution) will be allowed to overload, you together with your libraries will go to astral :lol:

 
Maxim Kuznetsov:

PS/ and, due to associativity and priorities, use the << operator as a more appropriate one

It occurred to me too, frankly. Overload << with >> and don't suffer. But it doesn't remove the desirability of allowing overloading of T()

 
Dmitry Fedoseev:

As I understand it, they are going to overload it here, so thatarray[5] would return not some object, but number double. Isn't it so?

Where in this example is this context that can be understood? Is it MYCRTMFLT parameter type? This is an overload on the type of returned value.

I don't see a problem at all:

double d;
d = chart[i];  // call operator double

void f(datetime t);
f(chart[i]);  // call operator datetime

The macro will either end with some identifier or function call and the compiler will understand what is expected from it. And if it doesn't (compile error with swearing on ambiguity), then you can always help it: chart[i].price

 
Ilya Malev:

Yes, of course, one must necessarily write d=(double)array[5], when one knows already during compilation that d cannot be anything but double... the mice cried and cried, but kept on gnawing on the cactus...

Besides d there is also something else with the name array.

It's not bad at all when the compiler warns about assigning inappropriate types. We should show the compiler that those who wrote this code take full responsibility for the result so that they won't complain later about the absence of compiler-generated warnings.

 
pavlick_:

I don't see a problem at all:

...

Neither do I.
 
Dmitry Fedoseev:

It's not bad at all that the compiler warns about assigning inappropriate types. We need to show the compiler that those who wrote this take full responsibility for the result, so that they don't complain later about absence of compiler's warnings.

Only not in that case when he himself has defined operator double(){...} method for this assignment, obviously not so that he could later write (double) after a variable of type double or get compiler's warnings.

In general, the conversation is obviously going in a circle, let's hope that type overloading will be allowed eventually, I personally wouldn't mind if to enable it I'd put a tick somewhere in options and confirm that "I agree to be fully responsible for the result".

12345678910
New comment