Очень спорное утверждение, вот я за более 10 лет программирования на C# использовал метод Aggregate может раза 2 от силы. Вместо Aggregate обычно проходитесь по перечислению через foreach и днлаете любые преобразования и аггрегируете как хотите
Вообще считаю, что вопросы на теоретические вопросы можно задать разве что джуну, у мидла и выше можно спросить про интересные проблемы с которыми столкнулся, как бы он решил ту или иную реальную проблему. Такое как правило не гуглят пока не столкнутся, но если решил, то сам принцип решения явно запомнишь. Проблемы в отрасли как правило похожи так, что по таким вопросам можно понять докуда дорос соискатель
С начала СВО многие улетели из России и не спешат вернуться, опасаясь мобилизации, многие из них неплохие специалисты. Так что некоторые проблемы с "появиться лично" всё таки могут быть
Ещё один момент в том, что вы преобразовываете число с большим количеством бит в число с меньшим количеством бит, то есть возможна потеря информации, в C# int можно преобразовать к long неявно, но вот long к int только явно
Но в конретом коде в статье это проблема, так как есть риск исключения при присваивании, что ну уж совсем не ожидаемо, всё таки метод Parse делает это прозрачным, что вот тут произойдёт преобразование одних данных в другие и есть некоторая логика этого преобразования, неявное преобразование тут подошло бы если бы не было бизнес логики, например у нас есть просто метод обёртка, который через констуктор поместит входные данные во внутреннее поле и всё, например это хорошо работает с Nullable. Ну и ещё аргумент против неявного привеления в том, что многие C# программисты, как и я, любят объявлять переменные через var и очень редко пишут тип вне объявленя параметров, свойств или полей
Выбрасывание исключений в констукторе не самое ожидаемое поведение, неявное приведение типов хоть и выглядит интересно, но лучше его не использовать, так как от пользователя вашего класса требуется знать об этом поведении. Вместо этого можно воспользоваться проверенным способом, использовать методы Parse и TryParse, они просты, понятны большинству разработчиков, не выглядят инородно. Для того чтобы исключить возможность создать экземпляр с не валидным значением, вы можете пометить конструктор private
public readonly struct SevenBitNumber
{
public byte Value { get; }
private SevenBitNumber(byte value)
{
Value = value;
}
public bool TryParse(byte value, out SevenBitNumber sevenBitNumber)
{
if (value > 127)
{
sevenBitNumber = default;
return false;
}
sevenBitNumber = new SevenBitNumber(value);
return true;
}
public SevenBitNumber Parse(byte value)
{
if (TryParse(value, out var sevenBitNumber))
{
return sevenBitNumber;
}
throw new ArgumentOutOfRangeException(nameof(value), value, "Value is out of range for seven-bit number");
}
}
Как ни странно в корпоративной разработке забыть что-то задокументировать гораздо проще. И стандарты качества PosgreSQL выше, чем у подавляющего количества ПО в принципе. Данная фича не просто была залита каким то разработчиком сразу в мастер и забыла, нет, она прошла несколько ревью и была включена в релиз.
Думаю что разработчики, когда выкатывают фичи, тоже делают бенчмарки, если окажется, что новый метод предпочтительнее, то это непременно отобразят в документации, мой посыл был в этом. Сейчас ощущение такое, что разработчики сделали фичи, которые могли бы ускорить работу в некоторых случаях, но по результатам замеров, не готовы пока выносить это в документацию, чтобы пользователи начали переходить на эту фичу.
Если речь о utf8 то есть смысл сравнить с https://github.com/neuecc/Utf8Json там много оптимизаций именно под utf8, к сожалению проект в архиве, но сами подходы там интересные
Выглядит так, что нет упоминаний в документации, потому что и смысла нет, LIKE, о котором все знают быстрее всех, кажется если что-то будет работать быстрее, то и упоминание в документации появится
Скорее Сашечка, тут более умилительный окрас как и у тян, Сашка же скорее пренебрежительно-простонародное, кажется такого суффикса в японском нет, есть суффикс сан но это скорее Саша, у нас так можно, например, коллегу по работе называть
Очень спорное утверждение, вот я за более 10 лет программирования на C# использовал метод Aggregate может раза 2 от силы. Вместо Aggregate обычно проходитесь по перечислению через foreach и днлаете любые преобразования и аггрегируете как хотите
Вообще считаю, что вопросы на теоретические вопросы можно задать разве что джуну, у мидла и выше можно спросить про интересные проблемы с которыми столкнулся, как бы он решил ту или иную реальную проблему. Такое как правило не гуглят пока не столкнутся, но если решил, то сам принцип решения явно запомнишь. Проблемы в отрасли как правило похожи так, что по таким вопросам можно понять докуда дорос соискатель
С начала СВО многие улетели из России и не спешат вернуться, опасаясь мобилизации, многие из них неплохие специалисты. Так что некоторые проблемы с "появиться лично" всё таки могут быть
Может у него куча детей и жена требует алименты
Ещё один момент в том, что вы преобразовываете число с большим количеством бит в число с меньшим количеством бит, то есть возможна потеря информации, в C# int можно преобразовать к long неявно, но вот long к int только явно
Но в конретом коде в статье это проблема, так как есть риск исключения при присваивании, что ну уж совсем не ожидаемо, всё таки метод Parse делает это прозрачным, что вот тут произойдёт преобразование одних данных в другие и есть некоторая логика этого преобразования, неявное преобразование тут подошло бы если бы не было бизнес логики, например у нас есть просто метод обёртка, который через констуктор поместит входные данные во внутреннее поле и всё, например это хорошо работает с Nullable. Ну и ещё аргумент против неявного привеления в том, что многие C# программисты, как и я, любят объявлять переменные через var и очень редко пишут тип вне объявленя параметров, свойств или полей
Выбрасывание исключений в констукторе не самое ожидаемое поведение, неявное приведение типов хоть и выглядит интересно, но лучше его не использовать, так как от пользователя вашего класса требуется знать об этом поведении. Вместо этого можно воспользоваться проверенным способом, использовать методы Parse и TryParse, они просты, понятны большинству разработчиков, не выглядят инородно. Для того чтобы исключить возможность создать экземпляр с не валидным значением, вы можете пометить конструктор private
Как ни странно в корпоративной разработке забыть что-то задокументировать гораздо проще. И стандарты качества PosgreSQL выше, чем у подавляющего количества ПО в принципе. Данная фича не просто была залита каким то разработчиком сразу в мастер и забыла, нет, она прошла несколько ревью и была включена в релиз.
Думаю что разработчики, когда выкатывают фичи, тоже делают бенчмарки, если окажется, что новый метод предпочтительнее, то это непременно отобразят в документации, мой посыл был в этом. Сейчас ощущение такое, что разработчики сделали фичи, которые могли бы ускорить работу в некоторых случаях, но по результатам замеров, не готовы пока выносить это в документацию, чтобы пользователи начали переходить на эту фичу.
Если речь о utf8 то есть смысл сравнить с https://github.com/neuecc/Utf8Json там много оптимизаций именно под utf8, к сожалению проект в архиве, но сами подходы там интересные
Выглядит так, что нет упоминаний в документации, потому что и смысла нет, LIKE, о котором все знают быстрее всех, кажется если что-то будет работать быстрее, то и упоминание в документации появится
WinRar тоже денег просил, но никого это не останавливало
Через стримы итак все умеют, лучше бы рассказали как это правильно через Pipe делать
D?
так в D вроде тоже есть, как я понимаю типа этого? https://wiki.dlang.org/DIP50
А ещё есть это https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md что позволяет писать код без сборщика мусора гарантируя освобождение ресурсов
так в D вроде тоже есть, как я понимаю типа этого? https://wiki.dlang.org/DIP50
Скорее Сашечка, тут более умилительный окрас как и у тян, Сашка же скорее пренебрежительно-простонародное, кажется такого суффикса в японском нет, есть суффикс сан но это скорее Саша, у нас так можно, например, коллегу по работе называть
Страница не найдена
Страница устарела, была удалена или не существовала вовсе
Звучит интересно, а можете подсказать какая у вас исходная коллекция? List?
чем zig лучше D?