Re[13]: Проблемы с навигацией
От: Ночной Смотрящий Россия  
Дата: 29.12.16 20:18
Оценка: 7 (1) +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Сложность языка ведёт к false-positives, но для навигации это не критично, критично для рефакторинга.


Кто бы сомневался. Если плюсы лажают, то это некритично.

No way to locate definitions

OK, so before we can parse AA BB(CC);, we need to find out whether CC is defined as an object or a type. So let's locate the definition of CC and move on, right?

This would work in most modern languages, in which CC is either defined in the same module (so we've already compiled it), or it is imported from another module (so either we've already compiled it, too, or this must be the first time we bump into that module — so let's compile it now, once, but of course not the next time we'll need it). So to compile a program, we need to compile each module, once, no matter how many times each module is used.

In C++, things are different — there are no modules. There are files, each of which can contain many different definitions or just small parts of definitions, and there's no way to tell in which files CC is defined, or which files must be parsed in order to "understand" its definition. So who is responsible to arrange all those files into a sensible string of C++ code? You, of course! In each compiled file, you #include a bunch of header files (which themselves include other files); the #include directive basically issues a copy-and-paste operation to the C preprocessor, inherited by C++ without changes. The compiler then parses the result of all those copy-and-paste operations. So to compile a program, we need to compile each file the number of times it is used in other files.

This causes two problems. First, it multiplies the long time it takes to compile C++ code by the number of times it's used in a program. Second, the only way to figure out what should be recompiled after a change to the code is to check which of the #include files have been changed since the last build. The set of files to rebuild generated by this inspection is usually a superset of the files that really must be recompiled according to the C++ rules of dependencies between definitions. That's because most files #include definitions they don't really need, since people can't spend all their time removing redundant inclusions.

Some compilers support "precompiled headers" — saving the result of the parsing of "popular" header files to some binary file and quickly loading it instead of recompiling from scratch. However, this only works well with definitions that almost never change, typically third-party libraries.

And now that you've waited all that time until your code base recompiles, it's time to run and test the program, which is when the next problem kicks in.

http://yosefk.com/c++fqa/defective.html

Там еще много прекрасного. Но это некритично, да.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.