15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


#ifdef Gating in MFC

Adam Rabin -- arabin@erols.com
Sunday, March 16, 1997

[Mini-digest: 4 responses]

Surprise!  It's in version VC 5.0....

Bruce Degraaf wrote:
> 
> Environment: VC++ 4.2b NT 4.0
> 
> This is a general question about MFC. I haven't found an answer in the
> documentation and even a verbal query directly to a Microsoft
> representative (trade show) yielded a shrug. Maybe, before this list
> shuts down, I can get an answer.
> 
> MFC generates lots of header files. You know, class CXyz in files
> xyz.cpp and xyz.h. Why is there never any header file gating, as in:
> 
>         #ifndef XYZ_H   // or some other name derived from the filename
>         #define XYZ_H
>                 ...
>         #endif
> 
> ?
> 
> I know of shops which demand not only gating but have the rule that any
> inclusions DIRECTLY necessary for a file must be explicitly specified.
> Note that that means that some inclusions are written twice, once in the
> header file and once in the code file. Also, the code file may have a
> slightly different set of inclusions.
> 
> The disadvantage: longer compilation times
>         (C'mon guys, get a decent machine!)
> 
> The advantage: much easier maintenance
>         (If you want to use a class, just include its header file. No fuss. You
> don't even have to worry about inclusion order.)
> 
> I've tried introducing gates just to see if it would unearth some dark
> force. As expected, no effects. Also, as expected, changing inclusion
> order really fouls things up.
> 
> Any ideas?
> 
> Thanks!

-- 

____________________________
                            |     Rabin . Adam.          |
                          /)|    arabin@erols.com        |(\
                         / )|   Ph : 212-362-3672        |( \
                      __(  (|____________________________|)  )__
                     ((( \  \ >  /_)              ( \  < /  / )))
                     (\\\ \  \_/  /                \  \_/  / ///)
                      \          /                  \          /
                        \      _/                     \_      /
                         /    /                         \     \
                        /    /                            \    \
-----From: Mike Blaszczak 

At 08:31 3/13/97 -0500, Bruce Degraaf wrote:
>Environment: VC++ 4.2b NT 4.0

>This is a general question about MFC. I haven't found an answer in the
>documentation and even a verbal query directly to a Microsoft
>representative (trade show) yielded a shrug.

Do you know the name of the person who shrugged at you? At which show?

>MFC generates lots of header files. You know, class CXyz in files
>xyz.cpp and xyz.h. Why is there never any header file gating, as in:
>
>	#ifndef XYZ_H	// or some other name derived from the filename
>	#define XYZ_H
>		...
>	#endif
>
>?

It turns out that MFC doesn't generate _any_ header files. MFC is a class
library. It's the Wizards that generate header files.

You'll find that the Wizards in the 5.0 box generate #ifdefs, and also
use the more efficient #pragma once to make sure headers are only included
one time in a build.

In prior versions, you can trivially add the three lines of code
for your own self.


.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
       One is too many and a million is not enough.
-----From: kmg@gregcons.com (Kate Gregory)

While I call it guarding rather than gating, there is some of it in VC++
and in MFC. What's more, starting in 5.0 there's quite a bit of it generated
automatically. Since 5.0 is now going to subscribers and universal MSDN folks,
I can probably show you this:

// MainFrm.h : interface of the CMainFrame class
//
/////////////////////////////////////////////////////////////////////////////

#if !defined(AFX_MAINFRM_H__BC59B1C8_65C2_11D0_B02C_0080C81A3AA2__INCLUDED_)
#define AFX_MAINFRM_H__BC59B1C8_65C2_11D0_B02C_0080C81A3AA2__INCLUDED_

class CMainFrame : public CFrameWnd
{
... the usual stuff

#endif //
!defined(AFX_MAINFRM_H__BC59B1C8_65C2_11D0_B02C_0080C81A3AA2__INCLUDED_)


That's from a standard AppWizard app done with 5.0. Many folks object
to the, ah, inelegance of the define arguments, but at least you can
be sure they are unique.

There's a performance hit when you test inside the header, since
the preprocessor reads every line to see if it's the #endif or
not, so Microsoft has some of the guarding outside. You run the
risk of forgetting to test though, so I like the IBM way, which
is to test both inside and outside:

#ifndef xyz_h
#include "xyz.h"
#define xyz_h
#endif

and then xyz.h has this stuff too. That way you don't take
the performance hit unless a programmer forgot to test xyz_h.

Kate, who added and moved around a fair number of these guards for VC++ 4.0
-- 
Kate Gregory -- kate@gregcons.com --  http://www.gregcons.com  
Gregory Consulting: programming, training, and advice.
Editor, Visual C++ Developer. Author, Using Visual C++.
Speaking at Developer Days in Toronto March 19th.

-----From: Dariusz Kozlowski 

Bruce Degraaf wrote:
> 
> Environment: VC++ 4.2b NT 4.0
> 
> This is a general question about MFC. I haven't found an answer in the
> documentation and even a verbal query directly to a Microsoft
> representative (trade show) yielded a shrug. Maybe, before this list
> shuts down, I can get an answer.
> 
> MFC generates lots of header files. You know, class CXyz in files
> xyz.cpp and xyz.h. Why is there never any header file gating, as in:
> 
>         #ifndef XYZ_H   // or some other name derived from the filename
>         #define XYZ_H
>                 ...
>         #endif
> 
> ?
> 
> I know of shops which demand not only gating but have the rule that any
> inclusions DIRECTLY necessary for a file must be explicitly specified.
> Note that that means that some inclusions are written twice, once in the
> header file and once in the code file. Also, the code file may have a
> slightly different set of inclusions.
> 
> The disadvantage: longer compilation times
>         (C'mon guys, get a decent machine!)



------------------------------------------------
If you worry about compilation time do:

---in XYZ.H
#deife XYZ_H 

---elsewhere
#ifndef XYZ_H
#include "xyz.h"
#endif

i prefer my computer to compile a few second longer rather than type
#ifndef ... every time i include a header.
-------------------------------------------------
darek





DFPav@aol.com
Thursday, March 20, 1997

In a message dated 97-03-15 23:20:29 EST, you write:

>  Environment: VC++ 4.2b NT 4.0
>  
>  MFC generates lots of header files. You know, class CXyz in files
>  xyz.cpp and xyz.h. Why is there never any header file gating, as in:
>  
>  	#ifndef XYZ_H	// or some other name derived from the filename
>  	#define XYZ_H
>  		...
>  	#endif
>  
>  ?
>  
>  I know of shops which demand not only gating but have the rule that any
>  inclusions DIRECTLY necessary for a file must be explicitly specified.
>  Note that that means that some inclusions are written twice, once in the
>  header file and once in the code file. Also, the code file may have a
>  slightly different set of inclusions.
>  

>  Any ideas?
>  
>  Thanks!
>  
1.I had never heard a term for that before but I saw that being done in the
standard run time library headers (stdio.h, etc) and thought that it was a
good idea to do on 
my own and have tried to get the others here to adopt that practice, as well.

2. I like to use a test file that has nothing but an include of a header
file.  I try to compile this (the IDE won't allow you to try to compile a
header) and I expect the
headers to compile.  All of the files they are dependent on should be listed
there.

3.  As far a double gating goes. why?  This means that other files have to
know what another file's symbols are.  The compilation may be miliseconds
faster but to me it 
seems that to do this is similar to exposing the data members of your class.
 I just wouldn't do it.  I would want to encapsulate these symbols.

Dan




Mike Blaszczak -- mikeblas@nwlink.com
Sunday, March 23, 1997

[Mini-digest: 2 responses]

At 12:50 3/20/97 -0500, DFPav@aol.com wrote:

>3.  As far a double gating goes. why? This means that other files have to
>know what another file's symbols are. The compilation may be miliseconds
>faster but to me

If you invent a standard to readily identify the symbol a 
given file uses, you really have nothing to worry about. You can
remember the symbol after a glance at the name of the file.

>it seems that to do this is similar to exposing the
>data members of your class.

Just like any other technique of any other art in the world, everything
has risks, benefits, and disadvantages.  The idea is to practice
the art until you understand those risks and benefits and disadvantages
so that you can avoid them, use them, and apply them to your greatest
benefit.

There are times when it's appropriate to use a technique that you might
not like. Just because you don't like a technique doesn't mean that
it is inappropriate for everyone in all circumstances. Even techniques
that are stupid and useless, like calling TerminateThread(), can find
application in some very limited (and perhaps even contrived)
circumstances.

That mentality, though, seems to have become rampant among PC software
developers lately. I talked with a fellow, recently, who hated CString
because it provided an LPCTSTR cast operator. He didn't like that because
"pointers are danagerous", he said.  Goodness: what does this fellow
think of loops? Or typing with a keyboard?  Or driving a car, or taking
a walk in the park?

> I just wouldn't do it.  I would want to encapsulate these symbols.

Again, please read up on the #pragma once directive.


.B ekiM
  Crotch Rocket   / Full-Body Rocket / Trip Report Central!
95 Honda VFR-750F /   94 Mazda RX-7  / http://www.nwlink.com/~mikeblas/
                 Less work, more hockey!
  These words are my own - I do not speak on behalf of Microsoft.
-----From: schwarz@oak.pacsim.com

>In a message dated 97-03-15 23:20:29 EST, you write:
>
>>  Environment: VC++ 4.2b NT 4.0
>>  
>>  MFC generates lots of header files. You know, class CXyz in files
>>  xyz.cpp and xyz.h. Why is there never any header file gating, as in:
>>  
>>  	#ifndef XYZ_H	// or some other name derived from the filename
>>  	#define XYZ_H
>>  		...
>>  	#endif
>>  
>>  ?
>>  
>>  I know of shops which demand not only gating but have the rule that any
>>  inclusions DIRECTLY necessary for a file must be explicitly specified.
>>  Note that that means that some inclusions are written twice, once in the
>>  header file and once in the code file. Also, the code file may have a
>>  slightly different set of inclusions.
>>  
>
>>  Any ideas?
>>  
>>  Thanks!
>>  
>1.I had never heard a term for that before but I saw that being done in the
>standard run time library headers (stdio.h, etc) and thought that it was a
>good idea to do on 
>my own and have tried to get the others here to adopt that practice, as well.
>
>2. I like to use a test file that has nothing but an include of a header
>file.  I try to compile this (the IDE won't allow you to try to compile a
>header) and I expect the
>headers to compile.  All of the files they are dependent on should be listed
>there.
>
>3.  As far a double gating goes. why?  This means that other files have to
>know what another file's symbols are.  The compilation may be miliseconds
>faster but to me it 
>seems that to do this is similar to exposing the data members of your class.
> I just wouldn't do it.  I would want to encapsulate these symbols.
>
>Dan
>
>

One More little tid-bit.

If the ifndef is only inside the included header,  The header must be parced
each time even if the #ifndef fails, looking for the #endif.  If the i#fndef
is around the include
and fails the include file is passed over, with large Class headers in lots
of modules,
this can reduce compilation time.

SS

  





Become an MFC-L member | Вернуться в корень Архива |