473,326 Members | 2,111 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

PROS/CONS: #define BEGIN {

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.
Nov 14 '05 #1
57 7393
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 END }
#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.


Why don't you use a sed script to modify some of your code
and see how you like it?

It takes a while to get used to it
and you will be obliged to invest some time
to adjust your tools to work with it
but, in the end, you will find that
people can get used to just about anything
and that they actually become quite fond of these things.

But, generally, I don't think that it's a good idea
to clutter up your macro namespace unnecessarily.
I believe that "coding style enforcement"
is a source of mischief and such issues
should be left up to the individual programmer.

Nov 14 '05 #2
"Mike Malone" <mr*@prodigy.net> writes:
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 ==


The third is similar to the equivalents given in iso646.h:

and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=

I don't know whether that's an argument for or against.
--
Just another C hacker.
Nov 14 '05 #3
Pro - fewer nesting errors...

"Mike Malone" <mr*@prodigy.net> writes:
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.

Nov 14 '05 #4
"Mike Malone" <mr*@prodigy.net> writes:
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?

[...]

There are no good reasons to do this.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '05 #5
Many moons ago someone suggested just this, it was called 'Easy C' and it turned
C into a weird form of Pascal, there were macros and even a small preprocessor.
There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer wheels were removed

The big problem for C programmers is that programs became verbose without saying
more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.
Nov 14 '05 #6

"Mike Malone" <mr*@prodigy.net> a écrit dans le message de
news:dY******************@newssvr19.news.prodigy.c om...
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.


One thing that could be done to make more readable code, instead of
modifying original C syntax, would be to use conventions of identation and
comments.
That helps A LOT MORE than those kind of tricks, in my opinion.

K
Nov 14 '05 #7

"Peter Hickman" <pe***@semantico.com> wrote in message
news:41***********************@news.easynet.co.uk. ..
Many moons ago someone suggested just this, it was called 'Easy C' and it turned C into a weird form of Pascal, there were macros and even a small preprocessor. There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer wheels were removed
The big problem for C programmers is that programs became verbose without saying more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much

more space.

And clutters up the view on the actual *payload*.
Nov 14 '05 #8
On Tue, 14 Dec 2004 03:18:33 GMT, Mike Malone
<mr*@prodigy.net> wrote:
A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:
How about your colleague learning C instead? Yes, it is possible to
write 'unreadable' C code, but that is possible with any language,
putting macros round constructs doesn't help.
#define BEGIN {
#define ENG }
#define EQ ==
etc.
I've seen it done. But why not counter-suggest that EQ is not
'readable' and it should be EQUALS, NOT_EQUALS, GREATER_THAN etc.?
Don't forget INTEGER instead of int, CHARACTER instead of char, PLUS and
MINUS, INCREMENT and DECREMENT...

You could make the language 'readable' as English like that, and also
increase your source code size by an order of magnitude, thus pleasing
management who will think you are working harder...
My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").
Mine as well.
Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:
I can't see any good reasons to do it. If you want to program in Pascal
or Fortran, get a compiler for the language you like.
* Won't work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers
Syntax-aware editors alone are a big reason to not do it, they often
save a lot of time all by themselves (for instance automatically
indenting and highlighting -- or rather failing to highlight -- typos in
keywords while typing).
* Requires re-training of C developers who are used to standard C syntax.


And retraining of people who have learned with the odd syntax.

Don't forget source-level debuggers, which are often confused by macros.

Chris C
Nov 14 '05 #9
dandelion wrote:
"Peter Hickman" <pe***@semantico.com> wrote in message
Many moons ago someone suggested just this, it was called 'Easy C'
and it turned C into a weird form of Pascal, there were macros and
even a small preprocessor. There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer
wheels were removed

The big problem for C programmers is that programs became verbose
without saying more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much

more space.

And clutters up the view on the actual *payload*.


At least format the quasi-Pascal properly:

IF x eq 1 THEN BEGIN
puts("The value is 1"); END;

or better:

IF x eq 1 THEN puts("The value is 1");

which still is neither fish nor fowl, real Pascal being:

IF x = 1 THEN writeln('The value is 1');

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #10
Why not go all the way? With a little cleverness, you could have BASIC.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Nov 14 '05 #11
In <dY******************@newssvr19.news.prodigy.com > "Mike Malone" <mr*@prodigy.net> writes:
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?


ANY usage of the C preprocessor that messes with the language syntax
should be avoided, unless the redeeming benefits are great enough to
compensate for the loss in program readability. And this kind of silly
substitutions have exactly zilch redeeming benefits.

Apparently, the original implementation of the Bourne shell was made
using a header file named "algol.h", whose purpose should be obvious
from its name. The end result was that no one wanted to maintain that
program, so it had to be retranslated to proper C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #12
Bart wrote:
Peter Hickman wrote:
converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.
Proper English words are, in my opinion,
more readable than lots of punctuation,
even if it takes more space
and C does seem to have far too many unnecessary symbols,
such as semicolons.

The C syntax looks like something
that was hastily knocked up one afternoon
and nobody has updated it since.


It certainly was *not*.
It was very carefully crafted
to take advantage of the ASCII character set
and to minimize the number of keystrokes
which you would realize was a very important consideration
if you had ever tried to program at a teletype terminal.
However that *is* the C language and most seem happy with it.

Tinkering with bits of syntax using DEFINEs
is likely to be unsatisfactory;
the above example seems a mix of FORTRAN, PASCAL and C.

Either use a different language
or a formal language extension that uses software
to convert your favorite syntax into standard C (my pet project).


I agree that the C preprocessor
is a poor language translation tool.
Nov 14 '05 #13
On Wed, 15 Dec 2004 00:05:18 +0100, "KiLVaiDeN"
<Ki*******@CaRaMaiL.CoM> wrote:
"Bart" wrote...
Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.


I think it'd be very annoying after a while to see tons of "BEGIN"
everywhere on the code..

Imagine something like ( useless code ) :

while(true)
{
do_something();
if(something is true)
{
do_something_else();
increment_something();
}
else
{
decrement_something();
do_nothing();
}
}

Would translate into something like :

while(true)
BEGIN
do_something();
if(something is true)
BEGIN
do_something_else();
increment_something();
END
else
BEGIN
decrement_something();
do_nothing();
END
END

Really the first one looks more readable to me !

I admit I'm not a fan of 'begin', I would code your fragment as
something like (loosely taken from Algol68):

do
do_something
if something then
do_something_else
increment_something
else
decrement_something
do_nothing
endif
end

The original C has:

5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)

As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.

As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).

Of course I'm not expecting to persuade anyone reading comp.lang.c
that C syntax is anything other than wonderful… just a few
observations.

Bart.

Nov 14 '05 #14

"Bart" <48**@freeuk.com> wrote in message
news:61********************************@4ax.com...

<snip>
5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)
You seem to be of the opinion that the "extra" punctuation is a bad point.
I, for one, do not think of it as such.

For instance, the language you use omits '(' and ')' for function names, but
i do not suppose that this is also the case when you want to apply a few
parameters. Furthermore, in 'C'

int foobar(void);

int some_var = foobar();

is something completely different than

int foobar(void);

some_var = foobar;

This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessary".
As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.
Ah... A matter of taste. Well, tastes differ.
As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).
Using tabs do to indenting is a *very* bad idea. I've seen more source that
looked like garbage (but wasn't) due to this. As an aside, i could not care
less about a few extra bytes of *source* code. A few extra bytes of *object*
code may keep me awake at night, though.
Of course I'm not expecting to persuade anyone reading comp.lang.c
that C syntax is anything other than wonderful. just a few
observations.


Well, at least you did not convince me.
Nov 14 '05 #15
On Tue, 14 Dec 2004 22:43:36 +0000, Bart wrote:
On Tue, 14 Dec 2004 10:05:06 +0000, Peter Hickman
<pe***@semantico.com> wrote:

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.

Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.


Where are C's semicolons unnecessary? Even Pascal uses them in a similar
way. The main difference in (imperative) languages are those that treat
end of line as a terminator. This has its own drawbacks and later
(imperative) languages tend to avoid it. If you don't do that you need
something to act as a separator/terminator.
The C syntax looks like something that was hastily knocked up one
afternoon and nobody has updated it since.
Well I might agree with you on that concerning the switch statement. :-)
However that *is* the C language and most seem happy with it.


We do recognise that there are things that could be designed better in C,
like operator precedence and integral promotions. Many people bemoan
declaration syntax. But the basic syntax and symbology of statements and
operators works pretty well, and it is hard to find anything that doesn't
serve a purpose. E.g. consider

if (isupper(ch)) *p = ch;

Take those ()'s for the if away and you get

if isupper(ch)*p = ch;

which isn't the same thing, or would be hard to parse consistently as the
same thing in the general case.

Lawrence
Nov 14 '05 #16
On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@meadow.net>
wrote:
int some_var = foobar(); ....some_var = foobar; This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessary".
some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line. I
must spend half my time playing pendantics with my compiler instead of
developing my application.

....Ah... A matter of taste. Well, tastes differ.


Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).

It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change), so I guess I will
soon have to be writing raw C as well.

Bart
Nov 14 '05 #17

"Bart" <48**@freeuk.com> wrote in message
news:9q********************************@4ax.com...
On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@meadow.net>
wrote:
int some_var = foobar(); ...
some_var = foobar;

This difference does not seem to be translated into your language. It alsoshows that at least some of the parenthesis aren't "unnecessary".


some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.


That would give me a pointer-to-a-pointer-to-a-function.

http://www.eskimo.com/~scs/C-faq/q1.34.html
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.
And I can have as many statements on a line as I wan't to. Not that I
generally
do that, but we *are* talking about 'C', which allows it. Hence the
semicolon.

Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D' on
others
and a third variety does it using '0x0D'. Using your preference, a (say)
Unix
source cannot compile on a (say) Macintosh and neither will compile on a
Windblows machine.

And to top the bill, I like to leave white-lines between blocks of code to
improve readability. I frequently chop up looooooooong calls into separate
lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.
I must spend half my time playing pendantics with my compiler instead of
developing my application.
Strange. I don't.
Ah... A matter of taste. Well, tastes differ.


Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).


Nope. that '(*' and '*)', IIRC.
It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change), so I guess I will
soon have to be writing raw C as well.


So get used to it or choose another language. There's enough of them around.
Alternative: grab the gcc sources and add a front-end. Then see how popular
it gets.
Nov 14 '05 #18
"dandelion" <da*******@meadow.net> wrote:
"Bart" <48**@freeuk.com> wrote in message
news:9q********************************@4ax.com...
On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@meadow.net>
wrote:
int some_var = foobar(); ...
some_var = foobar;
That isn't legal as it stands. You cannot assign a pointer to an int
without a cast.
This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessary".


some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.
This is a matter of taste.
That would give me a pointer-to-a-pointer-to-a-function.
No, it wouldn't. Either way takes the address of a function. Strictly
speaking, only &function would be correct, but since there's nothing you
can do with a function except call it or take its address, the ampersand
has been made optional.
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.
If you want BASIC, you know where to find it. It may come as a surprise
to you, btw, that in C statements can span several lines. I don't know
about you, but I find this a very useful feature.
And I can have as many statements on a line as I wan't to.
That, too, but that's not the reason why the last statement on a line
must end in a semi-colon.
Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D' on
others and a third variety does it using '0x0D'.


Non sequitur. This is as true for preprocessor statements now as it
would be for normal statements, and that has never been a problem.
I must spend half my time playing pendantics with my compiler instead of
developing my application.


Strange. I don't.


Neither do I. Perhaps Bart should spend more time learning the language
and less time griping about it.
Ah... A matter of taste. Well, tastes differ.


Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).


Nope. that '(*' and '*)', IIRC.


Not true. { and } are the original comment delimiters in Pascal (it's
Pascal, btw, not PASCAL; it's named after Blaise P., not an acronym); (*
and *) were introduced (no idea at what time) for the sake of systems
which don't have { and } in their charset, much as ??< and ??> (and now
<% and %>) in C.

Richard
Nov 14 '05 #19

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

<snip>
That would give me a pointer-to-a-pointer-to-a-function.
No, it wouldn't. Either way takes the address of a function. Strictly
speaking, only &function would be correct, but since there's nothing you
can do with a function except call it or take its address, the ampersand
has been made optional.


:-( *Bad*.

<snip>
And I can have as many statements on a line as I wan't to.


That, too, but that's not the reason why the last statement on a line
must end in a semi-colon.


And all the other statements do not have to? Wow. That's new.
Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D' on
others and a third variety does it using '0x0D'.


Non sequitur.


I wasn't making any conclusions from it , I merely point it out. And no, it
would not be a major problem, but it would need to be specified. Besides,
the C-syntax is rather a far cry form the CPP syntax.
This is as true for preprocessor statements now as it
would be for normal statements, and that has never been a problem.
So *this* is the Non Sequitur. If something isn't a problem in Prolog, it
may *well* be a problem in Lisp.

I notice you snip the most important reason for not having 'newline' as a
statement delimiter without marking snippage. Unmarked snippage is
considered bad form on many froups.

May be construed as telling less than the whole thruth...
I must spend half my time playing pendantics with my compiler instead of developing my application.


Strange. I don't.


Neither do I. Perhaps Bart should spend more time learning the language
and less time griping about it.
>Ah... A matter of taste. Well, tastes differ.

Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).


Nope. that '(*' and '*)', IIRC.


Not true.


Gimme a break!
<snip>
(* and *) were introduced (no idea at what time) for the sake of systems
which don't have { and } in their charset


So '(*' and '*)' mark comment. Thanks.

To Bart i'll admit i misread {,} for (,).
Nov 14 '05 #20
On Wed, 15 Dec 2004 14:27:41 +0000, Bart
<48**@freeuk.com> wrote:
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.
In real code a lot of statements take more than a line (at least with
reasonable line lengths). Typing semicolon is one character per
statement, having to add \ at the end of lines (and take them out) or
some other continuation character is a lot more painful. As is typing
BEGIN and END (and THEN and ENDIF for statements which don't need them).
I
must spend half my time playing pendantics with my compiler instead of
developing my application.
Then you should learn to write C. I very rarely have a semicolon
missing from a statement when I program in C. Yes, it's annoying when
the compiler flags some silly error, but it's a lot more expensive if it
just assumes that you meant whatever it was
It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change),
Syntax is not at all easy to change. Have you ever written a compiler?
Would you like to have to change millions of lines of existing code
because someone wants to change the syntax (and debug it, and verify
it...)?
so I guess I will
soon have to be writing raw C as well.


Indeed. Or you could get Visual Basic...

Chris C
Nov 14 '05 #21
On Wed, 15 Dec 2004 14:27:41 +0000, Bart wrote:
On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@meadow.net>
wrote:
int some_var = foobar(); ...
some_var = foobar;

This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessary".


some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.


Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line. I
must spend half my time playing pendantics with my compiler instead of
developing my application.


I haven't found typing one extra character per line a great hardship. The
more significant question is whether this syntax aids readability, which
is harder to say. Most languages I've used that don't do this have been
text processing or scripting languages and comparing readability between
such different languages, and how much of that is down to ; isn't easy. I
think code using ; is more consistent, especially in languages that try to
"guess" whether a 2nd line is a continuation or a new statement/command.

Lawrence

Nov 14 '05 #22
Bart wrote:
Of course I'm not expecting to persuade anyone reading comp.lang.c
that C syntax is anything other than wonderful... just a few
observations.

Bart.


It's not that C syntax is so wonderful (it really, really isn't); it's
that using the preprocessor to redefine the language *always* leads to
heartburn. The OP's negative points are spot on. It breaks
language-sensitive tools; it requires retraining; it will lead to
maintenance headaches as the language changes over time.

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

Nov 14 '05 #23
"dandelion" <da*******@meadow.net> writes:
"Bart" <48**@freeuk.com> wrote in message
news:9q********************************@4ax.com... [...]
some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.


That would give me a pointer-to-a-pointer-to-a-function.

http://www.eskimo.com/~scs/C-faq/q1.34.html


No, it doesn't (and the FAQ doesn't say it does). A function name in
an expression decays to a pointer-to-function *unless* it's the
operand of "&" or "sizeof" (the latter case is a constraint
violation).
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.


And I can have as many statements on a line as I wan't to. Not that
I generally do that, but we *are* talking about 'C', which allows
it. Hence the semicolon.


If C banned multiple statements per line, it would be no great loss in
my opinion (except, of course, that it would break tons of existing
code). The real issue is multi-line statements. Most C programmers,
I think, type the trailing ';' without thinking about it, and barely
notice it when reading code.
Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D'
on others and a third variety does it using '0x0D'. Using your
preference, a (say) Unix source cannot compile on a (say) Macintosh
and neither will compile on a Windblows machine.
Irrelevant. Any source file has to be converted when it's transferred
from one system to another. Some compilers may tolerate, e.g., CR-LF
pairs on a Unix system, or LF line terminators on a Windows system,
but in general if the text file formats differ you have to translate.
And to top the bill, I like to leave white-lines between blocks of code to
improve readability. I frequently chop up looooooooong calls into separate
lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.


If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

[snip]

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '05 #24
On 15 Dec 2004 14:08:53 -0800, jo*******@my-deja.com wrote:

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.


Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..

Bart
Nov 14 '05 #25

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

<snip>
And to top the bill, I like to leave white-lines between blocks of code to improve readability. I frequently chop up looooooooong calls into separate lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.


If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)


That does not address the point of breaking up long statements into multiple
lines for readability.

<snip>
Nov 14 '05 #26

"Bart" <48**@freeuk.com> wrote in message
news:b6********************************@4ax.com...
On 15 Dec 2004 14:08:53 -0800, jo*******@my-deja.com wrote:

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.


Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..


Checkout http://gcc.gnu.org

You may not be the first with that idea.
Nov 14 '05 #27
"dandelion" <da*******@meadow.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

<snip>
> And to top the bill, I like to leave white-lines between blocks
> of code to improve readability. I frequently chop up looooooooong
> calls into separate lines for the same reason, and do the same
> with lenngthy versions of conditions in if(), while() and
> friend. Those extra newlines (excusez le mot) would be part of
> the language in your setup.
>
> I would not like that. And that's putting it (very) mildly.


If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)


That does not address the point of breaking up long statements into
multiple lines for readability.


No, it doesn't. Since I don't think it's a good idea, I wasn't going
to work out all the details.

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '05 #28
Lawrence Kirby <lk****@netactive.co.uk> wrote:
On Wed, 15 Dec 2004 14:27:41 +0000, Bart wrote:
some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.


Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.


It's even worse in Pascal, because it does allow the name to occur, as a
normal identifier, on the left side of an assignment (where it
represents the return value); this makes it easy to assume, erroneously,
that it _is_ a normal identifier, and can be used on the right side as
well.

Richard
Nov 14 '05 #29
On Thu, 16 Dec 2004 10:47:08 +0000, Keith Thompson wrote:

....
But I suppose the most obvious thing to do would be to use '\' as a
continuation character.


You can do that, some languages do and even some data file formats. For
human edited data like source code it has IMO proved to be a VERY
error-prone mechanism.

Of course C has this mechanism which can be used anywhere but isn't needed
except for multi-line macro definitions and the old method of multi-line
string literals. IMO it is only the fact that the need to use it is rare
that makes it tolerable. It would be grim indeed if you had to use it for
every multi-line statement.

Lawrence
Nov 14 '05 #30

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"dandelion" <da*******@meadow.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

<snip>
> And to top the bill, I like to leave white-lines between blocks
> of code to improve readability. I frequently chop up looooooooong
> calls into separate lines for the same reason, and do the same
> with lenngthy versions of conditions in if(), while() and
> friend. Those extra newlines (excusez le mot) would be part of
> the language in your setup.
>
> I would not like that. And that's putting it (very) mildly.

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)


That does not address the point of breaking up long statements into
multiple lines for readability.


No, it doesn't. Since I don't think it's a good idea, I wasn't going
to work out all the details.

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.


Considering the amounts of time i've wasted correcting missing or
superfluous '/' i do not think that's a great idea.
Nov 14 '05 #31

"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k...
On Thu, 16 Dec 2004 10:47:08 +0000, Keith Thompson wrote:
But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

Of course C has this mechanism which can be used anywhere but isn't needed
except for multi-line macro definitions and the old method of multi-line
string literals. IMO it is only the fact that the need to use it is rare
that makes it tolerable. It would be grim indeed if you had to use it for
every multi-line statement.


EOL processing can be made fairly painless. An EOL (carriage return) is
quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.

For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.

Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b

In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I will
mention it before anyone else) is sending source code over networks that
wrap lines at arbitrary points.

Bart.
Nov 14 '05 #32
On Thu, 16 Dec 2004 17:20:02 +0000, Bart C wrote:

....
EOL processing can be made fairly painless. An EOL (carriage return) is
quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.

For example EOL can be ignored when following a symbol that is
*expected* to be followed by something else, such as "+". And converted
to ";" (or acts as statement terminator) otherwise. Use "\" to override
this behaviour in the latter case and ";" in the former, if it should
ever be necessary.
The problem isn't how the compiler handles this, it is with the
readability and maintainability of source code that results from this.
I've experienced it, and I wouldn't call it good.
Some conventions need to be used, for example it is necessary, if
splitting 'a+b', to write:

a+
b

rather than:

a
+ b
Languages like AWK do this sort of thing which is OK for that, but I still
find having explicit end of statement markers that I can locate instantly
more readable.
In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I
will mention it before anyone else) is sending source code over networks
that wrap lines at arbitrary points.


That can affect C as it is, notably with string literals and now that C99
supports // style comments. Although problems with those are usually easy
to spot and fix.

Lawrence
Nov 14 '05 #33
In article <pa****************************@netactive.co.uk> ,
lk****@netactive.co.uk says...
But I suppose the most obvious thing to do would be to use '\' as a
continuation character.


You can do that, some languages do and even some data file formats. For
human edited data like source code it has IMO proved to be a VERY
error-prone mechanism.


Which is precisely why we now have widescreen monitors, variable
font sizes, editors that can handle more than 80 columns and
landscape printers.

If you need really long lines, a dual-monitor video card can be
employed.

Is a smiley required?

Nov 14 '05 #34
"Mike Malone" <mr*@prodigy.net> wrote in message
news:dY******************@newssvr19.news.prodigy.c om...
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.


This will considerably reduce code readability.
So much so that (almost) no one noticed the typo on ENG
Your colleague is teasing you, or begging to be fired.

--
Chqrlie.
Nov 14 '05 #35
Sniper1 wrote:
lk****@netactive.co.uk says...
But I suppose the most obvious thing to do would be to use '\'
as a continuation character.


You can do that, some languages do and even some data file
formats. For human edited data like source code it has IMO
proved to be a VERY error-prone mechanism.


Which is precisely why we now have widescreen monitors, variable
font sizes, editors that can handle more than 80 columns and
landscape printers.

If you need really long lines, a dual-monitor video card can be
employed.


Or other ugly things, none of which beyond a 72 char wide text line
should be necessary. Even C has no need for a line continuation
character outside of specifying macros. Even here a simple syntax
change should suffice, something like BEGINMACRO .... ENDMACRO.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #36
"Bart C" <bc@freeuk.com> wrote:
For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.

Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b


Blech. If you want Icon, you know where to find it.

Richard
Nov 14 '05 #37
On Thu, 16 Dec 2004 17:20:02 -0000, Bart C
<bc@freeuk.com> wrote:
EOL processing can be made fairly painless. An EOL (carriage return) is
EOL is not necessarily "carriage return" (I believe some Macs use it,
nothing I've ever used). EOL is anything the implementation wants
external to the C program (including no character at all if lines are
counted strings) and is represented by the character '\n', 'newline', in
C.
quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.
Would it like to use the spaces for indentation as well? I know at least
one language which does -- and just like using EOL it's a pain more
often than it is useful.
For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.
Awk and Python are in other newsgroups.
Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b
As it happens, that's how I usually break lines anyway by choice.
However, there are millions of lines of code which use the opposite
convention according to local coding standards (I've had to write many
thousands of them) which would be broken by such a change.
In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I will
mention it before anyone else) is sending source code over networks that
wrap lines at arbitrary points.


Anything which wraps lines, like editors and "beautifiers", is likely to
break it.

A bigger problem is that it is not obvious visually without doing a
parse whether a statement is finished or not. In your second example it
is perfectly obvious visually that what is meant is a + b, but your
compilers will take it as two statements, a and +b (presumably without
giving a warning, since both would be valid statements).

If you want a different language, use it. Having a semicolon which
terminates statements (as opposed to separating them as in Pascal) is
something with which most C programmers have no problem.

Chris C
Nov 14 '05 #38

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...
On Thu, 16 Dec 2004 17:20:02 -0000, Bart C
<bc@freeuk.com> wrote: .... Awk and Python are in other newsgroups. .... If you want a different language, use it. Having a semicolon which
terminates statements (as opposed to separating them as in Pascal) is
something with which most C programmers have no problem.


For some appls I need a tight, compiled language like C. I want to use a
mainstream language so the choice is between C and ASM. I think writing C is
easier. The semicolon business is a bit of a pain but not a big deal.

It's just a shame that language syntax is bound so tightly to the rest of it
that no-one can see that there could be a choice without having to switch to
a totally different and inappropriate language.

Bart.
Nov 14 '05 #39
On Fri, 17 Dec 2004 13:22:23 -0000, Bart C
<bc@freeuk.com> wrote:
"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...
On Thu, 16 Dec 2004 17:20:02 -0000, Bart C
<bc@freeuk.com> wrote: ...
Awk and Python are in other newsgroups.

...
If you want a different language, use it. Having a semicolon which
terminates statements (as opposed to separating them as in Pascal) is
something with which most C programmers have no problem.


For some appls I need a tight, compiled language like C. I want to use a
mainstream language so the choice is between C and ASM. I think writing C is
easier. The semicolon business is a bit of a pain but not a big deal.


I think that writing C is easier than writing assembler as well. You
could use Fortran if you want it line oriented, that's tight enough for
heavy-duty number crunchers and is compiled (indeed, if you use GCC it
is compiled by exactly the same "back-end" so the code will be just as
'tight')...
It's just a shame that language syntax is bound so tightly to the rest of it
that no-one can see that there could be a choice without having to switch to
a totally different and inappropriate language.


You are free to write a preprocessor for your different language which
converts it to C, and to try to get it accepted. I suspect that when
you get to try to do it you'll find a number of ambiguities which don't
do what you think is 'natural' easily (having used Awk and looked at
Python and Javascript among others, I find that breaking lines where I
find it natural to do so causes more problems than are solved by the
absence of the semicolon).

How many computer languages do you know which have the flexible and
redefinable syntax you want? Basically, a computer language is defined
by its syntax (if C looked like Pascal or Fortran it wouldn't be C!).
The more flexibility the more difficult the maintenance, because the
next person looking at it will have to learn essentially a different
language (this happens with customised editors as well).

Chris C
Nov 14 '05 #40
James D. Veale wrote:
Pro - fewer nesting errors...


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

Especially if you are using a syntax aware editor then you will
immidiately see a nesting error.

Though one thing that does reduce nesting errors is to put in both
brackets (be the parens, curly or square) before the code that goes
inside them. Since I started doing this a good few years ago now
(relative to my relatively short experience of programming) nesting
errors have more or less disappeared.

--
Thomas.
Nov 14 '05 #41
CBFalconer wrote:
Or other ugly things, none of which beyond a 72 char wide text line
should be necessary.


I used to follow this. Though, when I stopped a month ago or so
I found that code became easier to write and to read.

Not by much though since lines of that length are quite rare anyway,
It is usually only the occasional if statement which goes further.

I just used judgement, if it makes something easier to read I'll do
it unless it breaks with in house coding style (which is quite lenient
without causing any problems).

--
Thomas.
Nov 14 '05 #42
Thomas Stegen <th***********@gmail.com> wrote:
James D. Veale wrote:
Pro - fewer nesting errors...


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.

Richard
Nov 14 '05 #43
On Tue, 21 Dec 2004 13:57:49 +0000, Thomas Stegen
<th***********@gmail.com> wrote:
CBFalconer wrote:
Or other ugly things, none of which beyond a 72 char wide text line
should be necessary.
I used to follow this. Though, when I stopped a month ago or so
I found that code became easier to write and to read.


I find 72 characters is too limiting, especially with 4 characters per
indent level (which was imposed on me at work, I was preferring 2
characters, and I then found that 4 makes it more readable).
Not by much though since lines of that length are quite rare anyway,
It is usually only the occasional if statement which goes further.
I find that function calls do it, if statements do it more.
I just used judgement, if it makes something easier to read I'll do
it unless it breaks with in house coding style (which is quite lenient
without causing any problems).


Exactly.

Chris C
Nov 14 '05 #44
Chris Croughton wrote:
<th***********@gmail.com> wrote:
.... snip ...
I find 72 characters is too limiting, especially with 4 characters
per indent level (which was imposed on me at work, I was preferring
2 characters, and I then found that 4 makes it more readable).
Not by much though since lines of that length are quite rare anyway,
It is usually only the occasional if statement which goes further.


I find that function calls do it, if statements do it more.


Such function calls usually should be broken into one line per
parameter anyhow, maybe per associated parameter pair in some
cases. I consider conditional statements that can't be similarly
broken to be much too complex anyhow.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #45
In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:
I find 72 characters is too limiting, especially with 4 characters per
indent level


I indent using tabs set to 8 characters for readability *and* because
it reaches the right margin on a typical 80 character editor window
after a reasonable nesting depth.

If the text falls over the right margin then I take this as a sign that
the logic is too complext to be efficiently maintained (for 20 or 30
years by someone else) and a change is required to reduce the number
of nesting levels.

Source code written using 2 character indentation and 30 indentation
levels is not something I want to maintain.

--
Göran Larsson http://www.mitt-eget.com/
Nov 14 '05 #46
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..
Nov 14 '05 #47
"Jarno A Wuolijoki" <jw******@cs.Helsinki.FI> wrote in message
news:Pi*******************************@sbz-31.cs.Helsinki.FI...
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 ?
What is your compiler / environment ?
What was the error message at compile time ?

--
Chqrlie.
Nov 14 '05 #48
On Tue, 21 Dec 2004, Charlie Gordon wrote:
"Jarno A Wuolijoki" <jw******@cs.Helsinki.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)

What is your compiler / environment ?
gcc.

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.

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.
Nov 14 '05 #49
Jarno A Wuolijoki wrote:
On Tue, 21 Dec 2004, Charlie Gordon wrote:

"Jarno A Wuolijoki" <jw******@cs.Helsinki.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.
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.


Impress us:
Make
gcc -Wall -O -ansi -pedantic
compile at exactly one brace/parenthesis mismatch.

It certainly would make its way into my repository of pathological
examples.

Otherwise, you would not hunt for a bug but for a syntax error.
-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

112
by: Andy | last post by:
Hi All! We are doing new development for SQL Server 2000 and also moving from SQL 7.0 to SQL Server 2000. What are cons and pros for using IDENTITY property as PK in SQL SERVER 2000? Please,...
2
by: Zhou Lei | last post by:
Hi friends I'm a newbie learning XSLT to transform an XML to some other documents. Now I have some questions, anyone could give me some suggestions on them? 1. If we save our documents in XML...
5
by: Fred | last post by:
Not much expertise on XSLT and trying to understand it's uses when creating apps in VS.NET? If I wanted flexibility on the UI (View aspect of M.V.C.): - How does it compare with creating...
2
by: scott | last post by:
Hi, Just wondering what sort of problems and advantages people have found using stored procedures. I have an app developed in VB6 & VB.NET and our developers are starting to re-write some of the...
5
by: JayCallas | last post by:
I have a requirement where I need to perform a query for position information. But for some types of entries, I need to "expand" the row to include additional position rows. Let me explain with an...
3
by: Andrea | last post by:
Hello everyone, I'd like to know which are the main pros and cons of using XML implementation in business organizations. >From a technical perspective, I find XML powerful, but looks like it is...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.