PHWinfo - Afficher un message - Left brace on a single line -- Question

10/04/2008, 05h19

James Kanze wrote:
> On Apr 8, 1:27 am, stan <smo...@exis.net> wrote:
>> James Kanze wrote:
>> > On Apr 7, 2:33 am, stan <smo...@exis.net> wrote:
>> >> James Kanze wrote:
<snip>
>> >> While I prefer the above on a readibility/cosmetic pov, I
>> >> don't think I've ever seen an actual technical argument other
>> >> than it makes finding functions easier when searching by way
>> >> of regular expressions. Is that the reason or are there other
>> >> justifications?
>
>> > That's the reason. You can search for the definition, without
>> > getting any non-definition use. Also, vi uses a { in column one
>> > to recognize the start of a function body, and in practice,
>> > there'll be times that you'll have to edit with vi (or ed, which
>> > follows the same rules).
>
>> While I've been there, writing code with ed seems a little too manly

>
> You should have used the editor on the original Intel
> development systems, then. After that, ed seems like something
> for sissies. (The basic philosphy was something like ed, but it
> allowed multiple commands on the same line, with constructs for
> looping, etc. A typical command line looked a bit like
> transmission noise, and an error in a single character could
> wreck havoc in your file.)

I've used something that sounds very similar for some old embedded
coumputers. Actually the word embedded never came up, they were just the
command and control computers. Editing wasn't my biggest problem; they
had an actual core memory and when a wire broke I had to take it down to
a repair facility and solder the broken wire with a microscope. The only
good thing was that the facility was just far enough away to make it a
two day trip. I usually spent the first day repairing and the second day
in the club

>
> Seriously, I don't think I've used ed much except for very small
> editing jobs in a script.

I really think if you had to write a very big program you would save
time writing an editor first

>> While I'm primarily an emacs type, I use vim enough to get by
>> and others sometimes but I'm not a vim guru. Thinking
>> about it, I don't actually remember ever using an actual vi.
>
> I still use it fairly often. Or production machines have a very
> limited environment, and we're not allowed to install just
> anything on them.

I never turn on compatibility. I might one day just to see if I can
still get around without banging into things to badly. I've never found
the vim files terribly intuitive, what does the actual vi look
like? AFAIK there's no actual open vi, is that correct?

>> I read that it's real hard/impossible to create a LALR or even
>> yacc compatible grammer for c or c++.
>
> That's actually true for a lot of languages---even Pascal. The
> C/C++ declaration syntax, however, seems to be designed
> intentionally to make parsing difficult.

I'm pretty comfortable with yacc/bison and flex and I've done many
little language things so I have some feeling for working on front ends.
However the urge to simply write a c or c++ front end never really
bubbled up to the top of my todo list.

>> I've never sat down to try but my understanding is there are
>> dark corners that cause problems. Is It possible to write a
>> yacc grammer that simply recognizes function and class
>> definitions?
>
> If you're handling pre-processed input (or don't mind screwing
> up if someone was stupid enough to use the preprocessor in a way
> that messed with this), you can come pretty close with just
> regular expressions and a state machine. If you're interested,
> you might look at the code for my kloc program
> (http://kanze.james.neuf.fr/code-en.html, then look for kloc in
> the Exec directory). It collects a number of statistics (more
> or less accurately), such as the number of functions and the
> number of class definitions (those should be very accurate).
> It uses only lex and a very simple state machine; I won't say
> that it can't be fooled, but it does seem to work most of the
> time. (I think. It's really very old code, and I've not really
> verified it with templates. I did expand it to handle
> namespaces, but I wouldn't be surprised if it didn't get
> confused by template definitions which contain parentheses.)

Thanks, I'll take a look. I've always found another solution every time
I came upon the need but one of these days I really do need to sit down
and take a look at this problem; if just for the learning. Last time I
needed something I hacked together a script to read a tags file. Seems
like the problem comes up often enough for me to add something a little
better to my toolbox. Time always seems to work against me when the
problem is actually staring at me.

>> I know there are programs that detect functions but I believe
>> they all do some clever pattern matching; I'm not aware of any
>> that try actually parsing.
>
> Any opening brace at namespace scope is either a class or a
> function definition. Knowing that you're at namespace scope
>
> The syntax for opening a namespace scope
> is pretty simple, so you should be able to track those
> (supposing no messing around with the preprocessor, of course)
> and `extern "C"' blocks. After that, any opening brace at
> namespace scope is the start of either a function, a class or an
> enum definition.

Sounds like a good start for my next rainy day project. Thanks.

10/04/2008, 05h19	#13
stan Messages: n/a Hébergeur:	Re: Left brace on a single line -- Question James Kanze wrote: > On Apr 8, 1:27 am, stan <smo...@exis.net> wrote: >> James Kanze wrote: >> > On Apr 7, 2:33 am, stan <smo...@exis.net> wrote: >> >> James Kanze wrote: <snip> >> >> While I prefer the above on a readibility/cosmetic pov, I >> >> don't think I've ever seen an actual technical argument other >> >> than it makes finding functions easier when searching by way >> >> of regular expressions. Is that the reason or are there other >> >> justifications? > >> > That's the reason. You can search for the definition, without >> > getting any non-definition use. Also, vi uses a { in column one >> > to recognize the start of a function body, and in practice, >> > there'll be times that you'll have to edit with vi (or ed, which >> > follows the same rules). > >> While I've been there, writing code with ed seems a little too manly > > You should have used the editor on the original Intel > development systems, then. After that, ed seems like something > for sissies. (The basic philosphy was something like ed, but it > allowed multiple commands on the same line, with constructs for > looping, etc. A typical command line looked a bit like > transmission noise, and an error in a single character could > wreck havoc in your file.) I've used something that sounds very similar for some old embedded coumputers. Actually the word embedded never came up, they were just the command and control computers. Editing wasn't my biggest problem; they had an actual core memory and when a wire broke I had to take it down to a repair facility and solder the broken wire with a microscope. The only good thing was that the facility was just far enough away to make it a two day trip. I usually spent the first day repairing and the second day in the club > > Seriously, I don't think I've used ed much except for very small > editing jobs in a script. I really think if you had to write a very big program you would save time writing an editor first >> While I'm primarily an emacs type, I use vim enough to get by >> and others sometimes but I'm not a vim guru. Thinking >> about it, I don't actually remember ever using an actual vi. > > I still use it fairly often. Or production machines have a very > limited environment, and we're not allowed to install just > anything on them. I never turn on compatibility. I might one day just to see if I can still get around without banging into things to badly. I've never found the vim files terribly intuitive, what does the actual vi look like? AFAIK there's no actual open vi, is that correct? >> I read that it's real hard/impossible to create a LALR or even >> yacc compatible grammer for c or c++. > > That's actually true for a lot of languages---even Pascal. The > C/C++ declaration syntax, however, seems to be designed > intentionally to make parsing difficult. I'm pretty comfortable with yacc/bison and flex and I've done many little language things so I have some feeling for working on front ends. However the urge to simply write a c or c++ front end never really bubbled up to the top of my todo list. >> I've never sat down to try but my understanding is there are >> dark corners that cause problems. Is It possible to write a >> yacc grammer that simply recognizes function and class >> definitions? > > If you're handling pre-processed input (or don't mind screwing > up if someone was stupid enough to use the preprocessor in a way > that messed with this), you can come pretty close with just > regular expressions and a state machine. If you're interested, > you might look at the code for my kloc program > (http://kanze.james.neuf.fr/code-en.html, then look for kloc in > the Exec directory). It collects a number of statistics (more > or less accurately), such as the number of functions and the > number of class definitions (those should be very accurate). > It uses only lex and a very simple state machine; I won't say > that it can't be fooled, but it does seem to work most of the > time. (I think. It's really very old code, and I've not really > verified it with templates. I did expand it to handle > namespaces, but I wouldn't be surprised if it didn't get > confused by template definitions which contain parentheses.) Thanks, I'll take a look. I've always found another solution every time I came upon the need but one of these days I really do need to sit down and take a look at this problem; if just for the learning. Last time I needed something I hacked together a script to read a tags file. Seems like the problem comes up often enough for me to add something a little better to my toolbox. Time always seems to work against me when the problem is actually staring at me. >> I know there are programs that detect functions but I believe >> they all do some clever pattern matching; I'm not aware of any >> that try actually parsing. > > Any opening brace at namespace scope is either a class or a > function definition. Knowing that you're at namespace scope > > The syntax for opening a namespace scope > is pretty simple, so you should be able to track those > (supposing no messing around with the preprocessor, of course) > and `extern "C"' blocks. After that, any opening brace at > namespace scope is the start of either a function, a class or an > enum definition. Sounds like a good start for my next rainy day project. Thanks.