Поддержка повышения - помощь необходима
Это - корректный путь. Календари работают тот же путь. Лучшее, которое я мог предложить Вам (на основе Вашего примера) является этим:
boolean isWithinRange(Date testDate) {
return testDate.getTime() >= startDate.getTime() &&
testDate.getTime() <= endDate.getTime();
}
Date.getTime () возвращает количество миллисекунд с тех пор 01.01.1970 0:00:00 GMT и является длинным, таким образом, это легко сопоставимо.
6 ответов
Где бы я ни работал в последнее десятилетие, когда у них был свой собственный класс интеллектуальных указателей, я обнаруживал в нем ошибки - обычно в течение нескольких недель. И нет, я никогда не ходил и не смотрел его в надежде найти ошибки.
У меня появилась привычка публиковать следующую цитату из предложения интеллектуального указателя TR1 :
Разработчики Boost обнаружили, что интеллектуальный указатель с совместным владением чрезвычайно сложно реализовать правильно. Другие сделали то же наблюдение. Например, Скотт Мейерс [Meyers01] говорит:
«Сама STL не содержит интеллектуальных указателей для подсчета ссылок, и написать хороший указатель - тот, который работает правильно все время - достаточно сложно, и вы не захотите этого делать. это, если вам не нужно. Я опубликовал код для интеллектуального указателя с подсчетом ссылок в More Effective C ++ в 1996 году, и, несмотря на то, что он основан на установленных реализациях интеллектуальных указателей и подвергается обширному предварительному рассмотрению опытными разработчиками, в течение многих лет поступает небольшой набор достоверных отчетов об ошибках. Количество скрытых способов, с помощью которых интеллектуальные указатели с подсчетом ссылок могут дать сбой, замечательно ».
Это плюс подробный анализ обнаруженных мною ошибок обычно давали мне работу по включению расширенных библиотек в базу кода
. 1142315]:)
Мне кажется, вы делаете это неправильно. Поскольку предложения о добавлении новых библиотек будут встречены с большим сопротивлением, даже не пытайтесь отстаивать поддержку в целом . Вместо этого выберите свои сражения.
Найдите определенные библиотеки Boost, которые вы знаете (с вашими знаниями о приложении, в котором они будут использоваться), будут полезны и сэкономят время и деньги. А затем предложите добавить их.
Я мог бы легко перечислить библиотеки Boost, которые я нашел полезными, и почему я считаю их отличными, но я не знаю, будут ли они какими-либо используйте в своем приложении.
Настаивайте на включение отдельных библиотек Boost, а затем, возможно, со временем будет включено так много из них, что всем будет проще просто включить все Boost.
Мне пришлось поддерживать компонент, используя старый старинный Tools.h ++ из Roguewave в системе Solaris.
В Solaris, если мы хотим использовать ускорение, нам нужно использовать либо gcc , или SunStudio с реализацией стандарта STLport (вместо Roguewave). И так как Tools.h ++ требует старой предварительной стандартной реализации стандарта Roguewave - на Solaris - мне пришлось отказаться от ускорения.
В конце концов, я переписал упрощенную версию нескольких необходимых мне функций, подобных ускорению.
Если вы находитесь в такой же ситуации (*), вы не сможете перейти из библиотеки Roguewave, чтобы легко это усилить. Эта операция требует значительных затрат, поскольку, например, контейнеры указателей из обеих библиотек имеют совершенно разные интерфейсы.
(*) Где мы не можем медленно менять бит за битом старого кода, чтобы постепенно использовать ускорение. В этой ситуации миграция должна быть радикальной и одновременно заменять каждое появление Tools.h ++ чем-то более модным или даже лучшим.
NB: Большинство людей могут постепенно использовать ускорение в старых проектах и могут пропустить очень важный, да и технический, момент. Отсюда мой отрицательный ответ.
Boost - отличный инструмент и неоценимая часть разработки нашего продукта (мы бы потерялись без smart_ptr) ... но поскольку он меняется так быстро, стабильность выпусков может быть достигнута.
Например, мы, недолго думая, с радостью представили новые версии Boost, как только они вышли. Так было до тех пор, пока мы не столкнулись с ошибкой в библиотеке потоков 1.35, которая приводила к случайным (т.е. трудным для отладки), но критическим ошибкам. К счастью, мы выявили проблему до того, как что-либо было выпущено для широкой публики, и мы могли вернуться к 1.34.
С тех пор мы взяли конкретную версию, тщательно протестировали ее и не обновили без веских причин для этого.
Вот два предложения в поддержку повышения:
Кто использует Boost? ( http://www.boost.org/users/uses.html )
многие крупные проекты используют Boost: (например, Adobe Photoshop, CERN)
Повышение стоимости проекта ( http://www.boost.org/development/index.html )
Сколько будет стоить нанять команду для написания boost с нуля? Там есть изящный (несколько хитрый) калькулятор, который помогает увидеть это в перспективе.
- Это открытый стандарт, не контролируемый конкретной компанией (без затрат на лицензирование)
- Это кроссплатформенный
- Он профессионально разработан / написан и очень быстро / эффективно тщательно протестирован
- Есть реализации с открытым исходным кодом, которые ваша команда могут компилироваться сами.
- Boost скоро станет частью стандарта C ++ STL
Вот немного устаревшая статья 2005 года о докторе Доббсе, в которой обсуждается предстоящий стандарт C ++ 0x.