Грань между разработчиком программ и разработчиком компиляторов [закрыт]

В последнее время очень много обсуждений об экономии на спичах, как привести ту или иную конструкцию в move семантике, всякие проблемы конкатенации строк с использованием .reserve и счетчике строк etc.
Где та самая грань, между разработчиком программ и разработчиком компиляторов? Что должен знать рядовой разработчик о языке? Ведь читать весь стандарт и разбираться в различных тонкостях нужно только разработчикам компиляторов? Или хорошо программировать на c++ не получится не читая весь стандарт?
Т.е. о чем должен знать рядовой программист, а что оставить разработчикам компиляторов и оптимизаторов?

Ответ

Мне кажется, нету однозначной границы. Многие вещи можно улучшать до бесконечности. Например, те же копии можно отоптимизировать при помощи move-семантики, вычисления можно вынести на этап компиляции при помощи «шаблонной магии», расходы на конкатенацию можно обойти, зарезервировав память заранее. Частично это проблема языка и «дырявых» абстракций, частично — недостаточно умный оптимизатор.
Границу каждый устанавливает для себя, исходя из своих эстетических предпочтений и практических задач. Например, если код представляет собой бизнес-логику, то в нём низкоуровневые оптимизации смотрятся не на месте, и кроме того ненужным образом усложняют и замедляют разработку.
Поскольку язык большой, программисты обычно знают только часть общей картины, которая попадается им при разработке. Те, кто занимается низкоуровневым кодом и битовыжиманием, часто плохо разбираются в семантике исключений или там многопоточности. Те, кто занимается lock-free-структурами и знают модель памяти до тонкостей, вполне могут плавать в вопросах упаковки структур или шаблонной магии. А те, кто умеет вычислять md5 на этапе компиляции, вполне могут не знать о внутреннем формате и накладных расходах на множественное наследование или плавать в деталях name resolution.
Язык C++ имеет тенденцию к большому акценту на «мелкую» эффективность, поэтому мне кажется, разрабатывая на нём, стоит уделить таким оптимизациям больше внимания.