Mercury13

Я просто вынесу ответ из обсуждений.

Ёмкость механических дисков и SSD — неформатированная доступная пользователю в десятичных единицах. Для них надо вычесть:
• коэффициент перевода из десятичных гигабайт в более привычные двоичные гигабайты (или гибибайты, как их недавно обозвали);
• главный загрузочный сектор;
• таблицу разделов, загрузочные сектора разделов, скрытые разделы, неразбитое место;
• технические поля файловой системы.
Технические поля винта/SSD скрыты и вычитать из номинальной ёмкости их не надо.

Ёмкость флэшек — полная ёмкость чипов памяти в двоичных единицах. Для флэшек надо вычесть:
• технические поля самóй флэшки (в них пишется как минимум таблица сбойных секторов, жёстко заданная на заводе);
• главный загрузочный сектор;
• таблицу разделов, загрузочные сектора разделов, скрытые разделы, неразбитое место (если есть; чаще флэшки форматируют в единый раздел);
• технические поля файловой системы.
Из-за особенностей адресации не имеет смысла делать чипы полупроводниковой памяти не двоичного размера. Просто во флэшке один-два чипа, в SSD — целая батарея, и чтобы износ, неизменный спутник системного раздела, не сделал в SSD дыру, там есть сложные механизмы резервирования секторов и балансировки износа. Потому в SSD принцип винчестерный, а не флэшечный.

«Десятично-круглая» цифра — неплохая оценка, сколько поместится на флэшку. Цифра не точная, т.к. зависит от модели флэшки и файловой системы на ней, но очень близкая к реальности. А на винчестер столько гарантированно не поместится.

www.ixbt.com/storage/flashdrives/svodka/size.shtml
Вот по этой ссылке видим, что в Windows может быть доступно как немного больше 4 млрд, так и немного меньше. А если взять неформатированную ёмкость первой попавшейся флэшки — у меня получилось 4039114752 байт, круглое плюс 1%. Для сравнения: неформатированная ёмкость моего «хитати» будет 2000395698176 байт — круглое плюс 0,02%. Вот вам разница между флэшкой и жёстким диском.

P.S. У меня экономии ради диски только механические, завтра на работе проверю ёмкость SSD.
UPD. Посмотрел. «СамСунь» неформатированного объёма в 256.052.822.016 байт. Отформатирован в один раздел объёмом 255.466.663.936. Так что тут явно по-винчестерному, с заделом в 0,02%.

P.P.S. Возьмём реальную флэшку Verbatim на 8Г = 8589934592.
Если вычесть технические поля, получится неформатированный размер, который равняется 7640M = 8011120640. Съедено 579 млн байт.
Загрузочный сектор и таблица разделов — мизер.
Куда больше занимают технические поля файловой системы. Раз на диске доступно 8010067968 байт, то съедено всего 1,05 млн. Но это NTFS, вероятно, там нет таблицы размещения файлов, которая всегда занимает определённые секторы.
Действительно, форматирование в FAT дало размер 7993294848 байт, т.е. технические поля FAT заняли 17,8 млн.

Итератор — это объект с семантикой указателя, который может указывать на N+1 точку в объекте.

Раз он с семантикой указателя, у него есть операции «унарная звезда» и −> (разыменование и разыменование+взятие поля). Также у итератора есть операция ++ (сдвинуться на следующую позицию). Если это т.н. «однонаправленный итератор» — всё, больше ничего.

Также бывают т.н. двунаправленные итераторы (есть операция −−), и итераторы произвольного доступа (их можно свободно складывать с числами — ну совсем как указатели). В частности, у std::list итераторы двунаправленные.

У итераторов неопределённое поведение…
• при попытке выйти за начало или конец;
• при попытке разыменовать, если он смотрит на последнюю позицию (отмеченную как «конец»).

Конкретно о задаче.
1. std::vector предпочтительнее std::list.
2. Не нужно возвращать string*, хватает какого-нибудь контейнера (std::vector<std::string> или std::list<std::string>).
3. Если функциональности и скорости istringstream хватает, флаг в руки! Я бы написал по хардкору, с нуля. Вот мой код, выдранный из моего проекта, наверно, будет несложно переделать его в учебный.

void parseCommaList(
        const char *aStart,   // указатель на начало
        const char *aEnd,    // указатель на символ за концом
        char aComma,        // символ-разделитель
        bool aSkipEmpty,   // true, если пустые подстроки пропускать
        ProcParseCommaList aCallback,   // функция-нагрузка
        void *aData)   // этот параметр нужен, чтобы передавать какие хочешь данные в функцию-нагрузку, удаляй его смело!
{
    str::trim(aStart, aEnd);    // моя функция; пододвигает aStart вперёд и aEnd назад, убирая пробелы.
                                // Если удаление пробелов не нужно — удаляй! Если нужно — пиши сам.
    if (aStart == aEnd) return;
    const char *sstart = aStart;
    for (const char *p = aStart; p != aEnd; ++p)
    {
        if (*p != aComma) continue;
        const char *send = p;
        str::trim(sstart, send);   // то же самое, можно убрать
        if (p != sstart || !aSkipEmpty)
            aCallback(sstart, send, aData);    // замени на боевую нагрузку
        sstart = p + 1;
    }
    str::trim(sstart, aEnd);   // то же самое, можно убрать
    if (sstart != aEnd || !aSkipEmpty)
        aCallback(sstart, aEnd, aData);    // замени на боевую нагрузку
}

И, соответственно, версия для std::string.

inline void parseCommaList(
        const std::string &aIn,
        char aComma,
        bool aSkipEmpty,
        ProcParseCommaList aCallback,
        void *aData)
{
    parseCommaList(aIn.data(), aIn.data() + aIn.length(), aComma, aSkipEmpty,
            aCallback, aData);
}

Размер экрана iPhone 6 — 750×1334 px.
Для рекламных тизеров его действительно стоит уменьшить, например, вдвое.
А когда показываем заказчику/программисту/верстальщику скриншоты, макеты и прочее — только хардкор, только пиксель в пиксель.

Окончательно разобрался.
1. Да.
2. Да.
3. Да.

Нет, вам нужны разветвители типа 06013 или 06015 — которые «для старых ноутбуков» и на одном конце нарисована клавиатура, на другом мышь.

USB-адаптеры с али позволяют подключать сколько угодно каких угодно клав и мышей (мультиплексирование на USB, в отличие от PS/2, есть), но, по опыту, многие из знакомых мне адаптеров подглючивают (клавиатура на время пропадает).

Вариантов много, в зависимости от того, форма модальная или нет, и нужно ли каким-то моделям передавать сообщение «обновись».

Вариант 1.

class AddItem : public QWidget
{
public:
  AddItem(QWidget* aParent, QList<Institution>& aInstitutions)
      : QWidget(aParent), institutions(aInstitutions) {}
private:
  QList<Institution>& institutions;
};

Во втором варианте у нас модальная форма, но редактировать можно только копию (например, институции первой формы задействованы в какой-то модели, или нужны каскадные удаления, или что-то ещё).

class AddItem : public QDialog
{
public:
  int exec(QList<Institution>& aInstitutions);
private:
  QList<Institution> institutions;
};

int AddItem::exec(QList<Institution>& aInstitutions)
{
  institutions = aInstitutions;
  int r = QDialog::exec();
  if (r) {
     aInstitutions = std::move(institutions);
  }
  return r;
}

И много-много других вариантов.

ООП рассчитано не на скорость исполнения, а на скорость разработки. Как, впрочем, и многие другие современные технологии разработки. Всё, что ООП делает, можно реализовать и без ООП, и даже эффективнее. Стоит ли — другой вопрос.

Какую задачу конкретно решает ООП? Обуздать сложность разработки программ, собранных из взаимодействующих компонентов. Вот от этого и пляшем: если программа не модульная (например, какой-нибудь сложный научный расчёт), ООП мало поможет. Также ООП не поможет, если стандартная реализация ООП недостаточно эффективна по процессору или по памяти — например, в мою бытность JavaMe’шником ООП не жаловали, поскольку памяти много ел, типичный мобильник имел от 215 до 800 килобайт доступной памяти. Также плохо будет работать там, где нет взаимодействия (на типичном PHP, который выдал страничку и исчез).

Что на PHP можно реализовать объектно?
• Поддержку каких-то протоколов (БД, почта, какая-нибудь внешняя веб-служба наподобие VK API или Mandrill).
• Что-нибудь из предметной отрасли, что меняет своё состояние — например, генерация картинок, звуков, архивов, PDF…
• Может, сделаешь какой-нибудь генератор страниц, который сначала собирает каркас страницы, а затем, в зависимости от настроек и целевого устройства, обращивает его HTML-кодом.

Скажу по-другому: в тех местах, где не нужны углы в явном виде, тригонометрия, скорее всего, излишня, и действительно вопрос очень часто можно решить средствами векторной алгебры. В большинстве задач геймдева и трёхмерной графики — так точно.

Ну буду настолько категоричным, чтобы сказать «полностью». Была как-то задача: есть шарнирный четырёхугольник, по диагонали натянута пружина. Может ли эта конструкция (в первом приближении) сымитировать педаль сцепления автомобиля? А то даже у Logitech G27 педаль сцепления не слишком убедительная. Решал численно и тригонометрией, хотя можно аналитически и векторной алгеброй попробовать.

ЗЫ. Основные аргументы против — простота и накопление погрешностей. Но и накопление иногда можно обойти, не прибегая к тригонометрии — например, использовать кватернионы вместо матриц поворота в 3D или нормировать вектор в 2D.