Как обстоят дела с модулями C++20 и Inline оптимизацией?
Читал, что Inline не объявляется в методах и функциях модулей неявно. Это значит, что компилятор больше не будет за меня делать работу с этой оптимизацией?
Dolarun, он это делает практически со всеми функциями, для которых может посчитать алгоритмическую пользу от встраивания. Более того, в собранном тобой коде могут присутствовать как выделенные тела твоих не-inline функций, так и результаты их встраивания.
За этот процесс отвечают настройки встраивания сгенерированного кода в твоем трансляторе.
Ключевое слово inline[?] определяет спецификатор, которым помечаются сущности со слабым внешним связыванием. Связывание внешнее, поэтому для таких сущностей обязательным является требование ODR. В это же самое время связывание обозначено как слабое, это означает что проверка на соответствие ODR для таких сущностей проходит не в момент чтения определения сущности из объектного файла, а в момент встраивания этой сущности.
И проверка эта выполняется таким образом, что проходят ее только полные дубликаты первого определения сущности. Если очередное определение такой сущности отличается от самого первого считанного определения, такое определение проваливает ODR и трансляция завершается с ошибкой. Само же связывание всегда производится только с самым первым определением сущности.
Т.е. к процессу встраивания спецификатор inline имеет далеко опосредованное отношение.
И вот давай теперь подумаем о том, какую роль модули играют в процессе линковки исходного кода и как модули могут поменять поведение слабого внешнего связывания?
Евгений Шатунов,
по идее в документе, который Вы указали, как авторитетный источник, его суть сводится к тому, что inline это translation unit bound semantical flag.
То есть похоже, что Dolarun прав.
Поскольку ( если мыслить логически ) линкер не имеет права на inference, только транслятор.
Не путать с распараллеливанием процедур. Матричные оптимизации, развертка, происходит в памяти процессора ( что так же возможно требует переосмысления, ибо не очевидно ).
Вырванное из контекста " inline это translation unit bound semantical flag" может означать все что угодно, даже погоду на Марсе.
Теперь фразе требуется вернуть контекст и внести конкретику. Результатом этого процесса будет строго однозначное понимание термина.
I apologies, I wasn't prepare to this degree of scrutiny of words.
It really is somewhat deciphering document you have shared.
The document, its scope, is directed at terms and meaning of each term.
What @Dollarum is proposing slices across domain of this word stream.
He is basically applying the verbatim of the document to specific use case.
This use case isn't in the document.
So, we have two choices.
1. send request to United Nations ( as a figure of speech ) and wait until they down unto us with "строго однозначное понимание термина", which in human words is a rare commodity, and really, never ever happens, no pun intended, but a succinct summary of practice.
or
2. try to turn to "many meaning" and slowly narrow those down and agree on what we find out, following our own humble devices. Or, in simple terms, a constructive way to understand what we are dealing with.
It would be really - really nice if you proposed your own interpretation. I personally would be delighted to read it :)
---
This isn't first discussion of this sort I am seeing. The previous one has occurred about 15 years ago, and since time has passed enough to pull even official seal of secrecy, I will make a call on this informal FOYA and describe similar research in meaning of words.
And engineer working at Microsoft fielded a question, regarding handling hardware exception in the event of communication link failure between an application and an database.
He had received an extremely qualified response from a Russian engineer, apparently working at Intel, with reference to specific hardware register and error code number, to look for, when handling such an exception, that was apparently causing significant trouble to product's driver ( Microsoft SQL Server ).
This discussion ensued at expert-exchange.com site, similarly facilitating exchange of knowledge between engineers.
In the end the engineer, who received support never ever acknowledged significant help and contribution of his vis-a-vis, however, it had significant impact on product quality improvement.
My proposal, we should be better than that engineer :)
