[PATCH] [Object] Split the ELF interface into 3 parts.

[Sean Silva]

On Wed, Jul 31, 2013 at 2:35 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > Probably none, but I don't see why we should truncate unless there's a
> good reason. This class is going to be 16 bytes on a 64 bit system anyway.
>
> ok
>
> > ================
> > Comment at: include/llvm/Object/ELF.h:365
> > @@ -786,4 +364,3 @@
> >
> > -  Elf_Rel_Iter endELFRel(const Elf_Shdr *sec) const {
> > -    return Elf_Rel_Iter(sec->sh_entsize, (const char *)
> > -                        (base() + sec->sh_offset + sec->sh_size));
> > +  Elf_Rel_Iter end_rel(const Elf_Shdr *sec) const {
> > +    return Elf_Rel_Iter(sec->sh_entsize,
> > ----------------
> > Rafael Ávila de Espíndola wrote:
> >> Having ELF in the name of this methods would be redundant, so I agree
> with dropping it, but why the switch away from CamelCase?
> > Because all the other iterator functions are like this.
>
> This is one part of the codebase that is fairly inconsistent. We have
> alias_begin, beginSequence and begin_symbols. All of which don't
> follow the style :-(. Using beginFoo and endFoo still look to be the
> closest.
>

Personally, the alias_begin style is the only convention that I
(explicitly) remember ever seeing anywhere in the codebase to indicate
STL-like semantics. All of the core LLVM classes use this style
(Value::use_begin, Function::arg_begin, etc.); I don't see any reason to
deviate.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130731/861df6c2/attachment.html>