Вопрос по типизации - страница 7

Новый комментарий
 
Dmitry Fedoseev:

Ну и проблемы у людей))) Шоп я так жил!

Между прочим писать d=array[5].to_double() гораздо проще, чем d=(double)array[5] Только точку нажать. Но мы не ищем легкий путей...

Зачем писать d=(double)array[5]? В этом и идея - не заморачиваться по этим пустякам. Вот кусок реального кода:

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] возвращает struct {price; time}. И нафига я постоянно дописываю .time/.price, когда в большинстве случаев можно понять из контекста? Да, иногда надо будет подсказать (как в предпоследней строке), но в большинстве случаев жизнь станет проще, а писанины меньше.

 
Dmitry Fedoseev:

Ну и проблемы у людей))) Шоп я так жил!

Между прочим писать d=array[5].to_double() гораздо проще, чем d=(double)array[5] Только точку нажать. Но мы не ищем легкий путей...

да, конечно нужно непременно писать d=(double)array[5], когда известно уже при компиляции, что d ничем кроме double быть не может. мыши плакали, кололись, но продолжали грызть кактус...

 
Ilya Malev:

да, конечно нужно непременно писать d=(double)array[5], когда известно уже при компиляции, что d ничем кроме double быть не может. мыши плакали, кололись, но продолжали грызть кактус...

в С++ для таких целей перегружают operаtor<=> для d, грызут и не плачут ;-)

PS/ а в следствии ассоциативности и приоритетов вообще используют оператор << как более подходящий
 
pavlick_:

Зачем писать d=(double)array[5]? В этом и идея - не заморачеваться по этим пустякам. Вот кусок реального кода:

chart[index] возвращает struct {price; time}. И нафига я постоянно дописываю .time/.price, когда в большинстве случаев можно понять из контекста? Да, иногда надо будет подсказать (как в предпоследней строке), но в большинстве случаев жизнь станет проще, а писанины меньше.

Писать (double) - как понял, здесь его перегружать собираются, что бы array[5] возвращало  не какой-то там объект, а число double. Не так что ли?

Где в приведенном примере этот контекст, по которому можно понять? Наверно тип параметров MYCRTMFLT? Это перегрузка по типу возвращаемого значения. 

 
fxsaber:

Если очень хочется, то можно и так

и т.д.

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

  Боюсь, что продолжая изучать Ваши коды я сломаю себе мозг.

  То есть я хочу сказать, что в Ваших методах все восхитительно (без шуток) кроме обилия заглавных букв с подчеркиваниями и операций разрешения контекста :)

  Думаю, что если её (операцию разрешения контекста) разрешат перегружать, то Вы вместе со своими библиотеками уйдете в астрал :lol:

 
Maxim Kuznetsov:

PS/ а в следствии ассоциативности и приоритетов вообще используют оператор << как более подходящий

Это мне тоже пришло в голову, честно говоря. Перегрузить << с >> и не мучиться. Но это не отменяет желательности разрешения перегрузки T()

 
Dmitry Fedoseev:

Писать (double) как понял, здесь его перегружать собираются, что бы array[5] возвращало  не какой-то там объект, а число double. Не так что ли?

Где в приведенном примере этот контекст, по которому можно понять? Наверно тип параметров MYCRTMFLT? Это перегрузка по типу возвращаемого значения. 

Вообще проблемы не вижу:

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

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

макрос кончится в итоге или идентификатором каким-нибудь или вызовом функции, там из контекста компилятор и поймёт чего от него хотят. А если нет (ошибка компиляции с ругательством на неоднозначность), то всегда можно помочь ему: chart[i].price

 
Ilya Malev:

да, конечно нужно непременно писать d=(double)array[5], когда известно уже при компиляции, что d ничем кроме double быть не может. мыши плакали, кололись, но продолжали грызть кактус...

Кроме d еще есть нечто с именем array.

Очень даже не плохо, что компилятор предупреждает о присвоении не соответствующих типов. Надо показать компилятору, что написавшие сие берет на себя полную ответственность за результат, что бы потом не было жалоб на отсутствие предупреждений компилятора.

 
pavlick_:

Вообще проблемы не вижу:

...

Дык я тоже.
 
Dmitry Fedoseev:

Очень даже не плохо, что компилятор предупреждает о присвоении не соответствующих типов. Надо показать компилятору, что написавшие сие берет на себя полную ответственность за результат, что бы потом не было жалоб на отсутствие предупреждений компилятора.

Только не в том случае, когда он сам определил для этого присвоения метод operator double(){...} . явно не для того, чтобы потом писать (double) после переменной типа double, или получать предупреждения компилятора. 

В общем разговор явно уже идет по кругу, будем надеяться, что перегрузку типов все таки со временем разрешат, я лично буду не против если для её включения нужно будет поставить галку где-нибудь в настройках и подтвердить, что "я согласен нести полную ответственность за результат".

12345678910
Новый комментарий
Причина обращения: