[PATCH] extracting swapStruct into include/llvm/Support/MachO.h (no functional change)

Duncan P. N. Exon Smith dexonsmith at apple.com
Mon Jul 7 16:33:40 PDT 2014


> On 2014-Jul-04, at 01:26, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> 
> Hello Duncan,
> 
> Ping regarding that proposed change.
> 
> Also updating the email subject to be a bit more descriptive.
> 
> 
> -----Original Message-----
> From: Artyom Skrobov [mailto:Artyom.Skrobov at arm.com] 
> Sent: 23 June 2014 15:37
> To: 'Duncan P. N. Exon Smith'
> Cc: llvm-commits
> Subject: RE: [PATCH] Some code improvements (no functional change)
> 
> Thank you Duncan!
> Committed as r210973--r210980, except for the namespace-related changes that
> you pointed out.
> 
> While committing this, I realised that the instantiations of swapStruct() in
> tools/lld/lib/ReaderWriter/MachO/MachONormalizedFileBinaryUtils.h are
> identical to the private implementations in lib/Object/MachOObjectFile.cpp
> 
> Should perhaps these swapStruct()'s be extracted into
> include/llvm/Support/MachO.h ?
> Attaching the patch for review.

Sorry, I've lost context on this -- can you re-attach the patch?

> 
> 
>>> Index: lib/Object/MachOObjectFile.cpp
>>> ===================================================================
>>> --- lib/Object/MachOObjectFile.cpp	(revision 210891)
>>> +++ lib/Object/MachOObjectFile.cpp	(working copy)
>>> @@ -24,9 +24,6 @@
>>> #include <cstring>
>>> #include <limits>
>>> 
>>> -using namespace llvm;
>>> -using namespace object;
>>> -
>> 
>> This cleanup seems unrelated.  You should leave this out.
> 
> Indeed this wasn't related to extracting SwapValue out of that file; but is
> this cleanup any controversial?
> 
> 
>>> Index: lib/Object/MachOUniversal.cpp
>>> ===================================================================
>>> --- lib/Object/MachOUniversal.cpp	(revision 210891)
>>> +++ lib/Object/MachOUniversal.cpp	(working copy)
>>> @@ -19,30 +19,26 @@
>>> #include "llvm/Support/Host.h"
>>> #include "llvm/Support/MemoryBuffer.h"
>>> 
>>> -using namespace llvm;
>>> -using namespace object;
>>> +namespace llvm {
>>> +namespace object {
>> 
>> I don't see a reason to change the namespace setup, but even if it's a
>> good idea it shouldn't be part of this commit.
>> 
>>> @@ -165,3 +161,6 @@
>>>   }
>>>   return object_error::arch_not_found;
>>> }
>>> +
>>> +} // end namespace object
>>> +} // end namespace llvm
>> 
>> This is part of the unrelated change above; remove it too.
> 
> The only reason for that change was to be consistent with the other file.
> Same as yourself, I'm not a big fan of "using" statements :-)
> 
> Is it OK to commit these two namespace changes?

Can't remember if I replied to this part already.  Coding standards say
that `using` clauses should be used in source files when (and only when)
implementing parts of that namespace [1].  Relevant text quoted here:

> The exception to the general rule (i.e. it’s not an exception for the
> std namespace) is for implementation files. For example, all of the code
> in the LLVM project implements code that lives in the ‘llvm’ namespace.
> As such, it is ok, and actually clearer, for the .cpp files to have a
> 'using namespace llvm;' directive at the top, after the #includes. This
> reduces indentation in the body of the file for source editors that
> indent based on braces, and keeps the conceptual context cleaner. The
> general form of this rule is that any .cpp file that implements code in
> any namespace may use that namespace (and its parents’), but should not
> use any others.

So I think `MachOUniversal.cpp` is correct as is.  Personally, I prefer
reading/writing `using` clauses for nested namespaces as:

    using namespace llvm;
    using namespace llvm::object;

http://llvm.org/docs/CodingStandards.html#do-not-use-using-namespace-std



More information about the llvm-commits mailing list