Здравствуйте, Дрободан Фрилич, Вы писали:
ДФ>В студии Replace in Files позволяет заменить табы на пробелы
Это если предпродажная подготовка, когда уже договорились на цену за байт сорсов. А по-человечески если — нужно наоборот. Причём не все пробелы, а только в началах строк, да и то иногда не всех. Я cindent использовал, но он пробелы на табы только в начале строки не умеет, им всё в пробелы переводил, а в табы потом — своей простенькой программкой. Теперь та программка уже не нужна, в стандартных дистрибутивах expand/unexpand появились, хоть и с корявыми ключами.
Не сработает, если программа писалась упоротыми товарищами, внутри строк тоже табами егозившими для красивости. Ну и вообще если внутри строк неземные красоты наведены, при переформатировании всё накроется. Но оно и правильно, мудрые люди говорят, что так делать нельзя.
Ещё cindent не умел по-людски строки переносить, поэтому им все в одну строку делал (ширина 256, кажется), а потом сам руками. В общем, нормальное оформление программы — тоже труд, и чисто автоматически вряд ли выйдет хорошо.
Здравствуйте, c-smile, Вы писали:
CS>Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t.
CS>Кто что порекомендует? Или я таки еще рано беспокоюсь и такого нет в природе?
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
The main usage scenarios that are foreseen for Vera++ are:
Ensure that the source code complies with the given coding standards and conventions.
Provide source code metrics and statistics.
Perform automated transformations of the source code, which can range from pretty-printing to diagnostics to fault injection and advanced testing.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, c-smile, Вы писали:
U>>>use std::map, Luke!
CS>>Сам-то понял что сказал?
U>я предложил каскад if (по факту линейный поиск) можно заменить на поиск по мапе (тут всякие мапы можно заюзать) U>вот так, например: https://ideone.com/oa9hv0 U>по факту это switch по строкам, который в плюсах не поддерживается =\
Ты думаешь что условно 9 if:
if(s.length = A && strcmp(...) == 0) t = 1;
else if(s.length = B && strcmp(...) == 0) t = 2;
...
будет медленнее чем создание std::map и поиск по дереву?
Если "да" то ты ошибаешься я думаю.
А для больших списков строк есть gperf который a) статический, b) быстрее чем std::map и с) памяти не просит.
Здравствуйте, c-smile, Вы писали:
U>>я предложил каскад if (по факту линейный поиск) можно заменить на поиск по мапе (тут всякие мапы можно заюзать) U>>вот так, например: https://ideone.com/oa9hv0 U>>по факту это switch по строкам, который в плюсах не поддерживается =\ CS>Ты думаешь что условно 9 if: CS>
CS>if(s.length = A && strcmp(...) == 0) t = 1;
CS>else if(s.length = B && strcmp(...) == 0) t = 2;
CS>...
CS>
CS>будет медленнее чем создание std::map и поиск по дереву? CS>Если "да" то ты ошибаешься я думаю.
Так это зависит от того, как используется данный код. Если он вызывается не один раз, то очевидно что std::map будет эффективнее, т.к. инициализация дерева будет происходить только один раз. И это кстати не теория — я использую на практике именно такой подход (только со string_view, а не string в качестве ключа для map).
CS>А для больших списков строк есть gperf который a) статический, b) быстрее чем std::map и с) памяти не просит.
Хы, ну это уже для совсем тяжёлых случаев игрушка. )))
Здравствуйте, c-smile, Вы писали:
CS>Ты думаешь что условно 9 if: CS>if(s.length = A && strcmp(...) == 0) t = 1; CS>[/ccode] CS>будет медленнее чем создание std::map и поиск по дереву?
Конечно if зарулит, если еще построить автомат, чтобы без strcmp, думаю, будет еще быстрее. А уж если собрать статистику, что чаще ищется и использовать чтобы минимизировать branch mispredict, то еще лучше. map здесь делает код чище, поэтому если овчинка выделки не стоит я за map (unordered_map), а в плане быстродействия вообще сравнивать смысла нет.
Здравствуйте, c-smile, Вы писали:
CS>Оно и хрен бы с ним, но вот зачем "time-" "local" разделились не ясно. CS>Хотя, нет, ясно ибо BreakStringLiterals: true было
Для clang-format'а есть какие-то специальные комменты в коде, типа "отсюда не форматировать" и "досюда не форматировать".
Здравствуйте, c-smile, Вы писали:
U>>use std::map, Luke!
CS>Сам-то понял что сказал?
я предложил каскад if (по факту линейный поиск) можно заменить на поиск по мапе (тут всякие мапы можно заюзать)
вот так, например: https://ideone.com/oa9hv0
по факту это switch по строкам, который в плюсах не поддерживается =\
Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t.
Кто что порекомендует? Или я таки еще рано беспокоюсь и такого нет в природе?
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Artistic Style
Я когда-то его смотрел, некоторых (интересных мне) вариантов форматирования не хватало. Вообще, тогда было ощущение, что все такого рода инструменты умеют форматировать только в стиле "Linux kernel", с небольшими вариациями.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
CS>Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t. CS>Кто что порекомендует? Или я таки еще рано беспокоюсь и такого нет в природе?
В CodeBlocks штук 15 стилевых форматтеров С++ кода.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, c-smile, Вы писали:
CS>Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t. CS>Кто что порекомендует? Или я таки еще рано беспокоюсь и такого нет в природе?
Решарпер умеет достаточно неплохо. Единственное — ловил косяки с удалением неиспользуемых заголовочных файлов.
c-smile:
CS>Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t.
В студии Replace in Files позволяет заменить табы на пробелы
Здравствуйте, c-smile, Вы писали:
ДФ>>В студии Replace in Files позволяет заменить табы на пробелы
CS>Я конечно профан в некоторых вопросах, но уж не настолько.
Ты просто заблуждаешься насчет цели этого поста
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, c-smile, Вы писали:
CS>Решил навести красоту в исходниках и привести их к единому формату. Оные редактировались на разных платформах, разных редакторах и соответственно разными верованиями в значение \t. CS>Кто что порекомендует? Или я таки еще рано беспокоюсь и такого нет в природе?
Такого полно и многие известные решения уже перечислены в данной темке. Однако после появления clang format смысл во всяких сторонних дополнительных решениях полностью пропал. Ну это если мы конечно про C/C++ говорим... )
насколько критично по производительности?
вариант с поиском в сортированном векторе/массиве не пробовал?
добавление простого хэша как ситуацию изменит?
В моем случае производительность всегда критична. Во всяком случае желательна.
Иначе получается Electron.
NB>вариант с поиском в сортированном векторе/массиве не пробовал?
Сортированный вектор из 8 элементов? Зачем?
NB>добавление простого хэша как ситуацию изменит?
А как это меняет дело?
Я в скрипте как-то проводил исследование — представление object в памяти:
{ foo: 1,
bar: 2,
zed: 3 }
Оказалось что если кол-во key/value пар меньше 7-8 то линейный поиск быстрее — меньше накладных расходов на подготовку поиска.
Поэтому если элементов больше 8 я object конвертирую в hash table.
Но это все индивидуально — зависит от того что есть ключ в конкретном случае.
Здравствуйте, night beast, Вы писали:
NB>насколько критично по производительности? NB>вариант с поиском в сортированном векторе/массиве не пробовал? NB>добавление простого хэша как ситуацию изменит?
Нет, там немного другой расклад — гораздо критичнее совсем другие параметры.
У варианта с map используется чуть менее медленное сравнение (отношение, а не равенство) чем в варианте с if, но при этом само количество сравнение меньше (причём принципиально — O(n) vs O(log(n)) ). Соответственно чем больше элементов в нашем списке вариантов, тем больше будет преимущество кода с map над вариантом с if.
Ну и ещё отдельно можно отметить, что нахождение среди тестируемых образцов вариантов не входящих в список определённых существенно деградирует эффективность кода с if (т.к. надо всегда проходить весь путь сравнения) и почти никак не влияет на производительность кода с map.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
CS>>А если не гадать на кофейной гуще то вот результаты теста — меньше run time — лучше: CS>>
CS>>Т.е. мой вариант не то что не хуже, а вообще в два раза быстрее.
_>К сожалению не могу проверить данные результаты, т.к. не знаю кто такие tool::chars и т.п.
Ты как я понял используешь map string_view.
Т.е. можешь переписать мой вариант со string_view — получишь тот же результат — map медленнее.
Это если string_view::operator=() правильно написан конечно.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, night beast, Вы писали:
Это вот ты написал?
_>то очевидно что std::map будет эффективнее, т.к. инициализация дерева будет происходить только один раз. И это кстати не теория — я использую на практике именно такой подход (только со string_view, а не string в качестве ключа для map).
Если "да" то вот тебе пример когда map медленнее перебора.
Здравствуйте, c-smile, Вы писали:
_>>К сожалению не могу проверить данные результаты, т.к. не знаю кто такие tool::chars и т.п. CS>tool::chars это пара CS>
А, ну т.е. это как раз самопальный аналог string_view. )))
_>>Вообще то это не моя функция — её предложил uzhas. Я вроде как вполне однозначно написал выше, что использую немного другой вариант. CS>Ты как я понял используешь map string_view. CS>Т.е. можешь переписать мой вариант со string_view — получишь тот же результат — map медленнее. CS>Это если string_view::operator=() правильно написан конечно.
Эм, оператор равенства? ) У тебя какое-то весьма странное представление об алгоритмах... Как ты себе представляешь бинарное дерево на основе оператора равенства? )))
В реальном мире std::map очевидно использует оператор сравнения (а конкретно оператор "меньше"), а не оператор равенства. Причём если не указать иного, то используется стандартный оператор "меньше" для указанного в качестве ключа типа. И как раз в этом и заключается причина медленности твоей реализации варианта с map: стандартный оператор сравнения у std::string (да и у std::string_view тоже) является лексикографическим, что абсолютно логично для строкового типа, но совершенно избыточно для ключа бинарного дерева. Однако стоит нам указать более подходящий оператор сравнения, например так:
как сразу же данный код с map становится быстрее твоего варианта с if'ми даже для указанного в твоём примере небольшого перечисления (для больших перечислений map будет эффективнее даже со стандартным лексикографическим оператором сравнения).
Здравствуйте, c-smile, Вы писали:
CS>Это вот ты написал? _>>то очевидно что std::map будет эффективнее, т.к. инициализация дерева будет происходить только один раз. И это кстати не теория — я использую на практике именно такой подход (только со string_view, а не string в качестве ключа для map).
Зачем задавать риторические вопросы? )
CS>Если "да" то вот тебе пример когда map медленнее перебора.
Пока что подобного примера не видел. А видел только неумение пользоваться стандартными средствами языка и как следствие этого написание самопальных велосипедов. )
Здравствуйте, MTD, Вы писали:
MTD>Конечно if зарулит, если еще построить автомат, чтобы без strcmp, думаю, будет еще быстрее. А уж если собрать статистику, что чаще ищется и использовать чтобы минимизировать branch mispredict, то еще лучше. map здесь делает код чище, поэтому если овчинка выделки не стоит я за map (unordered_map), а в плане быстродействия вообще сравнивать смысла нет.
В данном конкретном случае unordered_map будет менее эффективным решением, по сравнению с просто map. )