#include - again
-
I rely on "intelisense" to help me to add CORRECT #include header file. It sort of works in "left to right " fashion . If I need to add "header_.h" file I have to step thru all options BEFORE I have "header_.h " option. #include "../ now intlesence gives all options after "/". The "problem is " - until CORRECT , valid option is presented and selected I still have no way to see if it actually have an option to select desired header. It would be nice to have option to determine required path BEFORE going thru the intelisense steps. Sort of in reverse direction, opposite intelisense way. Is there?
Since you are using
#include " ...(double quotes) rather than#include < ...(angle brackets), you should know what the path is, as you are referring to local headers. But you could simplify things by adding the required header locations to the list of include directorie for the compiler to search. -
I rely on "intelisense" to help me to add CORRECT #include header file. It sort of works in "left to right " fashion . If I need to add "header_.h" file I have to step thru all options BEFORE I have "header_.h " option. #include "../ now intlesence gives all options after "/". The "problem is " - until CORRECT , valid option is presented and selected I still have no way to see if it actually have an option to select desired header. It would be nice to have option to determine required path BEFORE going thru the intelisense steps. Sort of in reverse direction, opposite intelisense way. Is there?
For standard include files, doc pages for the function usually show what include file to use. For your own, or other dependencies, not much luck. You can try to grep function name in *.h files. Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
Mircea
-
For standard include files, doc pages for the function usually show what include file to use. For your own, or other dependencies, not much luck. You can try to grep function name in *.h files. Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
Mircea
Mircea Neacsu wrote:
Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file :-) There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber"
Religious freedom is the freedom to say that two plus two make five.
-
For standard include files, doc pages for the function usually show what include file to use. For your own, or other dependencies, not much luck. You can try to grep function name in *.h files. Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
Mircea
Mircea Neacsu wrote:
Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file :-) There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ... Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know. Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
-
Mircea Neacsu wrote:
Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file :-) There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ... Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know. Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
Your name pollution point is valid. I just said it's "another strategy", I didn't say it's a good strategy :laugh:.
trønderen wrote:
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need.
Easy: just turn the "uber" in a pre-compiled header and that speeds up things dramatically.
Mircea
-
Mircea Neacsu wrote:
Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file :-) There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ... Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know. Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
-
Mircea Neacsu wrote:
Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file :-) There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ... Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know. Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need
Easy Peasy:
[k5054@localhost]$ cat ex1.cpp
#include int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex1.cppreal 0m0.208s
user 0m0.148s
sys 0m0.058s
[k5054@localhost]$ cat ex2.cpp
#include int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex2.cppreal 0m0.865s
user 0m0.718s
sys 0m0.142s
[k5054@localhost]$That's a 400% slow down. I've never done that in real life. I stumbled across
bits/stdc++.honly a couple of years ago, I think in QA. Not sure why the GNU maintainers allowed it. It seems like a good way to get a whole raft of unexpected results."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Sort of in reverse direction, opposite intelisense way.
Is there?
concluding from discussion which "went sideways" ( am I allowed to have an opinion ?) there is no such option
-
trønderen wrote:
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need
Easy Peasy:
[k5054@localhost]$ cat ex1.cpp
#include int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex1.cppreal 0m0.208s
user 0m0.148s
sys 0m0.058s
[k5054@localhost]$ cat ex2.cpp
#include int main()
{
std::cout << "Hello World\n";
}
[k5054@localhost]$ time g++ ex2.cppreal 0m0.865s
user 0m0.718s
sys 0m0.142s
[k5054@localhost]$That's a 400% slow down. I've never done that in real life. I stumbled across
bits/stdc++.honly a couple of years ago, I think in QA. Not sure why the GNU maintainers allowed it. It seems like a good way to get a whole raft of unexpected results."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Yeah, that's what I expected. I do not consider your example fully qualifying, though. I was speaking of "showing significant higher compilation times". I do not consider 600 and some milliseconds extra compilation time to be "significant". If milliseconds really count, you might delete all sorts of 'copyleft'-like blurb in all your header files, reduce all whitespace to single spaces and use single/few character symbols wherever possible. As I mentioned earlier, there are several good reasons against the "über" philosophy. I do not count saving 600 ms wall clock time as one of them.
Religious freedom is the freedom to say that two plus two make five.
-
Sort of in reverse direction, opposite intelisense way.
Is there?
concluding from discussion which "went sideways" ( am I allowed to have an opinion ?) there is no such option
May I please inquire are you stating the compiler you are utilizing provides no means to specify a list of directories to search for
#include's. That is difficult to believe. May I please inquire compiler purveyor.
