Что касается вашего вопроса, то capacity это максимальное количество элементов во всей HashMap. То есть сумма элементов во всех бакетах.
Похоже, что документация к HashMap противоречит этому:
The capacity is the number of buckets in the hash table, ...
Тут не говорится о том, что capacity - сумма элементов во всех бакетах. Тут говорится, что capacity - это количество самих бакетов, про элементы в бакетах нет упоминаний. Вопрос только в терминах: похоже, что то, что вы называете "capacity", в документации - "number of entries".
Да, на всякий случай, цель моего первого комментария - пересмотреть формулировку о различии бакетов по ёмкости и соответственно формулу об их взаимосвязи ниже. Документация, например, здесь.
Bucket -ы различаются по ёмкости (свойство capacity). Отношение между bucket и capacity выглядит следующим образом:
capacity = number of buckets * load factor
В то время как в документации к HashMap пишется: "The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created."
Возможно, имелось в виду, что: макс. количество элементов (entries) в HashMap до перехэширования <= capacity (number of buckets) * load factor ?
Время от времени вас могут выдёргивать вне рабочего времени, если есть необходимость в критической правке. Или же иногда приходиться принимать решения за других участников команды (как правило, в отношении интерфейсов между модулями разрабатываемой системы), если в противном случае жертвой становится успех проекта. В общем, сюда включаются различные отвлекающие шумы и посторонние активности по отношению к непосредственному написанию кода. Очевидно, что в любом деле это будет иметь место. Но когда ты работаешь напрямую со сравнительно большим количеством людей, лодка будет раскачиваться сильнее.
сделал дополнения, спасибо за активное участие в обсуждении, за информативные комментарии (особенно Xlab, IGHOR), за дополнительные комментарии и разъяснения в лс — tass, V0VaN.
Плюсы удобней (особенно если всегда на них писал). Но если, например, человеку из веб-разработки привычней JS, то почему бы не использовать этот язык для логики? Самое главное, что такой выбор есть.
JavaScript не использовал, потому что хотел больше погрузиться в сам Qt и было желание писать на C++. Предложенный вами способ возьму на заметку, спасибо.
Очень даже возможно. Обычно делается через кучу сигналов в бекенде, а в кумле эти сигналы слушаются и делаются нужные вещи. Только сигналы конечно не вида paintButtonInColor(), а вида someActionAllowed() и кумль уже сам там разбирается что ему надо сделать при этом. В идеале бекенд не должен знать вообще ничего о том, как устроен UI, иначе можно однажды упереться в абсолютную неподдерживаемость такого кода (когда там будут сотни зависимостей между бекендом и фронтендом и даже небольшое изменение фронтенда приведет к куче багов).
Здравая рекомендация, благодарю. Такая идея мне почему-то в голову не пришла: действительно будет намного удобней, чтобы не заморачиваться с огромным числом зависимостей между бэкендом и QML. Плюс в теории таким образом можно удобно разделить разработку приложения на 2 независимые части для фронтендщика и бэкендщика. В очередной раз убеждаюсь в хорошей гибкости Qt.
Это наверно один из худших вариантов, как можно работать с кумлем
Поэтому от этого варианта и отказался впоследствии. Хотел сделать, как было бы удобней для меня, но, как оказалось, всегда нужно учитывать специфику самого инструментария
не надо так делать, пожалуйста. Вы сейчас убили очень много котят этими строками. Есть же анкоры.
Прислушаюсь здесь. Буду использовать анкоры в будущем. Изначально думал, что с расчётами размеров относительно главного окна будет наглядней и удобней.
не стоит ради такой мелочи городить external reference
как следует поступить лучше в данном случае?
Конечно, зачем нам text у самой кнопки, к чему бы он нам
Опять-таки, видеть подпись у label логичней, имхо. Если так критично расположение одной строчки с text, аргументируйте, пожалуйста
Ни к чему, можно просто QObject. Тем более что все равно он идет как контекстное свойство, даже не как кумльный элемент
Можно, опять-таки, не вижу здесь критичности.
это не просто зло, это зло в квадрате. Вся логика работы с UI должна быть в кумле
Всю логику UI порой в принципе невозможно перенести в QML. В зависимости от работы в бэкенде, может и меняться UI. Но действительно здравое решение делать функции, изменяющие параметры элементов UI в самом QML. Я правильно понял вашу мысль? Подобное решение использовал, т.к. изначально хотел использовать знакомые по разработке в Android идиомы, там же в самой вёрстке логика не прописывается, верно (если не создавать кастомные классы для UI). Впрочем, повторюсь, используешь инструментарий — используй по его гайдлайнам.
Хм, честно говоря, не знал, что под «нативом» в первую очередь подразумевают именно нативный C/C++ код. Всегда считал, что натив — это просто использование SDK соответствующей платформы без дополнительных слоёв сверху в виде кроссплатформенных фреймворков и библиотек. Спасибо, учту, буду точнее в определениях.
С последним высказыванием абсолютно согласен. Более того, иногда можно увидеть, как на том же Unity3D (а в нём нативных контролов нет) делают не только игры, прикручивают, например, работу с БД, MVC и тд и тп. Хотя огромная редкость, конечно.
Насчёт интеграции скажу точно, что можно через QAndroidJniEnvironment и QAndroidJniObject получать доступ к нативным java-классам Android'a (похоже на рефлексию в Java). Поддержка x86 есть
Похоже, что документация к HashMap противоречит этому:
Тут не говорится о том, что capacity - сумма элементов во всех бакетах. Тут говорится, что capacity - это количество самих бакетов, про элементы в бакетах нет упоминаний. Вопрос только в терминах: похоже, что то, что вы называете "capacity", в документации - "number of entries".
Да, на всякий случай, цель моего первого комментария - пересмотреть формулировку о различии бакетов по ёмкости и соответственно формулу об их взаимосвязи ниже. Документация, например, здесь.
В тексте есть следующее упоминание:
В то время как в документации к HashMap пишется: "The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created."
Возможно, имелось в виду, что:
макс. количество элементов (entries) в HashMap до перехэширования <= capacity (number of buckets) * load factor
?
Здравая рекомендация, благодарю. Такая идея мне почему-то в голову не пришла: действительно будет намного удобней, чтобы не заморачиваться с огромным числом зависимостей между бэкендом и QML. Плюс в теории таким образом можно удобно разделить разработку приложения на 2 независимые части для фронтендщика и бэкендщика. В очередной раз убеждаюсь в хорошей гибкости Qt.
Поэтому от этого варианта и отказался впоследствии. Хотел сделать, как было бы удобней для меня, но, как оказалось, всегда нужно учитывать специфику самого инструментария
Прислушаюсь здесь. Буду использовать анкоры в будущем. Изначально думал, что с расчётами размеров относительно главного окна будет наглядней и удобней.
как следует поступить лучше в данном случае?
Опять-таки, видеть подпись у label логичней, имхо. Если так критично расположение одной строчки с text, аргументируйте, пожалуйста
Можно, опять-таки, не вижу здесь критичности.
Всю логику UI порой в принципе невозможно перенести в QML. В зависимости от работы в бэкенде, может и меняться UI. Но действительно здравое решение делать функции, изменяющие параметры элементов UI в самом QML. Я правильно понял вашу мысль? Подобное решение использовал, т.к. изначально хотел использовать знакомые по разработке в Android идиомы, там же в самой вёрстке логика не прописывается, верно (если не создавать кастомные классы для UI). Впрочем, повторюсь, используешь инструментарий — используй по его гайдлайнам.
Ещё раз спасибо за развёрнутый комментарий
С последним высказыванием абсолютно согласен. Более того, иногда можно увидеть, как на том же Unity3D (а в нём нативных контролов нет) делают не только игры, прикручивают, например, работу с БД, MVC и тд и тп. Хотя огромная редкость, конечно.