В новой версии добавлена поддержка обобщённых функций и типов (дженериков), при помощи которых разработчик может определить и использовать функции, предназначенные для работы сразу с несколькими типами. Также предоставлена возможность использования интерфейсов для создания комбинированных типов, охватывающих несколько типов данных. Поддержка дженериков реализована без нарушения обратной совместимости с существующим кодом.
// Суммирование значений набора, работающее для типов int64 и float64
func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V {
var s V
for _, v := range m {
s += v
}
return s
}
// Другой вариант с обобщённым определением типа:
type Number interface {
int64 | float64
}
func SumNumbers[K comparable, V Number](m map[K]V) V {
var s V
for _, v := range m {
s += v
}
return s
}
Насколько я понимаю, там подают на вход любые данные и смотрят, когда тестируемый код упадет.
Можешь объяснить, зачем этот Fuzzing нужен. По мне так это безумный вариант модульного тестирования (Unit testing), который уж точно будет реализован со всеми граничными случаями, до того, как дело дойдет до Фаззинга. Т.е. выглядит как очень нишевая технология, там где нужно особо фанатичное круглосуточное тестирование всеми немыслимыми входными данными.
Но с другой сторны, если это сделали, значит это кому-то нужно (и вряд ли все эти люди совсем неразумны).
Здравствуйте, Reset, Вы писали:
R>Насколько я понимаю, там подают на вход любые данные и смотрят, когда тестируемый код упадет.
R>Можешь объяснить, зачем этот Fuzzing нужен. По мне так это безумный вариант модульного тестирования (Unit testing), который уж точно будет реализован со всеми граничными случаями, до того, как дело дойдет до Фаззинга. Т.е. выглядит как очень нишевая технология, там где нужно особо фанатичное круглосуточное тестирование всеми немыслимыми входными данными.
R>Но с другой сторны, если это сделали, значит это кому-то нужно (и вряд ли все эти люди совсем неразумны).
Не очень понял, почему дело дойдёт до фаззинга только после всех граничных случаев. Суть в том, что не будешь ты тестировать все граничные случаи, тебе лень или у тебя жизнь слишком коротка. А фаззинг будет. И, может быть, найдёт баг. Его же не сложно писать, а польза есть, хотя бы гипотетическая.
В моём понимании он полезен:
1. Там, где критична безопасность. Например парсинг файлов, приходящих извне.
2. Там, где сложная state-машина, которую юнит-тестами покрыть невозможно, слишком много сочетаний.
Здравствуйте, Reset, Вы писали:
vsb>>А ещё они там Fuzzing добавили. Крутой релиз.
R>Насколько я понимаю, там подают на вход любые данные и смотрят, когда тестируемый код упадет.
R>Можешь объяснить, зачем этот Fuzzing нужен. По мне так это безумный вариант модульного тестирования (Unit testing), который уж точно будет реализован со всеми граничными случаями, до того, как дело дойдет до Фаззинга. Т.е. выглядит как очень нишевая технология, там где нужно особо фанатичное круглосуточное тестирование всеми немыслимыми входными данными.
R>Но с другой сторны, если это сделали, значит это кому-то нужно (и вряд ли все эти люди совсем неразумны).
Пошли по пути C++, сейчас начнет обрастать костылями.
— Нет в мире справедливости, — простонал Билл, когда цепкие пальцы Смертвича впились в его плечо.
— Конечно, нет, — согласился Смертвич. — А ты как думал?
Здравствуйте, SkyDance, Вы писали:
R>>Go 1.18 теперь тоже умеет обобщенные типы (generic, C++ templates) как для функций, так и для типов.
SD>Еще 5-7 лет, и Go можно будет отправлять вслед за С++ SD>И так будет с любым языком, который поддерживается не strong leader, а монстро-компанией.
Дженерики довольно толково добавлены. В С++ шаблоны они не вырастут и при этом более полезны, чем java-недодженерики.
