Стандартный программист

Просто также, как когда-то было с инженерами, происходит и с программистами (сисадмины выделились из «компьютерщиков» уже в прошлом веке). Первые инженеры были на все руки мастера, а сейчас есть и сантехники, от которых требуется лишь привинтить стандартный смеситель к стандартному трубопроводу, ничего при этом не разрушив, и разработчики ракетных двигателей, которым надо думать, что бы трубопровод не прогорел и не развалился от вибрации во время ресурса движка, поэтому этот трубопровод надо хитро изогнуть и снабдить охладительными каналами. Это не плохо, просто чем дальше, тем бОльшая будет специализация.

Мне кажется, я догадываюсь о ком ты :)

нет. Когда-то придумывал ник для форума, в голове вертелась музычка из Insult MD. Вот и обозвался…

Дайте ссылку на авторитетный источник.
Только, пожалуйста, не новости о британских ученых.

В том то и дело, что иначе, а не неэффективнее.

Нда-а, ребят.

forth programmer detected :)

Можно два char* использовать — на индексах и их вычислениях сэкономим. :)

пока писал уже написали мое решение :)

Переполнение фигня. Было бы желание, а умножить можно любые числа.

ну ну тогда общий алгорит примерно такой, как мне кажется:
смотрим есть ли у нас нули, если есть — убираем, иначе задача не имеет смысла
смотрим есть ли отрицательные значения
если отрицательное одно — выкидываем его — задача решена
если отрицательных более одного — определяем четное их число или нет, если четное — выкидываем наименьшее положительное число — задача решена
если нечетное число отрицательных — выкидываем наибольшее отрицательное (т.е. в последовательности -4,-3,-2 выкидываем -2) — задача решена

вроде ничего не упустил

абсолютное значение — это и есть по модулю ;)

итак, с 3 попытки:
1)если отрицательных четное кол-во и присутствует 0 — выкидываем 0
2)если отрицательных нечетное кол-во и присутствует 0 — выкидываем что-то кроме 0
3)если отрицательных нечетное кол-во — выкидываем максимальное отрицательное
4)если отрицательных четное кол-во — выкидываем минимальное положительное

Наличие в массиве нулей вообще ничего не меняет.
Разве что можно пока отрицательные числа считаем, если насчитали больше одного нуля — возвращаем 0 (ведь если первый элемент выкинем — произведение будет максимальным). Это немножно сэкономит процессорное время.

Если в массиве есть ноль и одно отрицательное значение, то надо оставить именно 0.

А, про отрицательное не сообразил. Произведение ж тогда тоже отрицательным будет.

Как же это у нас получится) чтобы произведение было отрицательным нужно убрать одно из отрицательных(при четном количестве). А мы удаляем меньшее НЕотрицательное число.

Тоже вариант — DOM с ленивым парсингом вложенных эленентов, однако тут тоже ведь нужно не просто так строку пропустить, а с учетом вложенности и т.п., да и весь JSON будет в памяти висеть. Мне больше нравится работать с событийными парсерами — экономия ресурсов и возможно обрабатывать огромные объемы, например сильно удобно при загрузке инфы в базу: DOM для миллиона записей построить можно, но несколько нецелесообразно, а вот по мере сборки нужной части данных сбрасывать ее в БД, освобождая память — самое то. А еще из событийного парсера генерить DOM — простая задача, а вот наоборот уже сложно.

На самом деле я стараюсь придерживаться той точки зрения, что у нас всегда есть 3 варианта: использовать чье-то готовое, придумать и написать свое и (достаточно редко рассматриваемый) написать свое по всем известному алгоритму или подходу. Плюс поиск решения должен начинаться с анализа того, что у нас уже есть, а не с поиска уже готового.

На самом деле в больших проектах в полный рост стоит проблема использования сторонних наработок т.к. просчитать последствия решения очень сложно и можно не только не получить желаемый результат, а поиметь массу проблем. Предположим у нас есть проект, в котором уже давно живет стороннее решение (обозначим его А) строго определенной задачи, нам нужно реализовать доп. функции, которые есть в готовом стороннем решении (назовем его Б), но это готовое решение использует другую наработку (назовем ее В), которая полностью повторяет решение А, и пусть даже они не конфликтуют, тогда у нас получается куча вариантов:
1. Развести зоопарк — в проекте будут решения А, Б и В, тогда нам нужно строго регламентировать использование решений А и В, иначе получим проблемы. Так же нам нужно конфигурить при установке оба практически одинаковых решения, что может повлечь ошибки.
2. Если можно, то заменяем решение А на решение В с переписыванием соответствующих частей, в проекте останется решения Б и В.
3. Можно попытаться решение Б заставить работать не с В, а с решением А.
4. Можно попытаться написать аналог решения Б, но с учетом использования нами решения А, после чего выложить его в свободный доступ и еще чуть-чуть увеличить хаос.

Есть, конечно, решения, которые самому писать нецелесообразно по причине огромного объема работ, или попытаться заменить широко используемые решения. Я не думаю, что целесообразно писать что-то свое для работы (например) с ЭЦП, работы с SMTP или Jabber протоколами или парсер XLS файлов (или совсем для одержимых — свою реализацию VM), однако написать парсер JSON или логгер под конкретную задачу в строго определенном контексте — почему бы и нет.

Как я уже говорил: самое главное — не впадать в крайности.