Здравствуйте, igna, Вы писали:

I>Я других не знаю. Тем не менее заявления вроде "статик внутри функции это всегда непереносимая функция какашка" как бы относятся и к приведенным мной примерам, и скорые на расправу рубщики рубят ведь "на ревью", и локальные по сути константы болтаются потом в глобальной области видимости или еще где.

Про такие я согласен. Хотя лично мне ближе такие константы объявлять просто статическими, а не статическими в функции.
И надёжнее, и понятнее и от причуд компилятора и платформы меньше зависимость...

Здравствуйте, purser, Вы писали:

P>Но мне же нужен один метод, который должен быть константным. А что должен делать неконстантный его брат-близнец и зачем он нужен?

Мне так кажется, что ты плохо понимаешь, что такое "константный метод"...

База даёт доступ только к константному интерфейсу. Наследник -- к полному. Если объект ограничен в доступе -- работаешь через указатель/ссылку базу, если нет -- через указатель ссылку на наследника...

E>>Так как у тебя решается проблема создания разных объектов по одинаковым адресам-то?..
P>Пока сам не разобрался. Разберусь — устрою голосовалку)

О! Вот на -- ЧИТАБЕЛЬНОСТЬ!!!

Здравствуйте, Alexey F, Вы писали:


AF>Вполне может попасться какая-нибудь зараза из компиляторов, которая подложит свинью и навернёт многопоточный код
AF>Придётся загаживать глобальное пространство имён единицы трансляции или ещё как-нибудь выкручиваться.

Придется. Но делать это с самого начала и есть та самая преждевременная оптимизация.

Здравствуйте, jyuyjiyuijyu, Вы писали:

>нда какой же вы интересный человек вцепились в этот 1 процент юз кейса в качестве
J>статических констант
J>и не видите 99 процентов говна со статиками у меня очень редко статическая пермеменная в коде

У меня этот "юз кейс" не 1, а как раз 99% (если не 100) использования static локально.

J>вот этот код будучи скомпилен
J>для C и для C++ на одном компиляторе cl.exe 15.0 генрирует разный код для C
J>генерируется потокобезопасный а для C++ инвалидный

J>static struct {
J>        char chr;
J>        char const ref[32];
J>    } const char_ref[] = {
J>        { '<', "lt" },
J>        { '>', "gt" },
J>        { '&', "amp" },
J>        { '\'', "apos" },
J>        { '"', "quot" },
J>    };

1. Это по-видимому баг VC++.
2. Это только "a performance issue", поскольку если константу 100 раз проинициализировать одним и тем же значением, никаких других проблем ожидать не приходится.
3. Даже и на этот баг я вряд ли наступил бы, покольку обычно перечитываю, что пишу, и заметил бы, что char const* ref заменять надо на char ref[32], а не на char const ref[32], поскольку оставленный тобой при преобразовании кода const имеет в твоем коде совсем другое значение нежели в моем.

J>фактически по стандарту C++ они оба инвалидны
J>там грится что при первом проходе локальный статик инится

Не при, а до: "before its block is first entered".

Здравствуйте, igna, Вы писали:

I>У меня этот "юз кейс" не 1, а как раз 99% (если не 100) использования static локально.
Так это же хорошо!
Не понятно только, зачем и эти 99% не превратить в просто static в единице трансляции, ну да это уже, скорее, вкусовщина, на самом деле.
Главный косяк static in function -- там можно случайно "заморозить" контекст первого вызова функции. Ну да это довольно редкая ошибка, скорее всего.

Здравствуйте, Erop, Вы писали:

E>Не понятно только, зачем и эти 99% не превратить в просто static в единице трансляции, ну да это уже, скорее, вкусовщина, на самом деле.

Во.

И нечего кое-кому (неважно кто это был, хотя это был jyuyjiyuijyu) обзывать это дело какашкой, а кое-кому другому (SleepyDrago) рубить не разобравшись на ревью. Раз вкусовщина.

Здравствуйте, igna, Вы писали:

I>И нечего кое-кому (неважно кто это был, хотя это был jyuyjiyuijyu) обзывать это дело какашкой, а кое-кому другому (SleepyDrago) рубить не разобравшись на ревью. Раз вкусовщина.

По моему опыту "вкусовщина" значит, что не важно как делать, главное, чтобы одинаково.
Так что я вполне понимаю людей, которые договорились так не делать, так как преимуществ это никаких не даёт. Я даже пойму людей, которые сильно ограничат использование static in function в принципе.

IMHO, это примерно такой же "важный" вопрос, как стиль расстановки скобок

Здравствуйте, Erop, Вы писали:

E>По моему опыту "вкусовщина" значит, что не важно как делать, главное, чтобы одинаково.

Ну естественно.

E>Так что я вполне понимаю людей, которые договорились так не делать, так как преимуществ это никаких не даёт. Я даже пойму людей, которые сильно ограничат использование static in function в принципе.

Ради бога. Только у себя в проекте, а не в публичном форуме.

E>IMHO, это примерно такой же "важный" вопрос, как стиль расстановки скобок

Да, только кавычки я бы убрал, стиль расстановки скобок как и стиль объявлений важны без кавычек, поскольку читабельность.

Здравствуйте, igna, Вы писали:

Я вдруг вспомнил, что в новом стандарте есть решение без закладывания на implementation-defined: возможность получить выражение, гарантированно вычисляемое на этапе компиляции... :

void func() {
...
    static struct {
        char chr;
        char ref[ 32 ];
    } constexpr char_ref[] = {
        { '<', "lt" },
        { '>', "gt" },
        { '&', "amp" },
        { '\'', "apos" },
        { '"', "quot" }
    };
...
    static char constexpr string[] = "abcdefghijklmnopqrstuvwxyz";
...
}

В сочетании static + constexpr компилятор не занимается созданием массивов на стеке (в отличие от просто constexpr) и, насколько я знаю (а как иначе с constexpr variable-то?), не имеет права отложить инициализацию этого участка.

g++ 4.6.1 (prerelease) не генерирует лишнего кода на этих участках ни без оптимизации, ни после неё. А попытка сломать выражение, сделав его неконстантным, обламывается.

И это даже не преждевременная оптимизация, а контракт на полную константность выражения и уменьшение области видимости