PROS/CONS: #define BEGIN {

[Mike Malone]

A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:

#define BEGIN {
#define ENG }
#define EQ ==
etc.

My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").

Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:

* Won't work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers

* Does not check for mismatches (e.g., "{" vs. "END").

* Does not prevent use of {, }, ==, etc., just adds alternatives.

* Requires re-training of C developers who are used to standard C syntax.

[Jarno A Wuolijoki]

On Tue, 21 Dec 2004, Michael Mair wrote:

Jarno A Wuolijoki wrote:

s/class/struct/g if feeling nitpicky. I'm fairly positive that, given some
time, I can craft a similar case in the topical language as well.

[...] Otherwise, you would not hunt for a bug but for a syntax error.

Are you absolutely sure that you want to turn this into a discussion
on whether or not a failure to compile can be counted as a bug or did
you just get baited by the "if feeling nitpicky"-part?-)
Anyway, if I wanted to go on with this, I'd probably make the following
case (which I obviously don't as otherwise I'd had it written here
right after these words):

int main(void) {
#if PLATFORM_Z
int a[] = {0);
#else
int a[] = {0};
#endif
return 0;
}

Is this a syntax error or a bug? Or perhaps a bug that shows up as
a syntax error under certain conditions?

[Keith Thompson]

Michael Mair <Mi**********@i nvalid.invalid> writes:

Jarno A Wuolijoki wrote:

On Tue, 21 Dec 2004, Charlie Gordon wrote:

"Jarno A Wuolijoki" <jw******@cs.He lsinki.FI> wrote
For an oppsite example, Today I debugged about half an hour a piece
of code that had ')' instead of '}' at the end of a block. Funny how
I hadn't realized before how similar to each other they can be made to
look like..

Half an hour on this ???
What editor do you use ?

Ultraedit. (it probably supports brace matching but I just didn't
realize that at the moment)

IIRC, it does.

What is your compiler / environment ?

gcc.

Which did not give you a parse error?

What was the error message at compile time ?

Something about some offtopic standard forbidding initialization
inside classes (I didn't say it was C..). Naturally, the error
pointed to a different source file and the main false track was that
I expected having actually put it in inside a class due to other
reasons I'm not going to enumerate here.

Sounds like a problem of messy coding.

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Mair]

Keith Thompson wrote:

Michael Mair <Mi**********@i nvalid.invalid> writes:

Jarno A Wuolijoki wrote:

On Tue, 21 Dec 2004, Charlie Gordon wrote:

"Jarno A Wuolijoki" <jw******@cs.He lsinki.FI> wrote

>For an oppsite example, Today I debugged about half an hour a piece
>of code that had ')' instead of '}' at the end of a block. Funny how
>I hadn't realized before how similar to each other they can be made to
>look like..

Half an hour on this ???
What editor do you use ?

Ultraedit. (it probably supports brace matching but I just didn't
realize that at the moment)

IIRC, it does.

What is your compiler / environment ?

gcc.

Which did not give you a parse error?

What was the error message at compile time ?

Something about some offtopic standard forbidding initialization
inside classes (I didn't say it was C..). Naturally, the error
pointed to a different source file and the main false track was that
I expected having actually put it in inside a class due to other
reasons I'm not going to enumerate here.

Sounds like a problem of messy coding.

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.
The "messy" referred to the fact that a different source
file was implied. This usually happens only if the error
occurred in a header file. Thus, the header file was not
checked for errors and not even included into some sort of
test translation unit which includes all the headers to
check for syntax errors in the headers.
<OT>
On errors like that, gcc usually dies with a parse error.
On parse errors, you easily can check where the whole
problem occurs by commenting out large chunks of code
until it runs. If the whole payload of the translation
unit is gone, then you move on to the headers. Why waste
time with unstructured searching when you cannot spot
the reason for the error at once?
</OT>

As one can see from the example brought by Jarno A
Wuolijoki, it was not a bug we were talking about but
a syntax error. Happens to me, too. My objection was
rather to the term bug. }/) mismatches happen just like
other syntax errors and can be found easily.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

Michael Mair <Mi**********@i nvalid.invalid> writes:
[...]

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.

[...]

Some of us (presumably including Jarno) have a more expansive
definition of "bug".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Mair]

Keith Thompson wrote:

Michael Mair <Mi**********@i nvalid.invalid> writes:
[...]

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.

[...]

Some of us (presumably including Jarno) have a more expansive
definition of "bug".

I go by the one from the jargonfile:

http://www.catb.org/~esr/jargon/html/B/bug.html :
"
bug: n.

An unwanted and unintended property of a program or piece of
hardware, esp. one that causes it to malfunction. Antonym of feature.
Examples: “There's a bug in the editor: it writes things out backwards.”
“The system crashed because of a hardware bug.” “Fred is a winner, but
he has a few bugs” (i.e., Fred is a good guy, but he has a few
personality problems).

[snip: Historical Notes]
"

Source code which does not compile is not exactly a program
in my book.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

[Chris Croughton]

On Tue, 21 Dec 2004 23:27:39 GMT, Keith Thompson
<ks***@mib.or g> wrote:

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

The following (deliberately non-indented) faulty program gives a number
of errors, on no compiler I have here does it say "you missed off a }".
On the other hand, I had to force vim (the editor I use) to not indent
it, the error was very obvious when it indented automatically.

void func(char *ptr)
{
if (ptr)
{
*ptr = 'a';
}

char buff[2];

int main(void)
{
func(buff);
}

Some compilers will give "parse error before 'char'" on the line
declaring buff, some will give "parse error before '{'" on the line
after "int main", at least one C99 compiler gives "parse error at end of
input" at the end of the file, and a C89 compiler (gcc v3 with -ansi
-pedantic) gives:

warning: ISO C89 forbids mixed declarations and code
warning: ISO C forbids nested functions

Chris C

[Albert van der Horst]

In article <Pi************ *************** ****@sbz-31.cs.Helsinki. FI>,
Jarno A Wuolijoki <jw******@cs.He lsinki.FI> wrote:

On Tue, 21 Dec 2004, Richard Bos wrote:

Thomas Stegen <th***********@ gmail.com> wrote:

> Well, how often do you have nesting errors? I can't remember when I
> last saw or heard of one. And it is not obvious at all to me that
> BEGIN and END are easier to remember to put in than { and }.

Point in case: I was hand-hacking a Windows resource file last week.
Windows resource files use BEGIN and END. I forgot nearly all the
second-level BEGINs, because to my mind, POPUP plus indentation already
defined the beginning of the block. Using C, I hardly have to think to
just put the { at the end of the if/while/for-line.
Ok, this may be influenced by me being more used to { } than to BEGIN
END, but it's enough to show that BEGIN and END aren't inherently less
nesting-error-prone.

For an oppsite example, Today I debugged about half an hour a piece
of code that had ')' instead of '}' at the end of a block. Funny how
I hadn't realized before how similar to each other they can be made to
look like..

Standard technique for when it takes more than 5 minutes to
understand a syntax error.
(Most implementations allow this one way or another.)
Run the program through the preprocessor only, typical -E.
Then through a beautifier (cb, indent).
It pays off to have a small script in place for this. At least
for someone elses code.

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

[Kevin Handy]

Mike Malone wrote:

A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:

#define BEGIN {
#define ENG }
#define EQ ==
etc.

My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").

Why not go all the way, and just program in PASCAL or COBAL?
If you don't like the language, why use it?
Why waste time doing a half-assed job of switching to
anopther language?

I assume you plan on never using any code analysis tools,
which are likely to barf on the hacked-up syntax.

I also assume you don't expect any outsiders to ever see your
code, especially people buying your product. It would be a
BIG negitive to me if I saw that stuff.