Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Я вот не думаю что авторы того кода неквалифицированны в C#, тем более там не один человек участвует. И исхожу из этого. EP>>>Если ты считаешь что они сделали какой-то ужас, то создай тему в соответствующем под-форуме с указанием на недостатки S>> Это ты считаешь. Мне все равно. Каждый сам решает, что и как. Но это не значит, что с точки зрения выразительности это хорошо.
EP>Так о том и речь что плохо
Но это не говорит о том, что С++ значительно выразительнее C#.
EP>>>>>Непонятно зачем ты патаешься оправдать раздутую реализацию алгоритма (простейшего!) лямбдами, впрочем мне это уже надоело. S>>>> Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше. EP>>>Какую конкретно реализацию? S>> Хотошо. Напомню.https://rsdn.ru/forum/philosophy/6489023.1
template<class ForwardIt>
ForwardIt max_element(ForwardIt first, ForwardIt last)
{
if (first == last) {
return last;
}
ForwardIt largest = first;
++first;
for (; first != last; ++first) {
if (*largest < *first) {
largest = first;
}
}
return largest;
}
Если сюда добавить фильтр на null, селектор для значения, компаратор, тo это мало будет отличаться от варианта по которому ты считаешь, что С++ значительно выразительнее.
Ну и разница, что в С++ итераторы это структуры, а на C# энумераторы это классы.
public static TSource MinItem<TSource, TValue>(
[NotNull, InstantHandle] this IEnumerable<TSource> source,
[NotNull, InstantHandle] Func<TSource, TValue> selector,
[CanBeNull] IComparer<TValue> comparer)
{
if (source == null) throw new ArgumentNullException(nameof(source));
if (selector == null) throw new ArgumentNullException(nameof(selector));
if (comparer == null)
comparer = Comparer<TValue>.Default;
var value = default(TValue);
var item = default(TSource);
// Ветка для нуллаблеif (value == null)
{
using (var e = source.GetEnumerator())
{
do
{
if (!e.MoveNext())
return item;
value = selector(e.Current);
item = e.Current;
}
while (value == null);
while (e.MoveNext())
{
var x = selector(e.Current);
if (x != null && comparer.Compare(x, value) < 0)
{
value = x;
item = e.Current;
}
}
}
}
else// Ветка для валуе типов аналогичной С++
// Можно просто применить foreach было бы то же само как и на С++
{
using (var e = source.GetEnumerator())
{
if (!e.MoveNext())
throw NoElementsException();
value = selector(e.Current);
item = e.Current;
while (e.MoveNext())
{
var x = selector(e.Current);
if (comparer.Compare(x, value) < 0)
{
value = x;
item = e.Current;
}
}
}
}
return item;
}
Но на этом делать вывод, что
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Для сравнения C#, свежий пример — на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
даже в данном варианте на C# 30 строк. При этом используя foreach можно сокаратить до С++ кода. Но даже этот вариант меньше чем ты нашел где то сотни строк.
Я кстати извинился за 2 раза. Жду от тебя извинений за несколько сотен строк.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>>> Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше. EP>>>>Какую конкретно реализацию? S>>> Хотошо. Напомню.https://rsdn.ru/forum/philosophy/6489023.1
Вообще-то нет, например у меня был ещё и selector.
S> Если сюда добавить фильтр на null
В том-то и дело что не нужно сюда добавлять фильтр на null — как и любой другой фильтр он реализуется ортогонально. Его добавили из-за проблем самого C#.
И я тебе уже это говорил в другой теме. Теперь ты и эту зафлудил
S> даже в данном варианте на C# 30 строк. При этом используя foreach можно сокаратить до С++ кода. Но даже этот вариант меньше чем ты нашел где то сотни строк. S> Я кстати извинился за 2 раза. Жду от тебя извинений за несколько сотен строк.
Ты нормальный? С чего мне перед тобой извинятся? Может я оклеветал тебя? Так покажи.
Вариант на сотни строк до сих пор лежит у них в репозитории. Если думаешь что они как-то неправильно закодировали — иди в соответствующий под-форум.
Re[168]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Ikemefula, Вы писали:
I>>>linq2db — не надо. А sqlpp — надо. Это полуфабрикат, он не является ни OR/M ни слоем абстракции, так утверждает его автор, поддерживает три с половиной БД. Следовательно — надо погружаться в дикие извраты, хотя бы для поддержки Оракла или DB2. EP>>1. В данном контексте речь идёт про проекции, а не про конкретно sqlpp11. I>"Точно также как ему не нужно знать например детали компиляции мэппинга внутри linq2db, и остальные десятки тысяч строк" I>Не надо знать — потому что Linq2Db все заявленое умеет и все нужные базы тоже умеет. А если вдруг он начнет ровно три с половиной базы поддерживать, то каждому юзеру придется полностью раздраконить не только маппинг, но и вообще всё.
Учу читать:
EP>1. В данном контексте речь идёт про проекции, а не про конкретно sqlpp11.
EP>2. Даже если брать sqlpp11 с его проекциями, то отсутствие поддержки Oracle вообще параллельно тому получится ли у конечно пользователя использовать проекции на других базах. Это очередное передёргивание с твоей стороны
Re[167]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>>>> Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше. EP>>>>>Какую конкретно реализацию? S>>>> Хотошо. Напомню.https://rsdn.ru/forum/philosophy/6489023.1
S>>>>Или ты её не видел? EP>>>А, так ты под реализацией имеешь в виду вызов готового алгоритма? S>>То, что ты показал это реализация на S>>http://ru.cppreference.com/w/cpp/algorithm/max_element
EP>Вообще-то нет, например у меня был ещё и selector.
У S>> Если сюда добавить фильтр на null
EP>В том-то и дело что не нужно сюда добавлять фильтр на null — как и любой другой фильтр он реализуется ортогонально. Его добавили из-за проблем самого C#.
Дааааа? Приведу пример работы с базами данных. Там null это повсеместное явление при соединениях.
Это как раз проблемы С++. EP>И я тебе уже это говорил в другой теме. Теперь ты и эту зафлудил
Я жду от тебя извинений за твои слова о том. S>> даже в данном варианте на C# 30 строк. При этом используя foreach можно сокаратить до С++ кода. Но даже этот вариант меньше чем ты нашел где то сотни строк.
S>> Я кстати извинился за 2 раза. Жду от тебя извинений за несколько сотен строк.
EP>Ты нормальный? С чего мне перед тобой извинятся? Может я оклеветал тебя? Так покажи. EP>Вариант на сотни строк до сих пор лежит у них в репозитории. Если думаешь что они как-то неправильно закодировали — иди в соответствующий под-форум.
Где я тебе показал на 30 строк. При этом вариант на C++ при сравнении на null будет аналогичным.
Я думаю о том, что ты не знаешь C#, но делаешь свои умозаключения на коде, в котором ничего не понимаешь. И то, что данный алгоритм можно решить так же как и на С++.
В библиотеке std тысячи строк. И что с того?
Для примера покажу вариант на давай рассмотрим вариант std без селектора и компаратора.
Можешь сам добавить и посчитаем, сколько строк. Еще раз при работе с БД null это нормальное явление при левых соединениях
template<class ForwardIt>
ForwardIt max_element(ForwardIt first, ForwardIt last)
{
if (first == last) {
return last;
}
ForwardIt largest = first;
++first;
for (; first != last; ++first) {
if (*largest < *first) {
largest = first;
}
}
return largest;
}
// Но вот их вариант но с компаратором, и селектором
using (var e = source.GetEnumerator())
{
if (!e.MoveNext())
throw NoElementsException();
item = e.Current;
value = selector(item);
while (e.MoveNext())
{
var x = selector(e.Current);
if (comparer.Compare(x, value) < 0)
{
value = x;
item = e.Current;
}
}
}
return item;
И где же это существенная алгоритмическая выразительность?
Мало того, по мне, так для многих арифметика указателей многим не понятна (я её прекрасно понимаю и она мне нравится)
Для обычного программиста код на C# просто понятнее
Другое дело, что для расширений нужно брать Linq и не парится с ручной работой с итераторами.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>>>Ты ни разу не объяснил, почему оптимизацию под платформу надо записывать в алгоритмическую выразительность. EP>>Потому что это реальный код, написанный из вполне практических соображений. I>Следовательно, если я напишу на С++ тот же код из десяти тысяч строк, это и будет доказательством более худшей алгоритмической выразительности языка С++.
Если у тебя будут какие-то номинальные алгоритмические познания, и ты напилишь десять тысяч строк для поиска минимального элемента из каких-то реальных практических соображений, а не исключительно ради раздувания кода — тогда и поговорим.
EP>>Нет, очевидно не на этот. Толку-то от минимально работающей если она не устраивает по разным параметрам? I>Что бы оценивать свойства компилятора отдельно от свойств платформу и все это отдельно от свойств языка.
А зачем их все отдельно оценивать? Как будто в случае C# есть какой-то реальный выбор их на что-то заменить.
Есть задача реализовать алгоритм под реальную практическую задачу, при реализации приходится делать много лишних движений, повторятся, генерировать код как текст и т.п. — это плохо, а из-за чего конкретно плохо — дело десятое, так как нет реальной альтернативы для замены
Re[168]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Serginio1, Вы писали:
S>>> Если сюда добавить фильтр на null EP>>В том-то и дело что не нужно сюда добавлять фильтр на null — как и любой другой фильтр он реализуется ортогонально. Его добавили из-за проблем самого C#. S> Дааааа? Приведу пример работы с базами данных. Там null это повсеместное явление при соединениях. S> Это как раз проблемы С++.
Я не говорю что не нужно фильтровать. Я говорю что фильтрацию не нужно встраивать в алгоритм поиска минимального элемента — это ортогонально.
Вот представить что тебе нужно отфильтровать не null, а все чётные — будешь писать отдельный алгоритм min_odd_element?
S>Я думаю о том, что ты не знаешь C#, но делаешь свои умозаключения на коде, в котором ничего не понимаешь.
Всё, надоел, по несколько раз одно и то же
Re[169]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>> Если сюда добавить фильтр на null EP>>>В том-то и дело что не нужно сюда добавлять фильтр на null — как и любой другой фильтр он реализуется ортогонально. Его добавили из-за проблем самого C#. S>> Дааааа? Приведу пример работы с базами данных. Там null это повсеместное явление при соединениях. S>> Это как раз проблемы С++.
EP>Я не говорю что не нужно фильтровать. Я говорю что фильтрацию не нужно встраивать в алгоритм поиска минимального элемента — это ортогонально. EP>Вот представить что тебе нужно отфильтровать не null, а все чётные — будешь писать отдельный алгоритм min_odd_element?
Еще раз для я тебе показал алгоритм на Linq. Но он состоит из 4 строк. Если часто используешь, то стоит сделать алгоритм из 10
строк, что бы использовать одну. S>>Я думаю о том, что ты не знаешь C#, но делаешь свои умозаключения на коде, в котором ничего не понимаешь.
EP>Всё, надоел, по несколько раз одно и то же
Правильно ты не можешь согласиться с тем, что не прав.
Ты сделал вывод на выразительности на основании того, что ктото ипользовал алгоритм поиска вручную. Тебе привели пример как можно использовать Linq https://rsdn.ru/forum/flame.comp/6497123.1
А, так ты под реализацией имеешь в виду вызов готового алгоритма?
При этом ты то при твои утвеждения, что считаешь, что они верны
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Для сравнения C#, свежий пример
— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
Ещё ДО отрабатывания T4, кода на C# больше, и его труднее поддерживать, ибо это склейка кода как текста.
А на то, что тебе приводят код на Linq более лаконичный тебе глубоко плевать. Но при этом будет 2 прохода.
Ребята решили оптимизировать и сделали за один проход. Другое дело, что фильтр оптимизирован и нужно было использовать только один проход с фильтром на Nullable типы
Надо признавать ошибки. И доказвать там, где хорошо знаешь область. От того, что ты прекрасно знаешь С++, не говорит, что ты автоматом разбираешься в C++ или 1С.
и солнце б утром не вставало, когда бы не было меня
IT>>Дайте паттерн матчинг в C# и отжать всё лишнее из генерируемого SQL вообще будет не проблема. EP>В C++ кстати есть PM для expression templates, причём аж в C++1998. То есть можно отматчить искомый фрагмент дерева запроса, и провести оптимизацию, или например выдать ошибку. EP>Я уже показывал
Эта перегрузка разбирает внутренний запрос, делает внутренний FROM внешним, и склеивает условия, после чего уходит в рекурсию.
При наличии такой перегрузки генерируемый запрос приобретает вид:
SELECT foo.id FROM foo WHERE foo.id>42 AND foo.id>41 AND foo.id>40
Паттерн естественно может быть и более "многоэтажным", для более глубокого матчинга по дереву выражения.
Re[167]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Нет, очевидно не на этот. Толку-то от минимально работающей если она не устраивает по разным параметрам? I>>Что бы оценивать свойства компилятора отдельно от свойств платформу и все это отдельно от свойств языка.
EP>А зачем их все отдельно оценивать? Как будто в случае C# есть какой-то реальный выбор их на что-то заменить.
Для того, что бы знать, что именно и как надо улучшать — в языке, а плафтформе, в программе, библиотеке.
Если проблема в языке — меняем язык, проверяем. Опаньки — ровно та же проблема и в С++ .Net. И в F# и вообще в любом доступном языке на этой платформе.
Язык поменяли, пробелема осталась — гы-гы. Это про твою логику
Отсюда ясно, что смотреть надо или в либы, или в программу, или платформу. Если в программе нельзя соптимизировать, другого алгоритма в библиотеке нет, то надо пробовать другую платформу — заюзать нативный код.
А если думать, как ты — "выхода нет, всё пропало", остаётся только голову пеплом посыпать.
EP>Есть задача реализовать алгоритм под реальную практическую задачу, при реализации приходится делать много лишних движений, повторятся, генерировать код как текст и т.п. — это плохо,
А что плохо ? Код писать твоя работа. А вот экономический эффект и показывает, что хорошо, а что плохо.
И вот здесь оказывается, что весь такой плохой С# убрал хороший С++ со сцены. С выходом C# почти все виндовые сиплюсники перешли на С#. Именно экономика и говорит, что плохо, а количество строчек — это вообще дело десятое.
> а из-за чего конкретно плохо — дело десятое, так как нет реальной альтернативы для замены
Эти проблемы есть вообще во всех языках на платформе .Net, даже С++ будет обладать теми же недостатками — он будет много медленнее нативного. Джит никогда не сможет справиться с обычным компилятором.
То есть, ты продолжаешь сравнивать разные платформы, но при этом цепляешься к конкретному языку.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>В C++ кстати есть PM для expression templates, причём аж в C++1998. То есть можно отматчить искомый фрагмент дерева запроса, и провести оптимизацию, или например выдать ошибку.
... EP>Паттерн естественно может быть и более "многоэтажным", для более глубокого матчинга по дереву выражения.
Теперь повтори этот же фокус для динамического запроса.
Re[168]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ikemefula, Вы писали:
I>Эти проблемы есть вообще во всех языках на платформе .Net, даже С++ будет обладать теми же недостатками — он будет много медленнее нативного. Джит никогда не сможет справиться с обычным компилятором.
Как .NET Native повлияет на меня и мое приложение?
Конкретные показатели могут отличаться, но в большинстве случаев ваше приложение будет запускаться быстрее, работать с большей скоростью и потреблять меньше системных ресурсов.
•До 60% повышения скорости холодного старта
•До 40% повышения скорости горячего старта
•Уменьшенное потребление памяти при компиляции в машинный код
•Нет зависимости от десктопного .NET Runtime при установке
Так как ваше приложение скомпилировано в машинный код, вы получите прирост производительности, связанный со скоростью выполнения нативного кода (близко к производительности C++). При этом вы по-прежнему можете пользоваться преимуществами индустриальных языков программирования C# или VB и связанных инструментов.
Вы также можете продолжать использовать всю мощь программной модели, доступной в .NET с широким набором API для описания бизнес-логики и со встроенными механизмами управления памятью и обработки исключений.
Другими словами, вы получаете лучшее из обоих миров: управляемая разработка с производительностью близкой к С++. Это ли не прекрасно?
Правда при этом теряется возможность огульной рефлексии ну и разного рода ограничения.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вот представить что тебе нужно отфильтровать не null, а все чётные — будешь писать отдельный алгоритм min_odd_element?
Вот только в обсуждаемом алгоритме не фильтрация null, а особое поведение основного алгоритма в случае null.
Re[170]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Вот представить что тебе нужно отфильтровать не null, а все чётные — будешь писать отдельный алгоритм min_odd_element? НС>Вот только в обсуждаемом алгоритме не фильтрация null, а особое поведение основного алгоритма в случае null.
1. Это особое поведение ортогонально алгоритму и выносится за скобки, в том числе с помощью фильтрации, а не копипастится.
2. Сама необходимость какой-то особой семантики в зависимости от рода типа
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>3. Исключение для индикации "NoElements" на алгоритме такого уровня — тоже жесть.
Ты просто, как обычно, не в теме. Min/MaxBy копирует семантику Min/Max, а она, в свою очередь, такая и для коллекций, и для доступа в БД. Вот последнее как раз и является причиной не совсем очевидного на первый взгляд поведения.
Re[172]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>3. Исключение для индикации "NoElements" на алгоритме такого уровня — тоже жесть. НС>Ты просто, как обычно, не в теме.
.
НС>Min/MaxBy копирует семантику Min/Max, а она, в свою очередь, такая и для коллекций, и для доступа в БД. Вот последнее как раз и является причиной не совсем очевидного на первый взгляд поведения.
Причины могут быть какие угодные. Я же например не говорю что авторы в рамках языка/платформы неправильно поступили. Я говорю что плох тот языка/платформа на которых необходимы такие извраты для простейших алгоритмов
Re[168]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ikemefula, Вы писали:
EP>>Есть задача реализовать алгоритм под реальную практическую задачу, при реализации приходится делать много лишних движений, повторятся, генерировать код как текст и т.п. — это плохо, I>А что плохо ? Код писать твоя работа.
Конечно плохо, но некоторые действительно так и пишут целые простыни, от забора и до обеда
I>А вот экономический эффект и показывает, что хорошо, а что плохо.
Это уже передёргивание с алгоритмической выразительности на сферический экономический эффект.
Re[173]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Причины могут быть какие угодные. Я же например не говорю что авторы в рамках языка/платформы неправильно поступили. Я говорю что плох тот языка/платформа на которых необходимы такие извраты для простейших алгоритмов
Извраты необходимы не из-за платформы/языка, а из-за предметной области — БД. А вот то что ты все вывернул опять на изнанку демонстрирует, что правда тебе не интересна, тебе интересны исключительно твои теории.
Re[174]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Причины могут быть какие угодные. Я же например не говорю что авторы в рамках языка/платформы неправильно поступили. Я говорю что плох тот языка/платформа на которых необходимы такие извраты для простейших алгоритмов НС>Извраты необходимы не из-за платформы/языка, а из-за предметной области — БД.
Например вот это дублирование — 1, 2 — из-за БД? А может быть вот этот мрак из-за БД?
НС>что правда тебе не интересна
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>>Причины могут быть какие угодные. Я же например не говорю что авторы в рамках языка/платформы неправильно поступили. Я говорю что плох тот языка/платформа на которых необходимы такие извраты для простейших алгоритмов НС>>Извраты необходимы не из-за платформы/языка, а из-за предметной области — БД.
EP>Например вот это дублирование — 1, 2 — из-за БД? А может быть вот этот мрак из-за БД?
Вообще это пишется без дублей
public static TSource MinBy<TSource, TValue>(
[NotNull, InstantHandle] this IEnumerable<TSource> source,
[NotNull, InstantHandle] Func<TSource, TValue> selector,
[CanBeNull] IComparer<TValue> comparer)
{
Code.NotNull(source, nameof(source));
Code.NotNull(selector, nameof(selector));
if (comparer == null)
comparer = Comparer<TValue>.Default;
var value = default(TValue);
TSource item;
// просто добавляем фильтр, он ленивый и будет вызываться во время итерацииif (value == null)
source=source.Where(x=>x!=null);
using (var e = source.GetEnumerator())
{
if (!e.MoveNext())
{
// по их алгоритму при пустом списке вызвать исключение для Nullableif (value == null)
throw NoElementsException();
else
return default(TSource); // вернуть default при пустом списке
}
value = selector(e.Current);
item = e.Current;
while (e.MoveNext())
{
var x = selector(e.Current);
if (comparer.Compare(x, value) < 0)
{
value = x;
item = e.Current;
}
}
}
return item;
}
Проблема не в языке. Напиши этот же алгоритм для C++ и мы сравним 100 раз о которых ты декларируешь.
И не смейся а доказывай свои слова.
на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
Можно подумать ты никогда не занимался копи-пасте?
Можно переписать на foreach
if (value == null)
source=source.Where(x=>x!=null);
bool isfirst=true;
bool fl=0;
foreach(var item in source)
{
var x = selector(item );
if (isFirst)
{
isFirst=false;
fl=-1;
}
else
fl=comparer.Compare(item, value);
if (fl< 0)
{
value = x;
item = e.Current;
}
}
if (isFirst)
{
// по их алгоритму при пустом списке вызвать исключение для Nullableif (value == null)
throw NoElementsException();
else
r eturn default(TSource); // вернуть default при пустом списке
}
return item;
Это не проблема платформы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например вот это дублирование — 1, 2 — из-за БД?
Глупо задавать вопросы, на которые тебе давно уже дали ответы. Это дублирование из-за того, что для ref-типов есть выделенное значение null, а для value его нету.
EP> А может быть вот этот мрак из-за БД?
А это для лучшего перформанса. Можно смело грохнуть весь этот файл, и все приложения, использующие методы оттуда продолжат успешно компилироваться и работать.
Ну и вообще — это тот самый код, который пишется в универсальных библиотеках и почти не пишется в прикладном коде. Но аналогичная ситуация с чудовищной кашей в твоей шаблонной магии тебя почему то устраивает, а тут прям какая то вселенская проблема и ужас ужас.
