marked-one

Не совсем понятно что за "мобильный банк". Если именно банк как полный аналог аналогичного оффлайнового, то открывать свою конторку - затруднительно. Требуется получение лицензии от ЦБ РФ на осуществление финансовой деятельности (которую получить судя по требованиям не так просто) + разрешения различных бюрократов (количество и набор зависит от того какие виды услуг Вы собираетесь оказывать). И вроде Вам потребуется внушительная сумма для обеспечения деятельности в каждый момент времени (т. е. в самом начале, до получения первой прибыли Вам надо будет иметь N миллионов рублей). Ну и управлять всем этим программист не сможет, нужны аналитики, финансисты и т. п. Т. е. тут явно лучше выступать "прокси" к существующему банку добавляя свою маржу.

1. Текущая версия Unity - 4.6.1
2. Разрабатывайте свою игру в десктопном варианте, помня про ограничения iOS
3. На момент деплоя и тестирования мак (или хакинтош) у вас должен быть
4. Подписка разработчика вам понадобится только если вы соберетесь распространять свою игру через AppStore (ну, других вариантов у вас нет по сути)

Не важно, где хранится исходный контент (вконтакте, на SoundCloud или где-либо еще). Если Вы размещаете этот контент (пусть даже посредством виджета) на своём домене и хостинге, Вы автоматически становитесь распространителем контента, нарушающем авторские права.

В вашем примере каждое из чисел, кроме 5, делится на предыдущее. Поэтому, до определённого момента - пока осталось заплатить не меньше 10 руб, и в кошельке есть купюры не меньше 10 - можно пользоваться "жадным" алгоритмом - брать самую большую купюру, которая меньше остатка стоимости товара.
Допустим, что остались только монеты по 1,2,5 руб. Если есть хотя бы одна монета 1 руб - то платить пятирублёвой монетой безопасно, даже если останется нечётная цена - то набрать её рублём и двушками удастся. Если есть две монеты по 5 руб, и осталось заплатить не меньше 10 - смело тратьте одну из них. Вторую тратить подождите, это может быть опасно.
В конце концов у вас останутся только пятачки и двушки, причём либо пятачков не более одного, либо осталось заплатить меньше десятки. Смотрите. Если надо заплатить нечётную сумму: если пятачков нет или надо заплатить 1 или 3 рубля - задача неразрешима. В противном случае тратите пятачок, остаётся чётная сумма.
Пытаетесь набрать остаток двушками. Если их хватило - вы победили. Если нет, то вам подсунули неразрешимый пример...
Если бы набор купюр и монет был из времён СССР (1,2,3,5,10,15,20,50,100,300,500,1000,2500,5000,10000), задача была бы значительно сложнее и интереснее.

UPD. Моё решение неверно. Кто найдёт контрпример?

Более правильный вариант.
- если есть хотя бы одна монета в 1 руб, то работает "жадный" алгоритм - в цикле платите самой большой купюрой, которая у вас есть и не превышает остатка суммы.
- если монеты 1 руб. нет:
- - если сумма, которую надо набрать, нечётна, а пятачка нет, вы проиграли.
- - если сумма, которую надо набрать, нечётна, и есть хотя бы один пятачок, вносим его. Переходим к следующему пункту.
- - если остаток суммы, который надо набрать, чётен - объединяем пятачки в пары (и по одному пятачку платить не будем, даже если хочется). И запускаем жадный алгоритм. Если задача разрешима, то он справится.

достаточно мне заменить точку на стрелочку и, разумеется, объект на указатель на объект и (о чудо!) всё работает

Самого главного не сказал: "и объект QWidget на стеке текущей функции на объект в куче".

Чисто академический вопрос: почему так?

Потому что в первом случае виджет разрушается при выходе из функции show_widget, а во втором остаётся болтаться в куче. Выход происходит сразу после возврата из QWidget::show, а сам этот вызов неблокирующий.

Как выяснилось (после 2 часов отладки вперемежку с нецензурной руганью) статические переменные a, b оказались одними и теми же (хранятся по одному адресу) для всех объектов классов B, C, D.
Разве они не должны быть в каждом объекте класса разными?

Начнём с того, что эти переменные вообще не принадлежат объекту. Это локальные переменные функции. А функция у вас определена одна единственная, A::func. B и C унаследовали это определение, своих функций func у них нет.

Есть такое понятие, как уровни OSI https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D...
Чем уровень выше, тем проще как разработчику, но работает медленно. Чем ниже, тем сложнее разработчику, зато работает быстрее.
WOT как и большинство онлайн игр работает на UDP.
"Различные MMORPG " отлично справились с проблемой передачи данных не только благодаря протоколу передачи данных. Есть еще куча технологий и алгоритмов которые использовались при разработке.
Например предсказания. Если от игрока пришел пакет, что его персонаж бежит вверх, то не стоит через 1/24 секунды (один кадр) останавливать персонажа, не дождавшись следующего пакета. Скорее всего следующий кадр его персонаж будет бежать дальше.
И еще, не стоит "передавать огромное кол-во данных". Необходимо передавать только то, что необходимо. Например, анимация персонажей, зачем каждому игроку передавать информацию о замахивании топором, если можно передать один байт, который соответствует типу "сейчас_персонаж_машет_топором". Это очень просто наблюдать на примерах существующих MMORPG когда у Вас пропадает интернет. Все персонажи залипают на текущей анимации
Андрей При любом качестве связи UDP быстрее.