Что надлежащий путь состоит в том, чтобы обработать версию блока?
Вот пример. Предположим, что у Вас есть strdup () функция, которая копирует строку:
char *strdup(char *src)
{
char * dest;
dest = malloc(strlen(src) + 1);
if (dest == NULL)
abort();
strcpy(dest, src);
return dest;
}
И Вы называете его как это:
main()
{
char *s;
s = strdup("hello");
printf("%s\n", s);
s = strdup("world");
printf("%s\n", s);
}
Вы видите, что программа работает, но Вы выделили память (через malloc), не освобождая ее. Вы потеряли свой указатель на первый блок памяти при вызове strdup вторым разом.
Это не грандиозное предприятие для этого небольшого количества памяти, но рассмотрите случай:
for (i = 0; i < 1000000000; ++i) /* billion times */
s = strdup("hello world"); /* 11 bytes */
Вы теперь израсходовали 11 ГБ памяти (возможно больше, в зависимости от Вашего диспетчера памяти) и если Вы не отказали, Ваш процесс, вероятно, работает довольно медленно.
Для фиксации необходимо назвать свободным () для всего, что получено с malloc () после того, как Вы заканчиваете использовать его:
s = strdup("hello");
free(s); /* now not leaking memory! */
s = strdup("world");
...
Hope этот пример помогает!
5 ответов
Мы штампуем все сборки в наших продуктах с одинаковым номером версии, используя следующие шаги:
Свяжите все сборки с AssemblyInfoCommon.cs, содержащий Информация о номере версии: см. здесь для примера.
Создайте файл AssemblyInfoCommon.cs как часть сборки с использованием (в нашем случае) задачи NAnt asminfo, Cruise Control .NET и маркировщика ревизий SVN
В нашем случае мы не используем * версию. Все развернутые версии построены на сервере сборки. Нас не волнует номер версии на наших компьютерах.
Итак Каждая сборка должна иметь одну и ту же версию, которая обычно представляет собой комбинацию версии выпуска, то есть 3.4 + номер сборки, который представляет собой последовательность, которая представляет количество раз, когда этот выпуск компилировался на сервере сборки. Ревизия актуальна, потому что она демонстрирует количество сборок, которые вы создали для этого выпуска. Вы действительно можете сделать это одним из двух способов. Первый способ заключается в том, что если вы запланировали выпуск, то есть 3.4, тогда, когда вы начнете работать над этим выпуском, это будет ваш основной номер версии, а ваш дополнительный номер версии будет увеличиваться вместе со сборкой. Другой способ сделать это - жестко контролировать версии сборки: когда вы будете готовы выполнить свой выпуск в QA / Regression, вы установите основную версию на 3.4, а второстепенный номер версии оставите равным 0. Таким образом вы держите все под жестким контролем. пока не отпустишь. Таким образом, вы можете контролировать нумерацию вашего пакета обновления с помощью младшего номера версии. Надеюсь, это поможет.
Ответ действительно зависит от того, чего вы пытаетесь достичь с помощью номеров версий сборки. Если вы выполняете развертывание ClickOnce и хотите выполнять независимую загрузку обновленных сборок, вам нужно будет иметь независимую версию каждой сборки - в противном случае я думаю, что часто бывает хорошо, если версии сборки соответствуют номеру выпуска программного обеспечения. В более сложных сценариях вам может потребоваться другая стратегия.
Схема, которую я использовал в предыдущей компании, была major.minor.revision.build - поэтому в версии 1.0 продукта версия сборки и версия файла сборки для каждой сборки были 1.0.0.1129 (например). Это позволяло легко сопоставить, какие сборки были частью той или иной версии программного обеспечения, вплоть до номера сборки. Мы достигли этого с помощью поиска перед компиляцией и замены в каждом AssemblyInfo.
Я обычно согласен с тем, что все сборки должны иметь одинаковый номер версии; однако я бы сделал одно предостережение. Если одна из сборок используется где-то еще за пределами этого проекта или если она считается собственным проектом, она должна иметь собственный номер версии. Его также, вероятно, следует переместить из этого решения в собственное. Единственная причина, по которой я упоминаю это, заключается в том, что я видел множество случаев, когда у людей была сборка, которая использовалась в паре других мест, но в основном в одном месте, и они пытались сохранить версию прямо. Это плохая идея. Я думаю, что принцип единой ответственности применим и на уровне решения / проекта.
Что касается нумерации, я согласен с Гаем Старбаком (major.minor.revision.build). Вот так я
У нас есть большое приложение (сотни сборок) с частыми выпусками (около 1 в месяц). Мы пошли на «дать каждой сборке одну и ту же версию», но меня постоянно разочаровывает то, что сборки для одной версии полностью несовместимы с сборками другой, несмотря на то, что интерфейсы этих сборок редко (если вообще когда-либо) меняются.
Если это ваш случай, вам может быть полезно управлять версиями сборок по отдельности - каждый раз, когда вы обновляете сборку, старайтесь увеличивать номер версии только в тех случаях, когда вы действительно хотите разорвать привязку сборки (например, если интерфейс изменится или в остальном изменения настолько значительны, что вы хотите предотвратить случайное использование кем-либо предыдущей версии).