Re[4]: Проект утилитной библиотечки - .NET

Здравствуйте, Sinix, Вы писали:

S>>>5. Threat warnings as errors.
AVK>>Это уже перебор.
S>Вот я сейчас работаю на проекте, на котором это не было сделано с самого начала. С варнингами в итоге никто не борется, потому что они есть даже в автосгенерированном коде. Количество сам можешь представить.
S>Поэтому только как errors, подавлять прагмой — её хоть найти можно.

Возможен компромисс. Если мы делаем два проекта, то в главном можно сделать всё по жёстче.

S>По названию — FlockLib пойдёт. Хотя бы не похоже на выхлоп генератора. Хотя CatHerd тоже ничего будет, отражает суть проекта. И реклама готовая есть,

Какие-то невнятные названия.

S>7. Нужно с самого начала определиться с тестами. Предлагаю требовать только тесты с сценариями использования, складывать их в отдельную папку (UseCases и назвать), остальное — добровольное, в папку Tests.

Запутаемся. Думаю одного проекта Tests хватит за глаза.

S>Тесты — любые, которые поддерживает appveyor, я бы взял xUnit, хотя бы из-за xBehave или fixie.

Я бы взял новый NUnit 3. Там всё переработано и сделано очень неплохо, особенно с параметризированными тестами.

Здравствуйте, Doc, Вы писали:

Doc>А это все планируется как единая библиотека (1 пакет NuGet) или же с разделением по темам (ну там lib.Strings , lib.XDoc и т.д.)

Это слишком мелкое дробление. Если что-то выделять в отдельные модули, то, например, связанное с ASP.NET или WCF. Т.е. то, что требует дополнительных зависимостей.

Doc>Так же для какого .NET это все планируется делать (или для каких). Я как про мин. версию, так и тип.

Совершенно не проблема сделать для чего угодно включая сильверлайт и телефон.

Здравствуйте, Doc, Вы писали:

Doc>4.5.2 как минимально поддерживаемый это мне кажется разумным. Но вот не ограничит ли это область использования?

Для тех задач которые здесь обозначили не вижу проблем сделать это всё хоть для 4.0. А нугетов можно наплодить хоть для каждой версии отдельно.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Ну и с С++ ситуация сильно другая,
EP>>И чем она сильно другая?
AVK>Крайне бедная стандартная библиотека,

И как это меняет сабжевую ситуацию?

AVK>сам язык плохо приспособлен для написания широко используемых библиотек,

Почему?

AVK>много извратов с метапрограммированием на шаблонах.

В Boost есть в том числе и мета-библиотеки. Как это меняет сабжевую ситуацию? Метапрограммирование здесь вообще ортогонально

EP>> Тематика сабжа будет уже?
AVK>Наоборот шире. Но никаких планов по включению туда специализированных вещей типа того же spirit нет.

Так уже или шире?

Если шире — то в каких направлениях?

AVK>Есть вполне конкретная потребность обобщения вещей, которые используются часто и во многих проектах, т.е. самого универсального кода.

То есть только универсальный код? Значит всё таки уже чем Boost? (в котором в том числе есть и не очень часто используемые библиотеки типа Odeint)

EP>>Да, тоже вариант, только экспериментальная часть должна быть доступна в том числе в виде пакета, должны прогоняться минимальные тесты и т.п. — то есть не просто experimental repo.
AVK>Разумеется.

Ещё хотелось бы знать какие компоненты и как часто используются. Как бы собрать такую статистику? Может косвенным способом через обращение к страницам документации?

Здравствуйте, AndrewVK, Вы писали:

Хочу (к уже ранее написанному):
1) Алгоритмы LowerBound/UpperBound на массивах и list'ах.
2) Коллекцию Disjoint Sets.
3) Хелпер для дампа куска массива байтов в строку (что-то типа .ToHexString(this byte[] array, int offset, int length)) — бывает полезно для отладочных дампов всякого протокольного обмена.

Могу поучаствовать (https://github.com/Lexey).

Здравствуйте, Sinix, Вы писали:

S>xBehave — красивая штука для короткой записи тестов. Вместо простыни методов достаточно одного основного. Построен повер xunit

Не понял в чём прикол. Для устранения простыни достаточно параметризированных тестов. В NUnit такого полно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ну значит xUnit

Да ну его нафиг. Его R# поддерживает?

Здравствуйте, Sinix, Вы писали:

S>Все варианты делают одно и то же, но вариант D самый читабельный, т.к. во-первых не требует скакать взглядом назад, во-вторых, не путается с IsNullOrEmpty() как C.

Скорее всего имеется ввиду, что граммитически Not здесь относится только Null.

Здравствуйте, AndrewVK, Вы писали:

AVK>По поводу студии и языка (не фреймворка!) — ограничиваемся 2013/5.0 или все таки 2015/6.0?

Однозначно 2015/6.0. Код генерируется вплоть до FW 2.0, так что никаких проблем.

Здравствуйте, Lexey, Вы писали:

L>Хочу (к уже ранее написанному):
L>1) Алгоритмы LowerBound/UpperBound

+ std::equal_range, + самый универсальный вариант std::partition_point:

template< class ForwardIt, class UnaryPredicate >
ForwardIt partition_point( ForwardIt first, ForwardIt last, UnaryPredicate p );

L>на массивах и list'ах.

Бинарный поиск работает и на Forward Range типа односвязных списков (профит в том что количество сравнений логарифмическое)

Здравствуйте, IT, Вы писали:

Doc>>А это все планируется как единая библиотека (1 пакет NuGet) или же с разделением по темам (ну там lib.Strings , lib.XDoc и т.д.)
IT>Это слишком мелкое дробление. Если что-то выделять в отдельные модули, то, например, связанное с ASP.NET или WCF. Т.е. то, что требует дополнительных зависимостей.

Это для примера. В любом случае, иметь одну сборку, которая будет содержать код "на все случаи жизни" не очень хочется. Ну и по зависимостям в том числе.

Здравствуйте, IT, Вы писали:

AVK>>Ну значит xUnit
IT>Да ну его нафиг. Его R# поддерживает?

Билды с Core вроде нет, для обычных — есть расширение R#. Кроме этого какие аргументы против (за были удобство использования и то, что сами MS его используют вместо MS Test).

Здравствуйте, Doc, Вы писали:

Doc>Это для примера. В любом случае, иметь одну сборку, которая будет содержать код "на все случаи жизни" не очень хочется. Ну и по зависимостям в том числе.

Я бы остановился пока на зависимостях.

Здравствуйте, Doc, Вы писали:

IT>>Да ну его нафиг. Его R# поддерживает?

Doc>Билды с Core вроде нет, для обычных — есть расширение R#. Кроме этого какие аргументы против (за были удобство использования и то, что сами MS его используют вместо MS Test).

За NUnit

— промышленный стандарт
— развитая, легко кастомизируемая система поддержки параметризированых тестов, для наших задач самое оно
— поддержка R# из коробки
— суперактивная работа над проектом в настоящее время, думаю, что сейчас можно попросить любых ништяков
— поддержка консольного режима запуска, что может быть полезно при автоматических билдах

Против xUnit главным образом R# и по опыту его использования всё у них там как-то из стороны в сторону. Что касается использования самим MS, то создаётся впечатление, что крому MS оно больше особо никому не нужно.

Здравствуйте, IT, Вы писали:

AVK>>Это уже перебор.
IT>Почему?

Мне, как человеку, испорченному решарпером хватает его подсказок, чтобы держать проект более менее чистым.