«

On 5 avr, 22:11, "Bryan Parkoff" <nos...@nospam.com> wrote:
> I want to know the best practice to write on both C / C++ source codes..
> The best practice is to ensure readable. Should left brace be after
> function or if on the same line or next line.

In the case of a function or a class, I'd say that there are
significant technical arguments for requiring 1) the opening
left brace on a line by itself, in column one, and 2) in the
case of functions, putting the return type on a line by itself,
above the function. (The idea is that the name, qualified by
the class if it is a member function, start in column 1.)

> For example...

> void Test( void) {
> int a = 5;
> printf( "%d\n", a);
> }

> or...

> void Test( void)
> {
> int a = 5;
> printf( "%d\n", a);
> }

> It applies to if. For example...

> if (a == 5) {
> printf( "%d\n", a);
> printf( "End...\n";
> }

> or...

> if (a == 5)
> {
> printf( "%d\n", a);
> printf( "End...\n";
> }

In this case, it really doesn't matter. Choose one, and stick
to it. (I would say that if the opening brace is on the same
line, you should require it always. I'd also require it always
in the other case, but it's less critical, since it is readily
apparent if it is missing.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On 5 avr, 22:11, "Bryan Parkoff" <nos...@nospam.com> wrote:
>> I want to know the best practice to write on both C / C++ source codes.
>> The best practice is to ensure readable. Should left brace be after
>> function or if on the same line or next line.
>
> In the case of a function or a class, I'd say that there are
> significant technical arguments for requiring 1) the opening
> left brace on a line by itself, in column one, and 2) in the
> case of functions, putting the return type on a line by itself,
> above the function. (The idea is that the name, qualified by
> the class if it is a member function, start in column 1.)

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?

<bracing examples snipped>

On Apr 7, 2:33 am, stan <smo...@exis.net> wrote:
> James Kanze wrote:
> > On 5 avr, 22:11, "Bryan Parkoff" <nos...@nospam.com> wrote:
> >> I want to know the best practice to write on both C / C++ source codes.
> >> The best practice is to ensure readable. Should left brace be after
> >> function or if on the same line or next line.

> > In the case of a function or a class, I'd say that there are
> > significant technical arguments for requiring 1) the opening
> > left brace on a line by itself, in column one, and 2) in the
> > case of functions, putting the return type on a line by itself,
> > above the function. (The idea is that the name, qualified by
> > the class if it is a member function, start in column 1.)

> 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).

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Apr 7, 2:33 am, stan <smo...@exis.net> wrote:
>> James Kanze wrote:
>> > On 5 avr, 22:11, "Bryan Parkoff" <nos...@nospam.com> wrote:
>> >> I want to know the best practice to write on both C / C++ source codes.
>> >> The best practice is to ensure readable. Should left brace be after
>> >> function or if on the same line or next line.
>
>> > In the case of a function or a class, I'd say that there are
>> > significant technical arguments for requiring 1) the opening
>> > left brace on a line by itself, in column one, and 2) in the
>> > case of functions, putting the return type on a line by itself,
>> > above the function. (The idea is that the name, qualified by
>> > the class if it is a member function, start in column 1.)
>
>> 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
While I'm primarily an emacs type, I use vim enough to get by and help
others sometimes but I'm not a vim guru. Thinking about it, I don't
actually remember ever using an actual vi.

I read that it's real hard/impossible to create a LALR or even yacc
compatible grammer for c or c++. 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? 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.

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:
> >> > On 5 avr, 22:11, "Bryan Parkoff" <nos...@nospam.com> wrote:
> >> >> I want to know the best practice to write on both C /
> >> >> C++ source codes. The best practice is to ensure
> >> >> readable. Should left brace be after function or if on
> >> >> the same line or next line.

> >> > In the case of a function or a class, I'd say that there are
> >> > significant technical arguments for requiring 1) the opening
> >> > left brace on a line by itself, in column one, and 2) in the
> >> > case of functions, putting the return type on a line by itself,
> >> > above the function. (The idea is that the name, qualified by
> >> > the class if it is a member function, start in column 1.)

> >> 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.)

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

> While I'm primarily an emacs type, I use vim enough to get by
> and help 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 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'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.)

> 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.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

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 help 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 help files terribly intuitive, what does the actual vi help 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.

On Apr 10, 5:19 am, stan <smo...@exis.net> wrote:
> James Kanze wrote:

[...]
> > 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

On the first Unix system I worked on, they had just finished
modifying the OS and the compiler, in order to be able to handle
programs as big as vi. Just to not have to use ed. The early
Intel editor I used ran on an 8 bit machine with 64 KB, using a
teletype as the console. In such an environment, it's hard to
do better than ed.

(FWIW: vi was the first full screen editor I ever used. Before
that, they were all command line editors, like ed.)

[...]
> I've never found the vim help files terribly intuitive, what
> does the actual vi help look like?

What help? There is no on line help.

> AFAIK there's no actual open vi, is that correct?

I think there was, at one time. But why bother? If you're
going to compile and install your own, you might as well make it
vim (or emacs). (Our production machines are Sun Sparcs,
running Solaris, and the only installed editors are those that
are bundled with Solaris. Which means the pure Berkley vi, just
as Bill Joy wrote it, when he was still a grad student, and
hadn't helped found Sun.)

> >> 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.

A C front end wouldn't be too difficult, despite the ambiguities
in the declaration syntax. C++ probably requires backtracking.
Still, I don't think it would be that difficult to get to the
stage of building a parse tree. The real fun would start when
you start to annotate it. Then comes name look up, function
overload resolution, and templates.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Apr 10, 5:19 am, stan <smo...@exis.net> wrote:
>> James Kanze wrote:
>
> [...]
>> I've never found the vim help files terribly intuitive, what
>> does the actual vi help look like?
>
> What help? There is no on line help.

What was I thinking?
>
>> AFAIK there's no actual open vi, is that correct?
>
> I think there was, at one time. But why bother? If you're
> going to compile and install your own, you might as well make it
> vim (or emacs). (Our production machines are Sun Sparcs,
> running Solaris, and the only installed editors are those that
> are bundled with Solaris. Which means the pure Berkley vi, just
> as Bill Joy wrote it, when he was still a grad student, and
> hadn't helped found Sun.)

I have vim. If available I might have loaded up vi to see how my hands
reacted. Actually my hands are confused as I jump between vim and emacs.
I might be risking permanent damage even trying a pure vi

<snip>
>> 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.
>
> A C front end wouldn't be too difficult, despite the ambiguities
> in the declaration syntax. C++ probably requires backtracking.
> Still, I don't think it would be that difficult to get to the
> stage of building a parse tree. The real fun would start when
> you start to annotate it. Then comes name look up, function
> overload resolution, and templates.

As I said, I think I might just give it a try.