не прокидывание исключения вполне нормальная практика. если проблема решилась локально.
использование исключений в логике тоже вполне допустимо. во-первых если они используются хоть где-то, то инфраструктура для их обработки уже внедрена в приложение. а во-вторых на фоне Qt они тормозить не будут )
Зря вы так. Если заказчик не понимает что можно сделать шустрее, красивее и аккуратнее, то куча уже готовых компонентов и фактор «оно работает» делают свое дело.
Очень даже разворачивают, только чуть более громоздко это будет.
Для большей наглядности, здесь не учтены unicode surrogate code points.
А фреймворк не есть единственно верное решение, кстати что-то мне кажется что энумератор тормозить ужасно будет. Ну примерно как версия с LINQ, по тем же причинам.
Ну вообще-то девайс мелкософтовский был и они почему-то решили выбрать .Net CF :)
Впрочем я не уверен, что девайс для игрушек предназначался, но такова специфика у gamedev индустрии — прикрутить игрушку на все, где ее можно продать :)
глобально — да, нету разницыБ нормальный компилятор развернет одинаково. просто в плюсах "!= 0" писать не надо, получается for (int i = str.Length; i--; ). писал, как привык.
Ну во-первых далеко не любой игровой платформе он есть :)
А во вторых… есть некоторые познания о жизнеспособности .Net CF в условиях ограниченых ресурсов (около 2М памяти, остальное железо тоже на уровне, .Net CF официальная среда), и они не очень позитивные. Впрочем писали же люди… И работало, правда с гайдлайнами .Net в итоге мало общего имело :)
1. Хабр нолик сожрал в условии
2. Стиль, как стиль. На С/С++ сплошь и рядом так пишут, главная польза в единоразовом вычислении str.Length. Ну и потенциальном схлопывании сравнения с нулем в одну операцию целевого процессора, хотя и мелочь второе.
Ну не знаю, в мирах win32 и .Net все оперативные данные хранят в UTF-16, а UTF-8 используется только для ввода-вывода, поэтому замечание к .Net не применимо. А конвертация в обе стороны делается за один проход.
Кстати сложность будет сравнима со сложностью обработки суррогатных пар.
Нее, черный :) Он подключен к кэшам по быстрому каналу и к памяти по медленной шине.
А вот какой логикой он руководствуется при захвате блока памяти мало кому известно. Например высока вероятность, что при линейном чтении большого массива, через пару итераций будет захватываться блок большого размера (тем более что спекулятивное выполнение заглядывает на нексколько инструкций вперет и можно предугадывать, что надо подгрузить).
Вы видимо никогда игрушки не писали :) Там даже за прирост скорости в 15% борются.
Согласен, писать динамичные игры на .Net в данный момент глупость, но так уж сложилось что я в силу определенный факторов пришел на эту платформу, а привычки и взгляды остались.
Действительно можно попробовать копировать блоки помещающиеся в L1 и переворачивать их in-place. Я хотел это проверить, но по ходу реализации пришел к выводу что это вряд-ли будет быстрее ReverseArrayManual :)
Что касается ReverseArrayFramework — ну так там и особо думать не о чем, прирост производительности в других реализациях достигается исключительно за счет отброса лишних копирований. А в случае unsafe еще исключается лишний промежуточный буфер.
Кстати, вернулись же к исходному — алгоритм кэширования (как и предсказания ветвлений) остается «черным ящиком», известно только что он должен делати и есть рекомендации что лучше на вход скармливать.
Я прекрасно понимаю обширность темы, это я так намекаю что с удовольствием почитал бы что-то более обширное, нежели комментарии :) Если время позволяет, конечно.
не прокидывание исключения вполне нормальная практика. если проблема решилась локально.
использование исключений в логике тоже вполне допустимо. во-первых если они используются хоть где-то, то инфраструктура для их обработки уже внедрена в приложение. а во-вторых на фоне Qt они тормозить не будут )
а дальше лень смотреть )
А фреймворк не есть единственно верное решение, кстати что-то мне кажется что энумератор тормозить ужасно будет. Ну примерно как версия с LINQ, по тем же причинам.
Впрочем я не уверен, что девайс для игрушек предназначался, но такова специфика у gamedev индустрии — прикрутить игрушку на все, где ее можно продать :)
Кстати в опере удобно кнопку на тулбар для этого вынести.
А во вторых… есть некоторые познания о жизнеспособности .Net CF в условиях ограниченых ресурсов (около 2М памяти, остальное железо тоже на уровне, .Net CF официальная среда), и они не очень позитивные. Впрочем писали же люди… И работало, правда с гайдлайнами .Net в итоге мало общего имело :)
2. Стиль, как стиль. На С/С++ сплошь и рядом так пишут, главная польза в единоразовом вычислении str.Length. Ну и потенциальном схлопывании сравнения с нулем в одну операцию целевого процессора, хотя и мелочь второе.
Кстати сложность будет сравнима со сложностью обработки суррогатных пар.
Вопрос не во времени загрузки игрушки, а в скорости отклика на действия пользователя.
А вот какой логикой он руководствуется при захвате блока памяти мало кому известно. Например высока вероятность, что при линейном чтении большого массива, через пару итераций будет захватываться блок большого размера (тем более что спекулятивное выполнение заглядывает на нексколько инструкций вперет и можно предугадывать, что надо подгрузить).
Согласен, писать динамичные игры на .Net в данный момент глупость, но так уж сложилось что я в силу определенный факторов пришел на эту платформу, а привычки и взгляды остались.
А если серъезно, то дело ведь не столько в самом акте разворачивания строки, лично мне интересней посмотреть, что вообще можно выжать из этой среды.
Есть два противостоящих «мира»: одни строят приложение на сверхвысокоуровневой платформе не думая об эффективности и производительности (об этом за нас подумает платформа ©), другие же пытаются выжать максимум чтою эта «платформа» таки думала за первых. Лично мне ближе второе, закономерно, что я буду везде искать интересные мне аспекты.
А конкретно это пример был «высосан из пальца» в пятницу вечером :)
Что касается ReverseArrayFramework — ну так там и особо думать не о чем, прирост производительности в других реализациях достигается исключительно за счет отброса лишних копирований. А в случае unsafe еще исключается лишний промежуточный буфер.