Dragon1, пальцем к носу:
1. Выбираете вообще случайным образом первое, второе и третье (или сколько там у вас блюд).
2 Сравниваете с эталоном цены и калорий, находите наиболее нарушающее этот эталон блюдо и заменяете его на аналогичное случайное.
3. Если за разумное число таких перестановок оптимум не нашелся - возвращаетесь к п. 1.
4. Повторяя все это до удовлетворения обоим показателям.
Потом, увидев уже на практике, какая херня получается, формируете более точное ТЗ и возвращаетесь к задаче снова ;)
А почитав - не злоупотреблять.
Потому что составленный с умом foreach довольно часто значительно оптимальнее и при этом, как ни парадоксально, лучше читаем, чем вымученный вызов не совсем подходящей функции обработки массива.
Владимир, ну да, сравнивать можно и так, это я погорячился.
Ну, отдебажьте код - поставьте точку останова на это самое сравнение и посмотрите глазами, что туда приходит.
Игорь, сталкивался. Но это не ситуация "все через жопу, системы нет", это ситуация "система есть, но делается через жопу". В этой ситуации одинокому айтишнику разгребать нечего.
Про конечных сотрудников и речи не было. Понимание обоих сторон автоматизации требуется тем двоим, кто ее осуществляет. Сотрудники ставятся перед фактом, и дальше идет административное лечение, айтишник может умыть руки.
Игорь, моя практика показывает обратное по обоим пунктам. Но для этого должны встретиться и договориться два грамотных человека - один со стороны бизнеса, другой со стороны IT.
Теоретики сильно любят порассуждать об окупаемости бизнеса, при этом обычно размахивают примерами размером со Сбер. А там таких конюшен и нет, потому что крупные организации в них просто завязнут и не смогут работать.
Разгребать приходится мелкий-средний бизнес, и это действительно могут сделать буквально два человека. В процессе основной работы или даже в свободное время. Главное - понимать, что делаешь и что действительно нужно сделать.
Василий Васильков, на хрена указатель и new? map по умолчанию инициализируется пустым множеством, просто insert в конструкторе.
В map можно вторым типом заявить хоть ту же выше объявленную структуру, просто незачем инициализировать этот map в заголовке, для этого есть конструктор.
Денис _______________, вот как раз безопасность в CRM и имеет место, в отличие от раскидывания всем подряд всех подряд файлов для какой угодно правки. Дать конкретному пользователю ограниченный доступ - функционал "из коробки".
Ввод данных, если это данные, а не строчки в ворде / клеточки в Ёкселе, требуется один раз - потом они под рукой, их не нужно вводить, только выбрать нужные.
PDF на первом месте в обоих списках - это правильно, разбирающийся человек составлял ;) А вот за RTF, DOC и XLS его бы выпороть, конечно.
Ага, но это и не нужно. Привычки кромешной работы в офисах - это прошлый век и техническое бессилие, в современных реалиях офис нужно не заменять на 100%, а выкинуть на 90%, заменить это колупание в файликах на CRM и вздохнуть с облегчением.
Денис _______________, вот именно для таких случаев существуют CRM, где все эти бесчисленные ОКТМО и ОГРН хранятся в базе данных, а человек видит необходимый минимум информации по проекту и работе над ним, внося поправки одной кнопкой и при любой необходимости генерируя по шаблонам тонны чиновничьей макулатуры, гарантированно содержащей бьющиеся между собой данные. Причем не в офисных форматах, которые может перекосить на конкретной машине, а в аккуратных PDF, гарантирующих неизменность документа. При желании - с подписями, печатями или электронной подписью, если чиновники уже с пальмы слезли.
Игорь, какая глубокая мысль...
Я сталкиваюсь с офисными файлами. И с тем колхозом, который вследствие их чрезмерного использования разводится в бизнесе. Однажды тем, кто думает о будущем, приходится приводить эти конюшни в порядок. Иногда - с моей помощью.
Takumi_Swift, ну, мы таки не можем знать за ваш смартфон - может, на нем блокировщик не в браузере...
В конце концов, посмотрите на компьютере, который файл стилей предположительно не загружается - и попробуйте его по прямой ссылке открыть на смарте, что покажет?
Lost_Universe, это была проверка не возможностей плюсов, а ваших знаний о них.
Статический и динамический методы элементарно имеют разные сигнатуры (динамическому первым аргументом передается ссылка на объект), так что такое переопределение, как у вас, в принципе невозможно.
