Кто со мной?

[still_alive]

Не очень понятно, о чем спор. Если накладные расходы на создание и уничтожение объекта не существенны, то все остальное дело вкуса. Еще б поспорили, где фигурные скобки ставить (вброс: на той же строке ествно).

а как же минимальная область видимости переменной?

Никаких проблем, просто при необходимости добавляем фигурные скобки:
{
char c;
for ...
}

[Пепел Феникса]

Никаких проблем, просто при необходимости добавляем фигурные скобки:

практически любой нормальный компилятор итак делает так.

[_Bers]

Сообщение от netrino

Если мы говорим о высокопроизводительных программах, то безусловно это так.

Мы говорим не о том, как выжать максимум, а о том, как не допустить нерационального падения, сохранив идеологию и чистоту стиля.

Идеология с++ заключается в управлении сложностью проекта.
Красивая архитектура с++ избавляет программиста от необходимости держать в голове "низкоуровневую кухню"

Допустим, фик с ним, с чаром. А если речь об объекте класса?
Вы скажете: ну тяжелый же объект будит вызывать конструкторы, диструкторы, это же с++. Поэтому его надо выносить за тело цикла.

И что получится? Это мы выносим, а это не выносим, да?

Ну то есть, вместо единообразного стиля, получаем многообразный, и с требованием, знать как минимум азы ассемблера?
То есть вы предлагаете необходимость знания ассемблера тупо для того, что бы понимать что делает высокоуровневый прикладной код? Так что ли?
Может тогда проще сразу писать на ассемблере?


Макконелл в своей книге пишет: единообразный стиль - первая превентивная форма защиты от ошибок. И именно поэтому, и были созданы понятия о нотациях code-style

Сообщение от Son Of Pain

В первую очередь программист на C++ (да и на любом другом языке) должен писать код так, чтобы его было приятно читать. Ты же не будешь спорить с тем, что если переменная объявлена рядом с местом ее использования - это выглядит логичнее, чем pascal-style куча переменных в одном месте?

Хорошо, давайте на реалистичном примере?

Не чар, но тяжелый объект. Его конструкторы/диструкторы сжирают кучу времени.

Понятно, что вы вынесете его за тело цикла, да?

Вопрос: почему у вас объект находится за 1005000 км от места использования?

[_Bers]

мой тезис: что бы не допустить нерационального падения - достаточно знать родной язык.

А что бы обеспечить близкое использование создаваемой сущности - нужно грамотно структурировать программу. "Разделяй и властвуй" - разбивать сложную задачу на кучку мелких инлайн функций, которые манипулируют значениями данных. Но ничего не создают, и не удаляют.

В самом цикле только обработка данных. Ничего не создаётся, и не удаляется.

[Пепел Феникса]

Вы скажете: ну тяжелый же объект будит вызывать конструкторы, диструкторы, это же с++. Поэтому его надо выносить за тело цикла.

если нужен каждую итерацию новый обьект, то толку от выноса не прибавится.

[_Bers]

Сообщение от Пепел Феникса

если нужен каждую итерацию новый обьект, то толку от выноса не прибавится.

см задачу. Нужен ли?

[Son Of Pain]

О боже.

Сообщение от _Bers

И что получится? Это мы выносим, а это не выносим, да?

Да, именно так. Человек думающий отличается от догматика тем, что видит границы применимости существующих правил (догм).
Саттер в своей книге писал именно о таком случае, например.

Для понимания того, как и когда происходит создание и уничтожение объектов в C++, совсем не обязательно знать ассемблер, потому не нужно пытаться построить на этом красивый силлогизм.
И если это понимание есть - становится очевидным, в каких случаях стоит пренебречь читаемостью кода и унести переменную далеко, а в каких этого делать не стоит. Опять же - это будет понятно даже без знания ассемблера, которого ты так боишься.

Программисту всегда приходится балансировать между читаемостью&поддерживаемостью кода, скоростью его работы и разными другими факторами. И никакие механически вызубренные правила "единого стиля" тут не помогут.

[Пепел Феникса]

я же сказал, если.
иначе естественно надо, поскольку конструктор обьекта может обладать побочными эффектами, то если он в цикле, то каждый раз обязан быть вызван.

[_Bers]

Сообщение от Son Of Pain

О боже.
Да, именно так.

говнокод вас очень любит.


1. Нарушение инкапсуляции механизма.
2. Нарушение инварианта механизма.

Грешно знать и не применять. Но злоупотреблять - ещё более грешно

[Пепел Феникса]

Грешно знать и не применять. Но злоупотреблять - ещё более грешно

я считаю еще более грешным вынос того что нафиг вне цикла не нужно, из этого цикла и выносить.