Harvester

Имеется класс виджета Qt: class GotoMenu : public QPushButton { Q_OBJECT public: GotoMenu(QWidget* parent = 0, bool handle_click = true); ~GotoMenu(); ... protected: void paintEvent(QPaintEvent* arg1); ... }; Согласно идеологии Qt при перерисовке виджета вызывается paintEvent(). Здесь вопросов нет. Теперь я создаю класс-наследник: class ComboElement : public GotoMenu { Q_OBJECT public: ComboElement(QWidget* parent = 0, const QString &var_combo = CommonData::_emptyString); ~ComboElement(); ... }; Правильно ли я понимаю, что если я не переопределю этом классе PaintEvent(), то при перерисовке этого виджета будет вызываться paintEvent() предка (GotoMenu)?

Вот Компэл предлагал в декабре:

Добрый день. Система CentOS 6, кросс-компиляция для powerpc. На сборочном сервере (с той же системой) все работает хорошо, но когда я пытаюсь повторить это на локальном компе, вылезает непонятная проблема. На финальном этапе сборки (перед генерацией образа) формируется список пакетов и вызывается команда ipkg: mkdir "$(IMAGEDIR)" PACKAGES='' ; for i in $(CONTENTSDIR); do \ PACKAGES="$$PACKAGES $(PACKAGEDIR)/$${i}_*.ipk"; \ done; \ $(IPKG) -o "$(IMAGEDIR)" install $$PACKAGES Проблема в том, что для 25-и пакетов команда выдает: Clearing state_want and state_flag for pkg=xxxxxx (arch_priority=0 flag=16 want=2) И только для 6-и: Installing xxxx(20015d-vard1) to root... А в конце: Nothing to be done An error ocurred, return value: 1. Collected errors: Cannot find package busybox. Check the spelling or perhaps run 'ipkg update' ... Все пакеты есть, ведь список формируется из реального содержимого папки. Права у всех пакетов одинаковые. Почему такое может происходить? Куда смотреть?

Я задал тот вопрос, который меня интересовал. В общем, я решил не использовать термин "дроссель", пока он явно не встретится в тексте.

Увы, если бы это было так, то и вопроса такого не возникло!

Простите, но Вы не совсем правы. Я ведь не спрашиваю, можно ли катушку индуктивности назвать просто индуктивностью. "сопротивление" vs "резистор", также как и "емкость" vs "конденсатор" - это противопоставление физической величины и компонента, работа которого основана на этой физической величине. Очевидно, что такая замена некорректна и условно допустима только в разговорной речи.

Заранее прошу прощения за, возможно, глупый вопрос. Правильно ли называть индуктивность в понижающем DC-DC преобразователе дросселем? С одной стороны этот элемент используется для запасания энергии, что является одним из применений дросселя, да и в русскоязычной литературе (тот же Семенов) часто употребляется термин "дроссель". С другой стороны, в английском языке дроссель это "chocke", а в текстах обычно явно говорится о катушке индуктивности:

Может я неправильно выразился. Но ведь здесь явно определяется элемент перечисления , а потом с этим же идентификатором написан define. Исходя из логики работы препроцессора все включения TFD_CLOEXEC будут заменены на идентичную строку, что в свою очередь будет обращением к элементу перечисления. Какое-то тройное "масло-масляное" получается :) Потому и вопрос возник - зачем? А Ваше предположение мне кажется неверным. Эти константы используются как битовые параметры, а не как директивы условной компиляции. timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK | TFD_CLOEXEC); И такое объединение enum + define встречается не в одном файле. Кстати, интересный вопрос - можно ли будет обратиться к элементу перечисления TFD_CLOEXEC, после того, как в коде появится #undef TFD_CLOEXEC? А в чем здесь красота? Дополнительные 5 строк кода, не несущие ни логической, ни пояснительной нагрузки.

Добрый день. Наткнулся вот на такую конструкцию в заголовочном файле (linux): /* Bits to be set in the FLAGS parameter of `timerfd_create'. */ enum { TFD_CLOEXEC = 02000000, #define TFD_CLOEXEC TFD_CLOEXEC TFD_NONBLOCK = 00004000 #define TFD_NONBLOCK TFD_NONBLOCK }; Кто-нибудь может предположить, зачем надо было переопределять элементы перечисления через идентичные define-ы?

Установит. А вот Ваш вариант PORTE &= ~(0<<PORTE5) - нет

Спасибо огромное. Век живи - век учись!

В том-то и дело, что не похоже. Просто подавление синфазного сигнала - это CMRR (Common Mode Rejection Ratio).

Добрый день. Встретилось в статье сокращение DCMR (Differential to Common Mode Rejection). Что оно означает вроде бы понятно, но при прямом переводе на русский какая-то ерунда получается. Может быть существует устоявшийся термин для этого коэффициента? Если что, статья про синфазные дроссели.

У меня на входе УЖЕ double. И далее в алгоритмах используется double. В этом случае результат не соответствует исходным требованиям, 50.11 => 50.2, а должно быть 50.0! :) Хм, попробую. Возможно этого будет достаточно :)

Все double