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

Допустим, пользователь ввел List<int>, но такой тип неоптимален, когда есть NList<int>. Аналогично с Convert и NConvert, когда целевой тип - int. При этом на List<string> предупреждение не должно выдаваться, так как тип NList<string> невозможен. Как это можно сделать?

0

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

1

Сообщение от belalugoci я сразу понял )

Нет уважаемый belalugoci, ничего вы не поняли и к сожалению не разобрались.

Сообщение от belalugoci задача как раз решаема и вопрос был по возможностям самого компилятора. Это так же как например использование Dictionary и HashSet, в MSDN указаны варианты использования того или другого, не вижу никакой сложности "увидев" неоптимальный сценарий выдать подсказку. Я вон код набираю и он мне подсказывает что написать, ошибается часто, но проще нажать таб и исправить пару символов чем набирать всю конструкцию

Компилятор ничего не может подсказать во время набора. Вы путаете компилятор со статическим анализатором.

0

0

Сообщение от Etyuhibosecyu можно освободить память моментально, вызвав Marshal.FreeHGlobal(), а в List<T> нужно ждать, пока заведется сборщик мусора.

Что же это за задача такая что скорость освобождения памяти настолько критично?

Сообщение от Etyuhibosecyu а вот сборка мусора - это серьезное преимущество.

Пишите на сях. И руками рулите мусор. Ни разу за всю историю не видел чтобы сборщик не справлялся со своими задачами. А если не справлялся то это ошибка в коде.

0

Сообщение от Etyuhibosecyu о он ВСЕГДА оптимальнее List<T> как минимум по одному признаку: сборке мусора. В NList<T> можно освободить память моментально, вызвав Marshal.FreeHGlobal(), а в List<T> нужно ждать, пока заведется сборщик мусора.

Что? Зачем ждать сборщик мусора? И надо ещё посмотреть, что ты там неуправляемого такого руками высвобождаешь. Есть подозрение, что ты придумал решение проблемы, которую сам же и добавил.

0

про какую речь идет сборка мусора в List<T>
если он не пересоздается и и используется ровно та длина которую мы задали?

0

Сообщение от ZeroKara Компилятор ничего не может подсказать во время набора. Вы путаете компилятор со статическим анализатором

каюсь, я по привычке IDE именую всегда компилятором. Ну что поделать, привык так.

Сообщение от ZeroKara ничего вы не поняли и к сожалению не разобрались

я рад что вы лучше меня знаете что происходит в моей голове.

0

Сообщение от Worldmaster Пишите на сях. И руками рулите мусор.

Я не знаю, что такое "сяхи". Как бы там ни было, давайте не разводить холивар, кому на чем писать. Мне C# удобен.

Сообщение от Worldmaster Ни разу за всю историю не видел чтобы сборщик не справлялся со своими задачами. А если не справлялся то это ошибка в коде.

Сообщение от Usaga Что? Зачем ждать сборщик мусора?

Попробуйте выполнить кучу операций с огромными списками, требующих прохода по коллекции, и таких, которые не покрываются LINQ. Будете в шоке от количества сгенерированного мусора, который еще неизвестно, когда освободится - на слабом компьютере OutOfMemoryException уже наступит.

Сообщение от Usaga И надо ещё посмотреть, что ты там неуправляемого такого руками высвобождаешь.

Смотрите.

0

Сообщение от Etyuhibosecyu Попробуйте выполнить кучу операций с огромными списками, требующих прохода по коллекции, и таких, которые не покрываются LINQ.

Так может тут хромают алгоритмы? Надо может быть продумать алгоритм более правильно и эффективно?
На и помимо List есть более эффективные коллекции.

Сообщение от Etyuhibosecyu что такое "сяхи".

Это тот самый С++ где было принято четко следить за выделяемой памятью и стараться эффективно ее расходовать.

0

Сообщение от Etyuhibosecyu Попробуйте выполнить кучу операций с огромными списками

например

0

Сообщение от Etyuhibosecyu Попробуйте выполнить кучу операций с огромными списками, требующих прохода по коллекции, и таких, которые не покрываются LINQ. Будете в шоке от количества сгенерированного мусора, который еще неизвестно, когда освободится - на слабом компьютере OutOfMemoryException уже наступит.

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

Сообщение от Etyuhibosecyu Смотрите.

Посмотрел. Ты там просто массив руками аллоцируешь и высвобождаешь. Преимущество в чём? Если бы ты хотя бы пытался учебник по C# открыть, то знал бы, что GC управляемые объекты умеет упаковывать, чтобы бороться с фрагментацией. А твоё решение этому тупо мешает, ибо тут уже сырые указатели.

Ты к такому решению пришёл отталкиваясь от тестов или от домыслов, как ты обычно делаешь?

0

Сообщение от Usaga Давай будем исходить из примера такого кода. И попробуем убедиться, что виноват не говнокод, а обстоятельства, требуеющие того, о чём ты говоришь.

Примерно здесь пример такого кода (возможно, чуть выше или ниже). Методы EncodeInts, EncodeBytes, WriteLZ, LZRequisites. Сразу предупреждаю - на количество параметров лучше забить, там точно говнокод. Но если именно операции с коллекциями - говнокод, научите меня, какая альтернатива.

0

Etyuhibosecyu, я не могу сказать, что там происходит. Каша настоящая. Но я вижу твою типичную ошибку - любовь жонглированием коллекциями. Сортировки, преобразования, копирования. Потом снова.

Вот такую строку ещё найди и ответь себе зачем оно, если результат всё равно не используется:
В общем, я вижу типичную для тебя ошибку: совершенно бездумное создание тонн мусора в куче и нежелание использовать отладчик, профилировщик и мозг, чтобы навести порядок. Вместо этого, типичное решение: начать изобретать велосипед, который должен, якобы, волшебным образом твой говнокод оптимально пережёвывать.

Опять виноват Microsoft, что их платформа в твоих руках никак не хочет превращаться в конфетку. Поэтому ты сам решил поиграться в повара.

Вот давай честно, ладно? Ты же не пробовал профилировать и отлаживать эту портянку, да? Не просто запустить инструмент, ничего не понять и закрыть. А именно честно попытаться разобраться. Я вижу, что ответ тут - нет, даже не пытался.

Добавлено через 7 минут
Т.е. более доходчиво перефразирую свою мысль:

Ты уже сам понял примерную проблему того кода: memory pressure (нагрузка мусором на GC). И вместо самого очевидного решения - уменьшения memory pressure - ты опять улетел куда-то в стратосферу и решил сотворить какие-то говноколлекции, которые будут брать на себя часть функций GC вынуждая разработчика везде и всюду пинать Dispose у них...

Ты уверен, что кто-то кроме тебя, носителя Правительских Званий, таким путём пойдёт вместо того, чтобы просто активировать убер-фичу - мозг?

Добавлено через 4 минуты
А дальше больше: выйдя в стратосферу и начав испытывать кислородное голодание, твой мозг выдал следующий вектор движения - вообще в сторону Марса - породить некий анализатор для Visual Studio, который будет стараться советовать твои говноколлекции к месту и не к месту.

Т.е. одно тупое решение, стало отправной точкой для целой цепочки тупых решений.

И опять ты даже не постарался задуматься о том, почему всем хватает стандартных решений (ну, плюс-минус), и только у тебя одного оно работает из рук вон плохо?

0

Сообщение от Worldmaster На и помимо List есть более эффективные коллекции

Подскажите чем будет более эффективно пользоваться для коллекции своего класса, чтобы сохранялся доступ по индексу и динамическое увеличение размера коллекции? (я правда хочу знать так как активно пользуюсь List и хотелось бы понять что есть лучше него)

0

Сообщение от belalugoci чтобы сохранялся доступ по индексу и динамическое увеличение размера коллекции?

Под это только List<T> подпадает.

0

Сообщение от Etyuhibosecyu Допустим, пользователь ввел List<int>, но такой тип неоптимален, когда есть NList<int>

Пару вопросов:
- как насчет (де)сериализации? Тот же System.Text.Json правильно обработает ваш класс?
- как насчет передачи как колекцию в лямда запрос для orm? Всякие даперы и прочие тоже правильно разверну в IN, или выплюнут исключение?

0

Сообщение от Wolfdp Всякие даперы и прочие тоже правильно разверну в IN

Даппер запросы не строит. Он ничего ни во что разворачивать не будет)

0

Сообщение от Usaga Даппер запросы не строит. Он ничего ни во что разворачивать не будет)

Ок, любая ORM которая позволяет древо (или как оно там правильно именуется) из Linq методов преобразовать потом в sql-запрос. Может это пережитки прошлого и сейчас всё что IEnumerable.Contains или Any спокойно проходит, но помню что мне приходилось лист конвертить в массив, потому-что в противном случае ругалось.

На самом деле мысль можно развернуть шире:
- есть общепризнанные коллекции, которые используются в общих (и не очень) библиотеках. С ним всё будет работать близко к 100%
- если мы пишем свои классы-коллекции, то максимум что потом может использоваться -- IEnumerable. В остальных случаях нам постоянно придется перегонять в ToList, ToArray и прочие приключения.

Учитывая что ТС предлагает варнинг или иные уведомления, которые будут постоянно маячить перед глазами там где оно не надо от слова совсем -- идея так себе.

0

Сообщение от Wolfdp IEnumerable.Contains или Any

потому что это like или in

Сообщение от Wolfdp но помню что мне приходилось лист конвертить в массив, потому-что в противном случае ругалось.

20 лет назад?

Сообщение от Wolfdp На самом деле мысль можно развернуть шире:

больше похоже вы сами не знаете как работает linq и IQueryable, либо не работаете с этим

0

Сообщение от Dr9vik больше похоже вы сами не знаете как работает linq и IQueryable, либо не работаете с этим

Я говорю о том, с чем встречался на практике. Доказывать свою (не)правоту сильного желания сейчас нет, можете смело не верить. Банальное использование List<T> вместо T[] уже может давать те или иные аффекты. А это общеупотребляемые коллекции. С кастомной коллекцией приключений скорее всего будет больше. Понятное дело что это будет проявлятся не ежедневно в каждой строчке кода, но с другой стороны -- зачем все эти нежданчики, если есть проверенное решение?

Поэтому если бы мне сказали на проекте, что необходимо всюду использовать самописный NList<T>, то я лично восприниму это в штыки и буду до последнего отвоевывать право использовать более общепринятые подходы. Ибо всяких решений, из-за которых приходится страдать, и без этого хватает.

0