home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,806 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: #include and #include
   22 Jan 13 22:24:13   
   
   From: daniel.kruegler@googlemail.com   
      
   Am 22.01.2013 20:01, schrieb james.d.mclaughlin@googlemail.com:   
   > I was having a look through the header files for a SAT-solver that I   
   > needed to work out how to use, and which for some reason seemed to be   
   > using a lot of the C versions of the headers ( instead of   
   >  for instance) alongside C++ headers such as .   
   >   
   > Which is how I encountered this:   
   >   
   > #include    
   > #include    
   > #include    
      
   Am I understanding you correctly that this #include series is part of   
   headers that are from a thirdparty source (and not "yours")? If so, I   
   strongly recommend not to touch it unless you are considering to fork   
   and take full responsibility for what you are doing.   
      
   > Does anyone know of any reason why someone would want to #include both   
   > stdio.h and cstdio in the same file?   
      
   Maybe providing support for some very old compilers/libraries?   
      
   > More importantly, are there any   
   > potential pitfalls to doing this?   
      
   Nowadays (and given my general warning above) I would solely use the   
   officially supported  headers instead of the deprecated   
   compatibility <*.h> headers. I haven't seen problems with recent gcc or   
   MSVC versions at all. But this does not properly answer your question:   
   In fact, there is at least one possible pitfalls here when considering   
   to modify source code that you have not fully understood:   
      
   If you simply add std:: qualifiers to functions that are currently   
   invoked unqualified to stop ADL to work properly. You need to have a   
   careful look whether the correct action is indeed an explicit   
   qualification or adding a (local) using-directive or using-declaration   
   from namespace std. Problem here is that the wrong choice may still   
   compile but will presumably take a unwanted code flow. If you add such   
   using directives, ensure that you do that solely within function bodies   
   (It is possibly to to that also in a safe way within namespace scope,   
   but this requires a little bit of discipline to discriminate localized   
   "receiver" namespaces from other public API namespaces).   
      
   > A slightly less important question as well - does anyone know of any   
   > reason not to change  to  in the above?   
      
   Not except the general statements above.   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca