[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: white space after star unexpected
From: |
david ingamells |
Subject: |
Re: white space after star unexpected |
Date: |
Thu, 19 Jun 2008 19:50:17 +0200 |
User-agent: |
Thunderbird 2.0.0.14 (X11/20080421) |
John E Hein wrote:
Moore, Robert wrote at 09:34 -0700 on Jun 19, 2008:
> I understand quite well.
>
> Indent needs to be smarter.
I don't think anyone would disagree (well, some would). But it has
never been a full c parser (let alone c++). No one has ever put forth
the patches to make that work. indent-ng would be an interesting SoC.
_______________________________________________
bug-indent mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-indent
Well! This has become the liveliest debate on indent for quite some time!
As Robert has said, Indent needs to be smarter. However there are some
obstacles to achieving that:
1) The parsing job for a smart indent is lots harder than for a C
compiler as it has to
* understand C and dialects thereof, as well as C++ (according to
lots many respondents)
* understand and manage white-space and various styles of
commenting, all of which a C compiler can just throw away.
* understand the preprocessor syntax and process it while still
keeping the original source file content intact.
* understand the mixes of all these items together. (eg what about
indenting inside #ifdef ... #else .. #endif)
2) The current code of indent is not at all well structured for
achieving this. The original developer said at the time that it was just
a quick hack, and it has been hacked ever since by hanging more and more
extra bits off it, most of which were done without fully understanding
the existing code.
I would love to have the time to work on an indent-ng, but with having
to earn a living in a very demanding job, maintain my home and give my
family the time they deserve I have no time over.
On the subject of the original mail that triggered all this, * is used
in C to declare a pointer, as in the prototype that was complained
about. It is also used as a dereferencing unary operator (e.g. *pi = 10
+ *pj;) and a multiplication binary operator (e.g. i = 10 * x;). Indent
is not smart enough to know the context unless it knows that the word
before the * is a type - which it has to be told as it doesn't
pre-process the code.
Regarding the request to change the behaviour, many users don't see that
space as "unexpected". I have see all of the following as preferred
styles for prototypes:
void func(type * p);
void func(type* p);
void func (type *p);
void func (type*); /* etc */
I personally don't consider any of them worth a flame war and I don't
think any of them worth my effort to extend indent to support them - but
that;'s maybe because my favourite IS supported :^). Anyone who does
care enough is welcome to submit an update and I will integrate it, but
the update must satisfy the regression test, have a new test added to
the regression test suite to prove the correctness of the update and the
documentation must be extended.
- Re: white space after star unexpected, (continued)
- Re: white space after star unexpected, Lin Ming, 2008/06/18
- Re: white space after star unexpected, david ingamells, 2008/06/18
- RE: white space after star unexpected, Moore, Robert, 2008/06/18
- Re: white space after star unexpected, david ingamells, 2008/06/18
- RE: white space after star unexpected, Moore, Robert, 2008/06/19
- RE: white space after star unexpected, John Hein, 2008/06/19
- RE: white space after star unexpected, Moore, Robert, 2008/06/20
- RE: white space after star unexpected, John E Hein, 2008/06/19
- RE: white space after star unexpected, Moore, Robert, 2008/06/20
- RE: white space after star unexpected, John E Hein, 2008/06/19
- Re: white space after star unexpected,
david ingamells <=