| T O P I C R E V I E W |
| schoenherr |
Posted - Apr 30 2007 : 02:05:59 AM
having code like this
#include "foo.h"
#ifndef _BAR_H
#include "bar.h"
#endif
shows some unexpected behaviour in the outline window.
foo.h is located under the includes item but bar.h not.
bar.h can be found under the "#ifndef _BAR_H" item.
While i think that "if[n]def" items are usefull in general they are contra productive in such a situation
m.schoenherr
|
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - May 02 2007 : 10:27:19 AM
The following work around works nicely for me, and it is also self documenting:
#define VA_LIVE_OUTLINE_HEADERS 1
#ifdef VA_LIVE_OUTLINE_HEADERS
#ifndef _BAR_H
#include "bar.h"
#endif
#ifndef _FOO_H
#include "foo.h"
#endif
#ifndef _FRED_H
#include "fred.h"
#endif
#endif
the down side is that you get 2 top level entries in the Live Outline, one for the #define and one for the block of #includes inside the #ifdef. Swapping this to #if 1 would get you down to just one top level item, but be less immediately clear. |
| schoenherr |
Posted - May 02 2007 : 12:50:20 AM
accord is right, doing things this way the compile does not need to open the include file more than once. Off curse we have the same include guard inside the header file.
bar.h:
#pragma once
#ifndef _BAR_H
#define _BAR_H
...
#endif // _BAR_H
as you can see we also use the pragma once statement, but as accord mentioned this is non-standard. And the second reason is that we can satisfy pc-lint (from gimpel) which otherwise would complain about multiple includes.
reading your comments i assume we should not expect any changes for this problem, so my next question is: can you think of any kind of work around?
|
| feline |
Posted - May 01 2007 : 07:34:08 AM
I don't think I have ever seen the #include statements in the cpp file wrapped like that, but it does make sense.
Like you I am inclined to say that Live Outline is working correctly, if this is the case. True it looks a bit messy, but so does the cpp file  |
| accord |
Posted - Apr 30 2007 : 2:34:32 PM
I may wrong, but it seems schoenherr is using include guards in his cpp files. It is useful, because compiler do not need to open include files more than once, because the guard is in the cpp for faster compilation speeds. For example:
foo.cpp:
#include "foo.h"
#ifndef _BAR_H
#include "bar.h"
#endif
bar.h:
#define _BAR_H
// ...
In this way, you must enclose EVERY #include with this type of guard (except where the file includes itself (foo.h in our example)).
I am using #pragma once for this purpose. Because if a header is already included to a cpp file, the compiler will skip the file, without opening it again. #pragma once is a non-standard but widely supported preprocessor directive. MS, GCC and Intel compilers are accept it.
http://en.wikipedia.org/wiki/Pragma_once
Despite it, I think VA Outlining is working correctly when your include guard is considered as an ifndef. VAX can handle this as a special situation, but this may confuse a user who do not use this as include guard, but for something totally different stuff. He may wonder why his ifndef recognized as an include.
What do you think? |
| feline |
Posted - Apr 30 2007 : 10:58:43 AM
You mean like:
#define _BAR_H
#ifndef _BAR_H
#include <string.h>
#endif
// rest of header file
Why would someone do this?
I am used to seeing the entire header file wrapped in a #ifndef block, in which case Live Outline shows the entire file contents underneath a root node, which is the #ifndef statement.
I am not keen on asking for a special case to handle this common situation, since it might have unwanted side effects. |
| schoenherr |
Posted - Apr 30 2007 : 09:32:50 AM
you'r right,
but maybe vax can check if the checked define is defined in the included header itself??? |
| feline |
Posted - Apr 30 2007 : 09:10:24 AM
This is a little unexpected, but to me it makes sense. Consider the code:
#ifdef WIN32
#include <string>
#include <utility>
#endif
or even:
#ifndef WIN32
#include "unix_string.h"
#include "unix_utils.h"
#endif
as soon as you consider cross platform development the grouping of #include statements matters quite a lot. |
