[cfe-dev] clang-format macros and typedefs

[Piotr Padlewski via cfe-dev]

Ok I totally understand it. So in my point of view clang-format is
extremally powerfull tool mainly because of configuration.

For example when colligues said "it would be nice to have one liner
getters, and to not merge normal functions into one line". On that point I
didn't belive that configuration is smart enough to handle that case, but
then I saw SFS_Inline was exactly the thing I was looking for.
So I don't know what is the real cost of adding new feature, I will
probably look at code some day and try to understand the real costs, but
anyway, clang-format is a very usefull tool, and I hope it will be more
configurable in the future.

Piotr

2015-11-13 21:12 GMT+01:00 Daniel Jasper <djasper at google.com>:

> Would be that much effort, but not sure clang-format wants to commit to
> it. At some point, I have actually noted down the requirements for
> additional options:
>
>
> http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>
> On Fri, Nov 13, 2015 at 9:00 PM, Piotr Padlewski <
> piotr.padlewski at gmail.com> wrote:
>
>> Hi folks,
>> so recently I was enforcing clang-format in the team that I work with,
>> and we found out 2 things that can't be configured and that are formated
>> not in the way that we would like to:
>>
>> 1. typedefs
>> so many times people use style like this for typedefs
>>
>> struct Predicate
>> {
>>     typedef std::shared_ptr<Predicate>            Ptr;
>>     typedef std::map<std::string, std::string>    Params;
>> };
>>
>> So as you can see the type names are aligned, and sometimes there is
>> larger space between name and type.
>> I guess this can be solved using using like this:
>> struct Predicate
>> {
>>     using Ptr         = std::shared_ptr<Predicate>;
>>     using Params = std::map<std::string, std::string>;
>> };
>>
>> because of the = align, but sometimes you can't use c++11 etc so it's not
>> the answer to every case.
>>
>> 2. The second thing is about macros and the operator ## - on default it
>> is glued
>>
>> #define CREATE_EVENT_ACCESSORS(Field, Type)
>>                                              \
>>     struct Field##Accessors
>>                                              \
>>     {
>>                                              \
>>         template <class E>
>>                                               \
>>         const Type &get(const E &e) const
>>                                              \
>>         {
>>                                              \
>>             return e.ref##Field();
>>                                               \
>>         }
>>                                              \
>>         template <class E>
>>                                               \
>>         void set(E &e, const Type &value)
>>                                              \
>>         {
>>                                              \
>>             e.set##Field(value);
>>                                               \
>>         }
>>                                              \
>>     };
>>
>> and there is no way to configure it as normal operator (with spaces
>> arround).
>> My question is: would it be simple to add this options? If it woudn't
>> require too much effort I would like to add this features.
>>
>> Piotr
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151113/e3f24715/attachment.html>