Подробнее
Когда закончил решать задачу на CodeForces public class Printer { public static String printerError(String controlstring) { int badCharCounter = 0; StringBuilder builder = new StringBuilderQ; for (int i = 0; i < controlstring.lengthO; i++) { if ((int) controlstring.charAt(i) >= no) { badCharCounter++; > > builder.append(badCharCounter).append("/").append(controlstring.length()); return new String(builder); > > Как ее решили другие public class Printer { public static String printerError(String s) { return s.replaceAll("[a-B]“, "").length() + "/“ + s.lengthO; >
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
Пришлось перечитать первый код, чтобы убедиться, что с первого раза всё понял не правильно. (facepalm). Ну и да, >=110 и [a-m] не одно и то же, однако мы не знаем условия, чтобы говорить кто прав.
Имхо, писать надо коротко, но не сжато.
За редким исключением во всех таких соревнованиях оценивается то, как быстро ты смог придумать и закодировать безошибочное решение. Что влечет за собой достаточно экстравагантные практики написания кода. Рабочий код нужен как можно скорее, а когда закончится контест и его разборы, никто и никогда больше не будет читать, вносить расширения, правки и фиксы в этот код.
Перейдя на реальные проекты люди со спортивным прошлым, годами приходят в чувство. Некоторые, особенно те, что параллельно со спортивной деятельностью никогда не писали собственных маленьких проектиков, в чувство не приходят никогда. И навечно остаются "подающими надежды", лучшее место работы для которых - готовить эти самые спортивные соревнования.
Просто я вижу тут (хоть сам из 1 группы, студент раздолбай) банальное незнание метода replaceAll...
На реальных проектах МОГУТ БЫТЬ СЛУЧАИ (например если мы глобально стараемся не создавать лишнюю нагрузку на GC), когда первый способ решения будет предпочтительней. Особенно, в случае если builder можно использовать повторно, а результат можно будет вернуть в более вменяймой форме чем строка.
Если не считать того, что он, вероятно, неправильно реализован. для случая когда в строке есимволы меньше 'a' .
В данном случае, задача совсем для новичков и не столь важно как её решать. но ДЛЯ ЗАДАЧ СЛОЖНЕЕ ЧЕМ ЭТА, при прочих равных, часто написание чуть более длинного, но более понятного кода, предпочтительней изощренных однострочных придумок (например заковыристых регексов). Если ты написал код, который никто кроме тебя не понимает, это не ты самый умный. А как раз даже наоборот.
В рамках этой задачи у мы видим решение, вызванное отнюдь не заботой о производительности, а банальным неумением использовать регулярные выражения.
use Time::HiRes (gettimeofday);
$start = gettimeofday();
my $string = 'abcdefghijklmopqrstuvwxyz'x100000;
$total = length($string);
$string=~s/[a-m]+//g;
$count = length($string);
$end = gettimeofday() - $start;
print "Total time: $end sec, result: $count of $total\n";
Total time: 0.0329160690307617 sec, result: 1200000 of 2500000
Т.е. три сотых секунды для строки размером в 2.5 миллиона символов.
1) Немножко самоцитирования "а в отсутствии временных аллокаций. Иначе, если функция будет дёргаться в цикле, гарантированно будет регулярный стопворлд. А такое не для игрушки, не для банк трейдера не допустимо, например.
2) Немножко логики. В реальном приложении или игрушке этот код будет висеть на сотне объектов и выполняться 60 раз в секунду, генерирую одну красивую строку статуса и кучу временного мусора, который прийдется чистить дот нету или ява машине.
3) Ссылочки на бесконечные "моя игра тормозит, што делать!?!?!"
"After some digging and playing around in the profiler, I found out those were due to some line named GC.Collect. In my project, it can take up to 8.62ms (on my high-end pc) of the 9.79ms needed for my behaviours updates on a given frame;"
"The strings create garbage as well, even when you concatenate them, so if you have to handle a lot of text somewhere and manipulate it heavily, use a StringBuilder that will take care of those memory issues alone and avoid the creation of garbage."
https://www.gamasutra.com/blogs/GrhyllJDD/20160119/263849/Reducing_memory_allocations_to_avoid_Garbage_Collection_on_Unity.php
https://forum.unity.com/threads/understanding-how-strings-related-to-memory-allocations.121140/
И вот в таких раскладах читаемость и простота кода намного важнее оптимизации.
Собственно, это универсальное правило - простота всегда предварительно лучше скорости. Потому что потом ты можешь профайлером посмотреть, что именно тормозит и оптимизировать, а вот сразу зарываться в оптимизацию - путь к долгой и неприятной отладке.