Здравствуйте Андрей Тарасевич, вы писали:
АТ>Здравствуйте Igor Soukhov, вы писали:
IS>>2Tigor, IT, Андрей, Влад !
IS>>Пришел на работу — глянул — сабж ! IS>>=)
АТ>Ночь — понятие относительное. У меня GMT -08:00 :)
я знаю =) вернее помню =) ... меня потряс размер треда ... 38 писем в ящике с утра
хотя там бывает ну ... 2-3 ... да и щас значит уже у тя ночь =)
Здравствуйте Igor Soukhov, вы писали:
IS>>>2Tigor, IT, Андрей, Влад !
IS>>>Пришел на работу — глянул — сабж ! IS>>>=)
АТ>>Ночь — понятие относительное. У меня GMT -08:00 :) IS>я знаю =) вернее помню =) ... меня потряс размер треда ... 38 писем в ящике с утра IS>хотя там бывает ну ... 2-3 ... да и щас значит уже у тя ночь =)
Это у нас вчера вторая смена заступила ;)
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
IT>Здравствуйте Андрей Тарасевич, вы писали:
АТ>>А вот пустрые деструкторы, явно определенные программистом, (по определению они нетривиальны) в MSVC++, например, оптимизатором не выкидываются. И да, получаются пустые call-ы. (Если они не inline, конечно.)
IT>Точно. Компилятор просто не имеет права их выкинуть (ни какого). Откуда другому модулю известно — пустые они, не пустые... Боюсь, здесь и глобальная оптимизация не поможет... Ну разве что только ОЧЕНЬ глобальная. Кстати, это относится не только к деструкторам, которые практически ничем не отличается от других методов класса.
Ты чёё... мужик? Где ты видал шоб модули думали? ;o)
Если функция помечена как virtual или export/extern, то конечно ее выкинуть не должны, а если нет, то выкинут нафиг. :) Модульи то все вместе компилируются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, вы писали:
АТ>>>А вот пустрые деструкторы, явно определенные программистом, (по определению они нетривиальны) в MSVC++, например, оптимизатором не выкидываются. И да, получаются пустые call-ы. (Если они не inline, конечно.)
IT>>Точно. Компилятор просто не имеет права их выкинуть (ни какого). Откуда другому модулю известно — пустые они, не пустые... Боюсь, здесь и глобальная оптимизация не поможет... Ну разве что только ОЧЕНЬ глобальная. Кстати, это относится не только к деструкторам, которые практически ничем не отличается от других методов класса.
VD>Если функция помечена как virtual или export/extern, то конечно ее выкинуть не должны, а если нет, то
Любая функция по умолчанию является 'extern'.
VD>выкинут нафиг. :) Модульи то все вместе компилируются.
Под модулями понимается как раз таки то, что компилируется отдельно. Например, DLL.
Здравствуйте Андрей Тарасевич, вы писали:
АТ>Любая функция по умолчанию является 'extern'.
Да?
И эта тоже?
class xxx
{
void f1() {};
};
ню-ню...
VD>>выкинут нафиг. :) Модульи то все вместе компилируются.
АТ>Под модулями понимается как раз таки то, что компилируется отдельно. Например, DLL.
Думаю IT под ними .obj пониал... когда писал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, вы писали:
VD>>>выкинут нафиг. :) Модульи то все вместе компилируются.
АТ>>Под модулями понимается как раз таки то, что компилируется отдельно. Например, DLL.
VD>Думаю IT под ними .obj пони[b]м[/]ал... когда писал.
Процетирует ещё раз первоисточник: АТ>А вот пустрые деструкторы, явно определенные программистом, (по определению они нетривиальны) в MSVC++, например, оптимизатором не выкидываются. И да, получаются пустые call-ы. (Если они не inline, конечно.)
Ясный пень, компилятор (в классическом смысле этого слова) ничего никуда выкидывать не дожен, кроме одного случая, когда функция статическая (локальная в модуле) и нигде не вызывается. Удалять неиспользуемые функции — это работа линковщика, версия от MS которого как раз умеет делать своё дело очень не плохо.
А теперь обратимся к цитате. Речь идёт не о неиспользуемых модулях, а о тех, которые ничего не делают. Что бы линковщик их удалил, он должен во-первых понять, что в них пусто, а во-вторых изменить код вызывающей процедуры так, чтобы она ничего не вызывала. 8-/ Теперь объясните мне — как это можно сделать, хотя бы теоретически?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
IT>Здравствуйте VladD2, вы писали:
VD>>>>выкинут нафиг. :) Модульи то все вместе компилируются.
АТ>>>Под модулями понимается как раз таки то, что компилируется отдельно. Например, DLL.
VD>>Думаю IT под ними .obj пони[b]м[/]ал... когда писал.
IT>Процетирует ещё раз первоисточник: АТ>>А вот пустрые деструкторы, явно определенные программистом, (по определению они нетривиальны) в MSVC++, например, оптимизатором не выкидываются. И да, получаются пустые call-ы. (Если они не inline, конечно.)
IT> IT>Ясный пень, компилятор (в классическом смысле этого слова) ничего никуда выкидывать не дожен, кроме одного случая, когда функция статическая (локальная в модуле) и нигде не вызывается. Удалять неиспользуемые функции — это работа линковщика, версия от MS которого как раз умеет делать своё дело очень не плохо. IT>А теперь обратимся к цитате. Речь идёт не о неиспользуемых модулях, а о тех, которые ничего не делают. Что бы линковщик их удалил, он должен во-первых понять, что в них пусто, а во-вторых изменить код вызывающей процедуры так, чтобы она ничего не вызывала. 8-/ Теперь объясните мне — как это можно сделать, хотя бы теоретически? IT>
Включить опцию пропогирующую :)) inline. И шоо любопытно ни одной пустой фукции не останется. Глобал Аптямязэйшооон... понимаш. ;)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, вы писали:
АТ>>Любая функция по умолчанию является 'extern'.
VD>Да?
VD>И эта тоже?
VD>class xxx VD>{ VD> void f1() {}; VD>};
VD>ню-ню...
Я имел в виду, что любая функция ро умолчанию имеет external linkage. Да, и эта тоже. Inline на linkage не влияет. Просто добавляется требование того, чтобы функция быда определена во всех единицах компиляции. Логика мне не совсем ясна (какая разница, какое linkage имеет функция, если ее все равно требуется определять во всех единицах компиляции), но так сказано в спецификации языка.
VD>>>выкинут нафиг. :) Модульи то все вместе компилируются.
АТ>>Под модулями понимается как раз таки то, что компилируется отдельно. Например, DLL.
VD>Думаю IT под ними .obj пониал... когда писал.
Думаю, что он все таки имел в виду EXE/DLL модули.
Здравствуйте Андрей Тарасевич, вы писали:
АТ>Я имел в виду, что любая функция ро умолчанию имеет external linkage. Да, и эта тоже. Inline на linkage не влияет. Просто добавляется требование того, чтобы функция быда определена во всех единицах компиляции. Логика мне не совсем ясна (какая разница, какое linkage имеет функция, если ее все равно требуется определять во всех единицах компиляции), но так сказано в спецификации языка.
Здесь как раз логика правильная, ты ведь можешь спокойно взять адрес этой функции ;)
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
АТ>>Я имел в виду, что любая функция ро умолчанию имеет external linkage. Да, и эта тоже. Inline на linkage не влияет. Просто добавляется требование того, чтобы функция быда определена во всех единицах компиляции. Логика мне не совсем ясна (какая разница, какое linkage имеет функция, если ее все равно требуется определять во всех единицах компиляции), но так сказано в спецификации языка.
IT>Здесь как раз логика правильная, ты ведь можешь спокойно взять адрес этой функции ;)
Да, с этой точки зрения логика есть :) В одной из рабочих версий стандарта языка inline функциям по умолчанию предлагалось давать internal linkage. И для того, чтобы гарантировать совпадение адресов одной и той же inline функции в разных единицах компиляции нужно было бы писать 'extern inline'. Потом эту часть стандарта изменили и inline функции получили external linkage. Т.е. и без явного 'extern' адрес inline-функции везде должен получаться одинаковым. Хотя до сих по можно услышать утверждения, что для гарантрованного совпадения адресов требуется 'extern inline'. По-видимому существуют еще компиляторы, которые следуют устаревшей спецификации. Подозреваю, что MSVC++ 6.0 тоже к ним относится (лень проверять).
* thriving in a production environment *
Если нам не помогут, то мы тоже никого не пощадим.
