title: Any downside to never creating ObjC files but always creating ObjC++ files instead?
body: <p>By default Xcode creates both an .h and and an .m file when you ask for a new ObjC class.
  Everything works fine until you need to refer to any C++ file elsewhere in your project and start #import ing it into either your .h or .m file</p>
  
  <p>At that point, the ObjC compiler gest utterly confused and throws mountains of parsing errors, and you the user (that is to say: me) get even more confused until such time it hits me: of course I should make that file an ObjC++ file instead.</p>
  
  <p>The options are:</p>
  
  <ol>
  <li>tell Xcode that this particular file, even though it is a .m file
  really is an ObjC++ file, or</li>
  <li>rename that file to .mm.</li>
  </ol>
  
  <p>The first option is not very palatable to me, because that file really <em>is</em> ObjC++ regardless of the what the project thinks it is. </p>
  
  <p>The second option is not good either as it screws up the Git repo which then 'forgets' that there used to be another .m file which really is the history of this 'new' .mm file.</p>
  
  <p>So I have decided from now on to always rename any .m file that Xcode creates for me to .mm first thing after creating it so that I won't loose the history. </p>
  
  <p>It has worked well for me so far, but I have this slight worry in my head, that there might be some corner case where I would really want to have an ObjC file and not an ObjC++ file.</p>
  
  <p>What would those corner cases be? Anyone is aware of any ObjC++ file which happens to NOT contain any C++ reference but would choke the ObjC compiler in some way, just by virtue of being an .mm file?</p>
  
  <p>And if there are no downside, why not just deprecate the use of .m forever and stick to .mm instead?</p>