Просмотр сообщений
|
Страниц: 1 2 [3] 4 5 6
|
31
|
Программирование / С/C++ / Re: Compile-time определение реверсивности итератора (reverse_iterator)
|
: Апрель 16, 2021, 11:04
|
Ага, оказывается "добавить дни" ф-ция есть, а я думал проблема в этом. и вместо QDate там шаред-поинтер на класс с членом, возвращающим QDate. И нужно именно "двигать", т.е. для выдвигаемых элементов должен вызываться деструктор, а вдвигаемые должны создаваться конструктором с новой датой.
Ну извлечь диапазон, впарить новые даты, потом найти место вставки (lower_bound), и вставить. Все банально (или я чего-то не знаю) Выдвигаемый элемент уничтожается (деструктор). Вдвигаемый создается конструктором с новой датой. Если же элемент остается в диапазоне (т.е. он просто сдвигается, но не выдвигается), то он остается нетронутым. [1 2 3] -> shift_left -> 1 (dtor) [2(untoched) 3(untoched) 4(ctor)]. Короче, элемент можно удалить, добавить, сдвинуть, но не модифицировать (нет интерфеса для модификации даты).
|
|
|
32
|
Программирование / С/C++ / Re: Compile-time определение реверсивности итератора (reverse_iterator)
|
: Апрель 15, 2021, 18:36
|
Итак, задача: есть диапазон дат (QDate), задаваемый парой итераторов [begin, end). Даты идут с шагом в 7-дней. Необходимо сдвинуть диапазон влево или вправо на любое заданное число элементов, при этом новые даты должны продолжать последовательность.
я так понимаю, сдвиг на N - это "прибавить N недель к каждой дате"? тогда (псевдокод): void shift(IteratorT begin, IteratorT end, int offset) { for (auto& it = begin; it != end; it++) { *it = (*it).addDays(offset * 7); } }
это имелось в виду? Блин, ну здорово!! На самом деле я неудачно упростил задачу, и вместо QDate там шаред-поинтер на класс с членом, возвращающим QDate. И нужно именно "двигать", т.е. для выдвигаемых элементов должен вызываться деструктор, а вдвигаемые должны создаваться конструктором с новой датой. Мое упущение. И мне не пришло в голову, что вот так вот можно шунтировать! Непосредственно на то, что я сформулировал вы привели исчерпывающее решение, ну может быть void shift(IteratorT begin, IteratorT end, int offset) { while (begin != end) { *begin++ = (*begin).addDays(offset * 7); } }
|
|
|
33
|
Программирование / С/C++ / Re: Compile-time определение реверсивности итератора (reverse_iterator)
|
: Апрель 15, 2021, 14:49
|
Друзья, все по-своему правы (зависит от контекста). Пожалуй, чтобы лучше "прочувствовать" приведу здесь саму задачу, решая которую и создал этот топик. Это типовая задача, в которой есть связь типа и константы. Итак, задача: есть диапазон дат (QDate), задаваемый парой итераторов [begin, end). Даты идут с шагом в 7-дней. Необходимо сдвинуть диапазон влево или вправо на любое заданное число элементов, при этом новые даты должны продолжать последовательность. Например, [2021-04-8, 2021-04-15, 2021-04-22] после сдвига влево на 2 станет [2021-04-22, 2021-04-29, 2021-05-06], а после сдвига на 4 - [2021-05-06, 2021-05-13, 2021-05-20]. Это отдаленно похоже на std::shift_left, std::shift_right из C++20, но мы ограничены C++17. Допустимо сделать две функции shift_left и shift_right, а можно обойтись и одной shift, в которой направление сдвига задается типом итераторов (прямой - влево, обратный - вправо) или знаком смещения ('+' - влево, '-' - вправо). Это на ваш выбор. Например, если направление сдвига задаем типом итератора (соот-но, будет беззнаковое смещение), то прототип такой: template <typename IteratorT> void shift(IteratorT begin, IteratorT end, typename std::iterator_traits<IteratorT>::difference_type offset) Если мысленно представите или набросаете решение, при этом стремясь к элегантности, которая в данном случае даст гибкость, производительность, включение универсальности ... и будет мало букв в коде, то поймете мой изначальный вопрос.
|
|
|
36
|
Qt / Qt Quick / QQmlListProperty<const QObjectDerived> (обратите внимание на 'const'): возможно?
|
: Апрель 10, 2021, 19:11
|
Собственно, если имеется QML-доступное списочное свойство Q_PROPERTY(QQmlListProperty<const QObjectDerived> items READ items NOTIFY updated) то на стороне QML возникает ошибка unregistered type. Если убираем 'const', работает без проблем: Q_PROPERTY(QQmlListProperty<QObjectDerived> items READ items NOTIFY updated) Есть ли возможность использовать const-вариант?
|
|
|
37
|
Qt / Qt Quick / QML: избыточное создание невидимых объектов в угоду простоте
|
: Апрель 10, 2021, 08:11
|
Изучаю QML. Похоже, здесь используется парадигма заблаговременного создания невидимых объектов на все случаи возможного использования. Например, в "Qt-v5.12.3-src\qtquickcontrols\src\dialogs\DefaultMessageDialog.qml" используется такой код: ... Button { id: openButton text: qsTr("Open") onClicked: root.click(StandardButton.Open) visible: root.standardButtons & StandardButton.Open } Button { id: saveButton text: qsTr("Save") onClicked: root.click(StandardButton.Save) visible: root.standardButtons & StandardButton.Save } ...
Т.е. создается ~20 кнопок, но видимыми становятся только несколько. Конечно, QML-контролы не задействуют много ресурсов (нет системных хэндлов, например), но все же память, да и сам принцип - зачем создавать то, что не используется. Это не в духе С/С++. Это мне напоминает "формоклепание". Что думаете?
|
|
|
38
|
Qt / Qt-инструментарий / QtCreator: обновление даты в doxygen-преамбуле файла
|
: Апрель 08, 2021, 07:31
|
Имеем такую преамбулу файла: /// \file /// \brief Application main file /// \author John Doe /// \date 27.Mar.2021 Покуда файл открыт в Креаторе, как изменить дату (/// \date 27.Mar.2021) на текущую посредством какого-нибудь шортката? Какой плагин? В целом, это не doxygen-specific задача, а задача изменения любого таггированного куска (например, ##date<27.Mar.2021>, где таг ##date<...>). Просто предполагаю, что в случае doxygena уже может быть готовое решение, плагин там какой.
|
|
|
39
|
Qt / Qt Quick / Re: Показ модального диалога с последующим удалением
|
: Апрель 06, 2021, 09:29
|
Или, чтобы не зависеть от внешней ссылки (appWindow): ... //##note: When the main window is closing at the dialog opened, here the dialog // itself is already destroyed, and its properties are 'undefined'. if (typeof object.parent !== 'undefined') object.destroy() ...
|
|
|
40
|
Qt / Qt Quick / Re: Показ модального диалога с последующим удалением
|
: Апрель 06, 2021, 09:23
|
Пока что пофиксил в таком духе: ApplicationWindow { id: appWindow Menu { MenuItem { text: qsTr("About...") onTriggered: { function destroyAboutWindow() { //##note: When the main window is closing at the dialog opened, here the main // window ref. is already nulled. The main window will destroy the dialog while // its own destruction. if (appWindow) object.destroy() }
var component = Qt.createComponent("AboutWindow.qml") var object = component.createObject(appWindow) console.assert(object) object.open() object.closed.connect(destroyAboutWindow) } } } }
|
|
|
41
|
Программирование / С/C++ / Re: Ассоциации (?)
|
: Апрель 03, 2021, 08:09
|
Хз. Год прошел. Но если прям нужна уверенность, то, навскидку, как-то так: #include <iostream>
enum Param { First, Second, Third };
template <Param> const char* ParamName = "Not associated!"; template <> const char* ParamName<First> = "First parameter name"; template <> const char* ParamName<Second> = "Second parameter name";
// Для третьего параметра "забыли" специализацию, поэтому будет "Not associated!".
int main() { std::cout << ParamName<First> << std::endl; std::cout << ParamName<Second> << std::endl; std::cout << ParamName<Third> << std::endl; // Not associated!
return 0; }
Или еще лучше - с компайл-тайм детектион: template <Param> const char* ParamName = "Not associated!"; заменить на template <Param> const char* ParamName = [](){ static_assert(0, "Not associated!"); return nullptr; }();
В этом случае строка std::cout << ParamName<Third> << std::endl; // Not associated! просто будет давать ошибку компиляции. Здесь С++17 (template variables/constants, invokable lambda), но в С++11 это тоже принципиально достижимо. З.Ы. Сам всегда делал (и делаю) перечисление + массив строк (как у вас). Да, при изменении нужна скрупулезность. Зато достоинство - простота и читаемость кода. Да и часто для строк нужно делать перевод на разные языки, а это уже что-то вроде QCoreApplication::translate("context", QT_TRANSLATE_NOOP("context", "First parameter name") и только рантайм.
|
|
|
42
|
Программирование / С/C++ / Compile-time определение реверсивности итератора (reverse_iterator)
|
: Апрель 03, 2021, 06:47
|
Имеем такой шаблон функции, где нужно в зависимости от того, прямой на входе итератор или реверсивный (reverse_iterator) генерировать ту или уную константу: template <typename IteratorT> static void shiftWeeks(IteratorT begin, IteratorT end) { .... static const int DayStep = 7 * (IsReverseIterator<IteratorT> ? -1 : 1); .... }
Задействовать контейнер (подавать его на вход функции) нельзя. Пока что прицепился к reverse_iterator::base() - этой функции нет у iterator: template <typename, typename = void> inline constexpr bool IsReverseIterator = false;
template <typename T> inline constexpr bool IsReverseIterator<T, std::void_t<decltype(std::declval<T>().base())>> = true;
В С++17 более никаких compile-time отличий не нашел (а хотелось бы какой-нибудь тэг направления). Допускаю, что что-то пропустил. И, кто уже юзает C++20, - как там в плане новшеств этом вопросе?
|
|
|
44
|
Qt / Работа с сетью / QNetworkAccessManager: не работает после первой ошибки
|
: Март 31, 2021, 07:09
|
Qt 5.15.2. Пусть загружаем с FTP сервера два файла: good.txt - файл реально есть на сервере и bad.txt - файла попросту нет на сервере.
Если первым посылаем запрос для загрузки bad.txt, то получаем ошибку об отсутствии файла, все как полагается, но далее второй запрос на загрузку good.txt просто не выполняется.
Есть ли вменяемое решение, кроме как загружать каждый файл отдельным инстансом QNetworkAccessManager. Возможно, сторонние либы типа QFtpServer? Какие стоящие по вашему опыту? Да, раньше пользовался QFtp.
|
|
|
45
|
Qt / Qt Quick / Показ модального диалога с последующим удалением
|
: Март 16, 2021, 19:33
|
Друзья, не особо люблю GUI-программирование, но решил заняться QML. Задача следующая: когда выбирается пункт меню "О программе..." нужно: 1. Создать диалог (AboutWindow.qml). 2. Отобразить его на экране в модальном режиме. 3. Когда диалог будет закрыть, уничтожить его. Вот рабочий набросок, но с изъяном - при открытом диалоге и завершении программы (например, на десктопе закрываем главное окно (Alt+F4)) в destroyAboutWindow() диалог уже находится в процессе уничтожения. ApplicationWindow { Menu { MenuItem { text: qsTr("About...") onTriggered: { //TODO: At open dialog and app closing: TypeError: Property 'destroy' of object TypeError: Type error is not a function function destroyAboutWindow() { object.destroy() }
var component = Qt.createComponent("AboutWindow.qml") var object = component.createObject(appWindow) console.assert(object) object.open() object.closed.connect(destroyAboutWindow) } } } } Вытекающий подвопрос: как идиоматически воплотить на QML следующую конструкцию (это искусственный пример - просто для иллюстрации): void showAboutDialog() { auto dialog = new QDialog; dialog->deleteLater(); dialog->exec(); // blocking call, shows modal dialog with its own event loop } ?
|
|
|
|
|