Присвоение локальной переменной для ухода от нескольких бросков
Нет никакой настоящей причины для использования extern "C++". Это просто делает явными связь, которая является неявным значением по умолчанию. Если у Вас есть класс, где у некоторых участников есть экстерн "C" связь, можно пожелать явного состояния, что другие - экстерн "C++".
Примечание, которое Стандарт C++ определяет синтаксически extern "anystring". Это только дает формальные значения extern "C" и extern "C++". Поставщик компилятора свободен определить extern "Pascal" или даже extern "COM+", если им нравится.
8 ответов
Определенно поеду первым. Разница в производительности, вероятно, не имеет значения, но читаемость определенно улучшена.
Помимо удаления приведений, это также означает, что вы можете использовать другое имя - в конце концов, теперь вы знаете больше об этой переменной, поэтому, возможно, имеет смысл дать ей более конкретное имя. Это не всегда так, но может быть. Техника рефакторинга «ввести локальную переменную ради наименования значения» недооценивается, даже без приведений ...
Я предпочитаю создавать локальную переменную, а не всегда выполнять приведение из-за проблем с читабельностью. Читаемость кода для меня (или других разработчиков, работающих над тем же кодом) является важным вопросом.
Беспокойство о производительности на этом этапе кажется мне примером шаблона «преждевременной оптимизации».
Я предпочитаю первый, так как он выглядит более чистым. Второй начинает выглядеть как Lisp . Но это личное мнение.
Я бы сказал, что важно не оптимизировать преждевременно. Если есть накладные расходы на приведение, они, вероятно, будут настолько малы, что на практике будут практически незаметны. Если этот фрагмент кода не занимает большую часть процессорного времени вашего приложения, я не думаю, что вы заметите какую-либо измеримую разницу в производительности между ними.
Следовательно, я бы также выбрал первый вариант, так как он выглядит чище и проще понять и изменить - гораздо важнее, чем выполнение на пару тактов быстрее в 99,99% ситуаций.
Абсолютно хорошая идея, поскольку она улучшает четкость. Я бы сказал, что это применимо и для предотвращения множественных вызовов методов доступа - это хорошая идея для ясности, а не из соображений производительности.
Я предпочитаю первый вариант по двум причинам
- Необходимые скобки делают код запутанным и трудным для чтения
- Возможно (небольшие) накладные расходы в приведении
Я предпочитаю первый, не только для удобства чтения кода, но и для отладки во время выполнения (также для исходного примера - если вы поместите результат геттера в локальный, вы увидите это значение, вместо того, чтобы отслеживать его в первый раз).
Я согласен с людьми, которые говорят, что первая версия предпочтительнее, но я хотел бы добавить, что если это вообще возможно - а это почти всегда возможно - вам следует в первую очередь избегать преобразования типов. Не из соображений производительности, а просто для дополнительной проверки правильности кода.