Можно ли присобачить оператор присваивания к структуре? - C/C++. Прикладные вопросы

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>ULONG KeQueryTimeIncrement ();
ЕМ>ULONG KeQueryInterruptTime ();

ЕМ>LARGE_INTEGER TickCount, TicksPerSecond;

ЕМ>TicksPerSecond = 10000000 / KeQueryTimeIncrement ();
ЕМ>TickCount = KeQueryInterruptTime ();

Может, как вариант, просто ввести внешнюю ф-цию?:

inline void set( LARGE_INTEGER& integer, UINT64 const value ) {
    integer.QuadPart = static_cast<LONGLONG>( value );
}

...
set( TicksPerSecond, 10000000 / KeQueryTimeIncrement () );
set( TickCount, KeQueryInterruptTime () );

Я бы не сказал что это будет радикально отличаться от присваивания.

В винде есть структура LARGE_INTEGER, представляющая 64-разрядные значения. Она неудобна тем, что для 64-разрядных операций нужно специально указывать поле .QuadPart, и тем, что это поле знаковое — нельзя присвоить ему беззнаковое значение без преобразования. Не смертельно, но получается уж больно громоздко.

А оператор присваивания непременно должен быть членом класса.

Если порождать класс от _LARGE_INTEGER, то придется вводить преобразования к дочернему классу — одни громоздкие построения заменяются на другие.

Может, есть способ присобачить оператор присваивания минимальными усилиями?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

ЕМ>Может, есть способ присобачить оператор присваивания минимальными усилиями?

А вы присваиваете один LARGE_INTEGER другому или как? Просто, зачем вам вообще переопределять оператор?

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>А вы присваиваете один LARGE_INTEGER другому или как? Просто, зачем вам вообще переопределять оператор?

Я LARGE_INTEGER использую только через поле QuadPart — простое 64-разрядное значение. Поэтому хотелось бы иметь оператор, позволяющий просто присваивать значение переменной типа LARGE_INTEGER, не залезая в поле, а также присваивать беззнаковые значения с автоматическим преобразованием. А глобально отключать предупреждения на несоответствие знаковости/беззнаковости типа не хочу — они нужны.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

L_L>>А вы присваиваете один LARGE_INTEGER другому или как? Просто, зачем вам вообще переопределять оператор?

ЕМ>Я LARGE_INTEGER использую только через поле QuadPart — простое 64-разрядное значение. Поэтому хотелось бы иметь оператор, позволяющий просто присваивать значение переменной типа LARGE_INTEGER, не залезая в поле, а также присваивать беззнаковые значения с автоматическим преобразованием. А глобально отключать предупреждения на несоответствие знаковости/беззнаковости типа не хочу — они нужны.

а можешь пример кода привести, что хотелось бы получить в итоге?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>>А вы присваиваете один LARGE_INTEGER другому или как? Просто, зачем вам вообще переопределять оператор?

ЕМ>Я LARGE_INTEGER использую только через поле QuadPart — простое 64-разрядное значение. Поэтому хотелось бы иметь оператор, позволяющий просто присваивать значение переменной типа LARGE_INTEGER, не залезая в поле, а также присваивать беззнаковые значения с автоматическим преобразованием. А глобально отключать предупреждения на несоответствие знаковости/беззнаковости типа не хочу — они нужны.

а обязательно использовать именно LARGE_INTEGER? можно взять тот же boost::uint64_t, например

Здравствуйте, night beast, Вы писали:

NB>а можешь пример кода привести, что хотелось бы получить в итоге?

Хм, здесь разве можно что-то понять превратно?

ULONG KeQueryTimeIncrement ();
ULONG KeQueryInterruptTime ();

LARGE_INTEGER TickCount, TicksPerSecond;

TicksPerSecond = 10000000 / KeQueryTimeIncrement ();
TickCount = KeQueryInterruptTime ();

Функции KeXxx, понятное дело, не мои — виндовые, и структуры нужно тоже передать винде. Для внутренних нужд я пользуюсь UINT64, здесь никаких проблем нет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, XuMuK, Вы писали:

XMK>а обязательно использовать именно LARGE_INTEGER? можно взять тот же boost::uint64_t, например

Для своих целей я использую обычный UINT64, вполне хватает. Но в ряде случаев и винда дает значения в LARGE_INTEGER, и ей их нужно передавать так же.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

NB>>а можешь пример кода привести, что хотелось бы получить в итоге?

ЕМ>Хм, здесь разве можно что-то понять превратно?

ЕМ>

ЕМ>ULONG KeQueryTimeIncrement ();
ЕМ>ULONG KeQueryInterruptTime ();

ЕМ>LARGE_INTEGER TickCount, TicksPerSecond;

ЕМ>TicksPerSecond = 10000000 / KeQueryTimeIncrement ();
ЕМ>TickCount = KeQueryInterruptTime ();
ЕМ>

возьмем за начальное приближение такой код:

struct integer {
   LARGE_INTEGER value;

   integer () {}
   integer ( LARGE_INTEGER src ) : value( src ) {}
   integer ( LONGLONG src ) { value.QuadPart = src; }

   operator LARGE_INTEGER () const { return value; }
};

не подходит?

Здравствуйте, night beast, Вы писали:

NB>возьмем за начальное приближение такой код:

Так понятно, что через промежуточные классы/переменные все решается элементарно. Но уж если браться — хочется сделать элегантно, а тут придется либо вводить переменные типа integer, либо явные преобразования.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

NB>>возьмем за начальное приближение такой код:

ЕМ>Так понятно, что через промежуточные классы/переменные все решается элементарно. Но уж если браться — хочется сделать элегантно, а тут придется либо вводить переменные типа integer, либо явные преобразования.

да.
можешь, конечно, переопределить какой нибудь operator << но operator = никак получится.

Здравствуйте, Alexey F, Вы писали:

AF>Может, как вариант, просто ввести внешнюю ф-цию?:

В большом проекте функция set не годится — ее нужно будет как-то длинно и понятно обозвать, и из текста не будет очевиден смысл действия. Хочется именно присобачить оператор присваивания прямо к существующему классу LARGE_INTEGER. И на кой стандартом это запрещено?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, night beast, Вы писали:

NB>можешь, конечно, переопределить какой нибудь operator << но operator = никак получится.

А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В большом проекте функция set не годится — ее нужно будет как-то длинно и понятно обозвать, и из текста не будет очевиден смысл действия. Хочется именно присобачить оператор присваивания прямо к существующему классу LARGE_INTEGER. И на кой стандартом это запрещено?
set, assign — в принципе, не такие и плохие имена для свободной ф-ции или семейства свободных ф-ций, устанавливающих значение. Может, подошли бы setUnsigned или assignUnsigned, т.к. нет точного соответствия между типом QuadPart (LONGLONG) и вторым их аргументом (UINT64) (с другой стороны, перегруженные ф-ции для того и делаются, чтобы избавиться от таких имён).
Можно оставить явный operator= в коде, но модифицировав левую часть присваивания:

ref( TicksPerSecond ) = 10000000 / KeQueryTimeIncrement ();
ref( TickCount ) = KeQueryInterruptTime ();

, где ref:

struct LargeIntegerRef {
    LargeIntegerRef( LARGE_INTEGER& ref )
        : ref_( ref ) {}

    LargeIntegerRef& operator=( UINT64 const value ) {
        ref_.QuadPart = static_cast<LONGLONG>( value );
        return *this;
    }

private:
    LARGE_INTEGER& ref_;
};

inline LargeIntegerRef ref( LARGE_INTEGER& ref ) {
    return ref;
}

Здравствуйте, Евгений Музыченко, Вы писали:

NB>>можешь, конечно, переопределить какой нибудь operator << но operator = никак получится.

ЕМ>А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

не знаю. возможно сочли не целесообразным.

Здравствуйте, night beast, Вы писали:

ЕМ>>А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

NB>не знаю. возможно сочли не целесообразным.

Когда считают нецелесообразным — просто не принимают специальных мер. А здесь из множества всех глобальных бинарных операций присваивания специально выделены и запрещены.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

Чтоб ты не переопределил присваивание для интов и других встроенных типов. То же самое касается и ->, [] и что там еще было?
Может еще потому, что operator= генерится компилятором, если не реализуешь свой. Может каким-то образом это облегчает задачу компиляторописателям.

Здравствуйте, andrey.desman, Вы писали:

AD>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

AD>Чтоб ты не переопределил присваивание для интов и других встроенных типов. То же самое касается и ->, [] и что там еще было?
AD>Может еще потому, что operator= генерится компилятором, если не реализуешь свой. Может каким-то образом это облегчает задачу компиляторописателям.

И еще сигнатуру int зафиксировать, чтоб не получались финты вроде этого:

struct test
{
test() {}
test(int i) {}
};

test operator = (test a, test b);

void foo()
{
   test a;

   1 = a;
}

Или такие:

struct test
{
    void set(const test &r) { *this = r; }
}

test& operator = (test &l, const test& r){}

void foo()
{
test a, b;
a.set(b); // какой оператор вызовется?
}

Здравствуйте, andrey.desman, Вы писали:

AD>Чтоб ты не переопределил присваивание для интов и других встроенных типов.

Про встроенные типы речи вообще не шло. Я именно про структуры/классы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, gegMOPO4, Вы писали:

MOP>Потому, что оператор присваивания неявно генерируется компилятором, если он не определён.

И что с того? Какие соображения мешают его переопределить?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А оператор присваивания непременно должен быть членом класса.

Если порождать класс от _LARGE_INTEGER, то придется вводить преобразования к дочернему классу — одни громоздкие построения заменяются на другие.

Я сделал структуру-обертку над FILETIME, и никаких преобразований в коде не прибавилось. При вызове API не требуется кастов к старому типу, а новый код сам по себе использует только новый тип. В общем, ты преувеличиваешь проблему, делай обертку и не парься.

Здравствуйте, Кодёнок, Вы писали:

Кё>Я сделал структуру-обертку над FILETIME, и никаких преобразований в коде не прибавилось. При вызове API не требуется кастов к старому типу, а новый код сам по себе использует только новый тип. В общем, ты преувеличиваешь проблему, делай обертку и не парься.

Там проблема еще и в том, что нельзя класс-обертку отнаследовать от _LARGE_INTEGER, ибо он union. Но вроде после доработки напильником что-то получилось:

class LargeInteger {

  LARGE_INTEGER LI;

  public:

  LargeInteger (void) { LI.QuadPart = 0; }
  LargeInteger (LARGE_INTEGER const Src) { LI.QuadPart = Src.QuadPart; }
  LargeInteger (INT64 Src) { LI.QuadPart = Src; }
  LargeInteger (UINT64 Src) { LI.QuadPart = INT64 (Src); }
  LargeInteger (ULONG Src) { LI.QuadPart = INT64 (Src); }

  operator INT64 (void) const { return LI.QuadPart; }
  operator UINT64 (void) const { return UINT64 (LI.QuadPart); }

  LARGE_INTEGER const * operator & (void) const { return &LI; }
  LARGE_INTEGER * operator & (void) { return &LI; }

  operator LARGE_INTEGER const & (void) const { return LI; }
  operator LARGE_INTEGER & (void) { return LI; }

  LARGE_INTEGER const & operator = (LARGE_INTEGER const &Src) {
    LI = Src; return LI;
  }

  LARGE_INTEGER const & operator = (ULONG Src) {
    LI.QuadPart = INT64 (Src); return LI;
  }

};

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Там проблема еще и в том, что нельзя класс-обертку отнаследовать от _LARGE_INTEGER, ибо он union. Но вроде после доработки напильником что-то получилось:

ЕМ>

ЕМ>class LargeInteger {

ЕМ>  LARGE_INTEGER const & operator = (LARGE_INTEGER const &Src) {
ЕМ>    LI = Src; return LI;
ЕМ>  }

ЕМ>  LARGE_INTEGER const & operator = (ULONG Src) {
ЕМ>    LI.QuadPart = INT64 (Src); return LI;
ЕМ>  }
ЕМ>};
ЕМ>

а эти два зачем? кстати, вариант с функцией ref, что Alexey F предлагал не понравился?

Здравствуйте, night beast, Вы писали:

NB>а эти два зачем?

Друг другу присваивать, чтоб уж до кучи.

NB>кстати, вариант с функцией ref, что Alexey F предлагал не понравился?

Если уж что-то свое городить — то изящно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

NB>>а эти два зачем?

ЕМ>Друг другу присваивать, чтоб уж до кучи.

по идее без них должно работать (дефаултавый). лишнее конструирование компилятор может соптимизировать.

Здравствуйте, night beast, Вы писали:

NB>по идее без них должно работать (дефаултавый). лишнее конструирование компилятор может соптимизировать.

Ну да, с однотипным присваиванием я погорячился, а для интегральных-то типов без спецоператора не обойтись, как он догадается, что с ними делать?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

NB>>по идее без них должно работать (дефаултавый). лишнее конструирование компилятор может соптимизировать.

ЕМ>Ну да, с однотипным присваиванием я погорячился, а для интегральных-то типов без спецоператора не обойтись, как он догадается, что с ними делать?

создаст временную LargeInteger(конструкторы то не explicit) и передаст в оператор копирования.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, night beast, Вы писали:

NB>>можешь, конечно, переопределить какой нибудь operator << но operator = никак получится.

ЕМ>А почему, кстати? Я плохо разбираюсь в тонкостях парадигмы C++, поэтому очевидной причины для такого запрета не улавливаю.

Дальше пошла масса сторонних обсуждений, но этот вопрос вполне резонен.

Поскольку для каждого класса есть предопределенное копирующее присваивание, программист может рассчитывать на него, если не видит в интерфейсе класса перегрузки operator=.

Представим, что разрешено перегружать присваивание свободной операторной функцией. Тогда ее появление где-то в массе совсем не имеющих отношения к определению класса включений могло бы разительно изменить семантику кода исходного модуля. Это не есть хорошо, и это запрещено простой оговоркой о нестатическом члене класса.

Дополнительно — гарантируется, что слева от = всегда будет объект данного класса (потенциально — lvalue). Что и требуется от столь фундаментальной вещи, как присваивание.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В винде есть структура LARGE_INTEGER, представляющая 64-разрядные значения. Она неудобна тем, что для 64-разрядных операций нужно специально указывать поле .QuadPart, и тем, что это поле знаковое — нельзя присвоить ему беззнаковое значение без преобразования. Не смертельно, но получается уж больно громоздко.

ЕМ>А оператор присваивания непременно должен быть членом класса.

Если порождать класс от _LARGE_INTEGER, то придется вводить преобразования к дочернему классу — одни громоздкие построения заменяются на другие.

ЕМ>Может, есть способ присобачить оператор присваивания минимальными усилиями?

А может, просто кастить этот самый LARGE_INTEGER к __int64 когда нужно ? Один черт — 64 бита.

Здравствуйте, night beast, Вы писали:

NB>создаст временную LargeInteger(конструкторы то не explicit) и передаст в оператор копирования.

Поэкспериментировал. MS VС это делает как-то странно: конструктора, принимающего INT64, ему для этого недостаточно — требуется либо оператор присваивания, принимающий INT/UINT, либо конструктор, принимающий строго INT. Конструктору, принимающему UINT, передавать не желает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А может, просто кастить этот самый LARGE_INTEGER к __int64 когда нужно ? Один черт — 64 бита.

Тоже можно, но я всю эту возню затеял, чтобы избавиться от хронических кастингов туда-сюда.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А может, просто кастить этот самый LARGE_INTEGER к __int64 когда нужно ? Один черт — 64 бита.

ЕМ>Тоже можно, но я всю эту возню затеял, чтобы избавиться от хронических кастингов туда-сюда.

Можно макрос сделать и запись кастинга будет простой.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Можно макрос сделать и запись кастинга будет простой.

Это я изо всех сил пытаюсь делать "по-плюсовому", но постоянно приходится прибегать к костылям.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

ЕМ>Хочется именно присобачить оператор присваивания прямо к существующему классу LARGE_INTEGER.
Присваивание не получится.
Но можно оператор сдвига <<
Будешь писать так:

large_int << 5;

На мой вкус, вполне наглядно.

V>Присваивание не получится.
V>Но можно оператор сдвига <<
V>Будешь писать так:

V>large_int << 5;

V>На мой вкус, вполне наглядно.

Это пока не понадобится работа с битами. Потом кто-нибудь попытается сдвинуть 64-разрядное число на несколько разрядов и будет счастлив в отладчике.

	От:	Alexey F
	Дата:	08.04.11 11:33
	Оценка:	+1

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	08.04.11 10:22
Оценка:

	От:	Lorenzo_LAMAS
	Дата:	08.04.11 10:31
	Оценка:

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	08.04.11 10:37
Оценка:

	От:	night beast
	Дата:	08.04.11 10:41
	Оценка:

От:	K13	http://akvis.com
Дата:	16.04.11 07:23
Оценка:

	От:	gegMOPO4
	Дата:	09.04.11 20:37
	Оценка:

	От:	ArkM
	Дата:	13.04.11 18:39
	Оценка:

	От:	Vamp
	Дата:	15.04.11 20:47
	Оценка: