Macros

[BartC]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

 

[Öö Tiib]

I'm trying out these macros to save on typing and errors** :

If C syntax is too hard to type for you then better choose
a language with more laconic syntax like Python. Do not mutate
language or else others can not read your code.

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

You are violating standards here.
You may not use language keywords as macro names.
You may do something like:

#define BartcElse } else {

That will work. Also if someone wants to undo your effort
(for obvious reasons) then it will be easier for him.

 

[Ian Collins]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

Have you taken a Bill pill?

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

Use a decent editor, or a not so good one that does auto indent and
bracket/brace matching.

 

[James Dow Allen]

I'm trying out these macros to save on typing and errors** :



#define else } el##se {
... problems from mismatching/missing braces ...

 

[James Kuyper]

If C syntax is too hard to type for you then better choose
a language with more laconic syntax like Python. Do not mutate
language or else others can not read your code.

I agree with the sentiment. I'd hate to do maintenance work on code
written by someone who finds the following concept attractive:

You are violating standards here.
You may not use language keywords as macro names.

Citation, please? The grammar for #define requires only that a macro
parse as an identifier. The C standard distinguishes between plain
tokens and preprocessing tokens (6.4p1). During translation phase 3, the
source text is decomposed into preprocessing tokens (5.1.1.2p3) - It's
only during translation phase 7 that preprocessing tokens get converted
into tokens. Keywords are parsed tokens during translation phase 7, but
parse as identifiers during translation phase 3.

 

[BartC]

If C syntax is too hard to type for you then better choose
a language with more laconic syntax like Python. Do not mutate
language or else others can not read your code.

Python is no good to me. While I no longer care that no-one else can read my
code. (Since I've been mostly using my own languages since about 1980, that
is hardly new for me!)

Now it seems to work without using ##. Strange.

You are violating standards here.
You may not use language keywords as macro names.
You may do something like:

#define BartcElse } else {

That will work. Also if someone wants to undo your effort
(for obvious reasons) then it will be easier for him.

I think (since no-one is taking me seriously, also that no-one has given me
a solution...) that I will look instead at creating a preprocessor for the
source code. This will just take care of the keywords for some statements,
and help look after the braces.

The input file needs to have an extension other than ".c", so it will be
a'language' distinct from C, and the output will be pure C to keep the
people here happy.

 

[Ian Collins]

I think (since no-one is taking me seriously, also that no-one has given me
a solution...) that I will look instead at creating a preprocessor for the
source code. This will just take care of the keywords for some statements,
and help look after the braces.

Did you expect to be taken seriously?

The "solution" is simple - get your editor to do the work for you.

 

[Greg Martin]

Did you expect to be taken seriously?

The "solution" is simple - get your editor to do the work for you.

+1 ... or if the repetition is significant enough write a code
generator. Alternatively, run the macro processor in a separate phase to
leave the final sources readable and free of obfuscation.

Famous last words ... I'm the only one who'll ever read this anyway.

 

[Richard Damon]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

No, what is stopping the define from running recursively is the rules
for expanding defines. The rule approximately states that a macro will
not reprocess the replacement it creates.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

Since elsif and else are different macros, so the recursive clause
doesn't apply.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

I wouldn't do this sort of redefinitions. For one thing I believe your
programs have technically invoked undefined behavior to the compiler so
nothing is promised anymore about your program.

You are also making your code unreadable to anyone else.

IF I was to try and do something similar to this, I would use capitals,
in C these are generally indicative of a macro, so it warns the reader
to look for the definition. Thus you would have

#define IF(x) if(x) {
#define ELSE } else {
#define ELSIF(x) } else if(x) {
#define FI }

note that the last is needed to avoid giving smart editors that match
the braces from having fits over your code.

 

[BartC]

Did you expect to be taken seriously?

I thought someone might rise to the technical challenge... But it doesn't
matter now.

The "solution" is simple - get your editor to do the work for you.

So one answer is to use some external software to help out. Which is what
I'm now attempting. (And I'll probably fix a few other things while I'm
about it.)

 

[Öö Tiib]

Citation, please? The grammar for #define requires only that a macro
parse as an identifier. The C standard distinguishes between plain
tokens and preprocessing tokens (6.4p1). During translation phase 3, the
source text is decomposed into preprocessing tokens (5.1.1.2p3) - It's
only during translation phase 7 that preprocessing tokens get converted
into tokens. Keywords are parsed tokens during translation phase 7, but
parse as identifiers during translation phase 3.

You might be correct, I had memory that the tokens like else are reserved
for keywords and shall not be used otherwise. But now I looked 6.4.1 again
and there is some sort of "reserved (in translation phases 7 and 8) for useas
keywords, and shall not be used otherwise." So that can be indeed read as
"shall not be used otherwise in translation phases 7 and 8".

 

[BartC]

I think
... that I will look instead at creating a preprocessor for the
source code.

The input file needs to have an extension other than ".c", so it will be
a'language' distinct from C, and the output will be pure C to keep the
people here happy.

This preprocessor now 'works', and is transparent to the compilation
process.

(So long as the input is line-oriented and follows certain guidelines.)

But one small snag I hadn't thought of: modifying thousands of lines of
existing code to conform to this new format. I don't think it will help my
RSI much.)

 

[Rui Maciel]

Also,
if a good coding style is not being used consistently,
then looking at one's own code for the first time in six months,
is a lot like reading someone else's code.

Hear, hear.

In addition, there are always bugs lingering around, which eventually
require a fix, and cryptic code only makes them that much harder to spot.


Rui Maciel

 

[Joe Pfeiffer]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

No, no, no.

Many new C programmers have made this mistake -- I was one of them.

C has a syntax. It may or may not be a good syntax, but it is C's
syntax. Using macros to try to create a new syntax for C leads to
madness. Just... don't.

 

[Joe Pfeiffer]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

No, no, no.

Many new C programmers have made this mistake -- I was one of them.

C has a syntax. It may or may not be a good syntax, but it is C's
syntax. Using macros to try to create a new syntax for C leads to
madness. Just... don't.

 

[Joe Pfeiffer]

I'm trying out these macros to save on typing and errors** :

#define else } el##se {

That seems to work: 'else' is converted to '} else {'. Somehow the ## stops
the new 'else' from being recursively processed.

But:

#define elsif } el##se if

if converted to '} } else { if'. That new 'else' is this time processed one
extra time.

What's the way to make it do what I want? (I don't like using capitals; I
reserve those for debug code.)


(** A month or so of using C, and I'm starting to suffer from RSI pain
again! Partly from all the extra typing needed, partly from sorting out
problems from mismatching/missing braces, case labels and everything else.
For a supposedly terse language, there's a lot of typing involved!)

No, no, no.

Many new C programmers have made this mistake -- I was one of them.

C has a syntax. It may or may not be a good syntax, but it is C's
syntax. Using macros to try to create a new syntax for C leads to
madness. Just... don't.

 

[Heinrich Wolf]

There exist some tools that reformat the code to a structured indentation
and to systematic braces. After reformatting the code you may be able to
find problems with misplaced braces and misleading indentation.

For many years I used Diamond X-Tools as such a tool. Furthermore it makes
the code visible as Nassi-Schneidermann diagram and offers editing in that
diagram. Unfortunately the deafult setting is to add many special
controlling comments to the source code. But you can switch many of these
off.

 

[BartC]

No, no, no.

Many new C programmers have made this mistake -- I was one of them.

Possibly that tells you something about the language...

C has a syntax. It may or may not be a good syntax, but it is C's
syntax.

Maybe. A 'good' syntax that requires external tools to encode/decipher type
declarations, or to count braces, or (in my case) to create lists of local
and global function prototypes that would otherwise take half my time to
maintain.

Using macros to try to create a new syntax for C leads to
madness. Just... don't.

Well, I've given up on that, because it's not up to the job. As I've said,
I'm using an external tool to convert source code in a kind of hybrid
language to what is considered normal C code.

It's a crude tool that converts source a line at a time (so that line
numbers correspond), but it seems to work.

Braces have been almost entirely eliminated. Endings for if, switch, while
etc are distinct (rather than be all "}"). Function prototypes are taken
care of (they are placed in two include files, one for locals, one for
exports).

There were a few other things which weren't that important, but in this
language implementation project, they were changed to match the target
language (for example, using := and =, instead of = and ==).

And, the output is perfectly readable, ordinary C. Where the braces always
match up.

 

[ImpalerCore]

This preprocessor now 'works', and is transparent to the compilation
process.

(So long as the input is line-oriented and follows certain guidelines.)

But one small snag I hadn't thought of: modifying thousands of lines of
existing code to conform to this new format. I don't think it will help my
RSI much.)

If you use 'vi', it has a macro mechanism to record a series of steps
and apply it on command.

If you have code that features the same style, you should be able to
change it through a careful selection of movement and edit commands,
and apply it to any number of sequential lines.

For example, let's say that you have a set of integer declarations.

int a;
int b;
int c;
....
int z;

You want to create a set of printf statements from that block. The
'^' represents a cursor position in the text.
vi command
int a;
^ ma
int b;
int c;
....
int z;
^ y'a

Paste it in a new location.

vi
int a; p
int b;
int c;
....
int z;

Go to beginning of first line of copied block.

int a;
^ qa
int b;
int c;
....
int z;

Hitting 'q' starts recording a macro in slot 'a'.

Perform your edit and place the cursor at the beginning of the next
line. Use 'yw' to copy the character 'a' to store relative text and
paste to duplicate that text. At the end of your edit, move to the
beginning of the next line ('j', '0') that's used to anchor your next
line edit.

vi
printf( "a = %d", a );
int b;
^ q
int c;
....
int z;

Hit 'q' to end the macro. Now you have a macro to change 'int a;'
into ' printf( "a = %d", a );' and moves down to the beginning of the
next line.

printf( "a = %d", a );
int b;
^ 25@a
int c;
....
int z;

Type 25@a to apply your macro 'a' 25 times.

printf( "a = %d", a );
printf( "b = %d", b );
printf( "c = %d", c );
....
printf( "z = %d", z );
^

You can also do it with regular expressions. If you have this much
editing to do, it's worth looking into an editor that can help you out
with repetitive code changes.

Best regards,
John D.

 

[Öö Tiib]

There exist some tools that reformat the code to a structured indentation
and to systematic braces. After reformatting the code you may be able to
find problems with misplaced braces and misleading indentation.
+1

For many years I used Diamond X-Tools as such a tool. Furthermore it makes
the code visible as Nassi-Schneidermann diagram and offers editing in that
diagram. Unfortunately the deafult setting is to add many special
controlling comments to the source code. But you can switch many of these
off.

I have used "Artistic Style". It does not do any editing only formats.
However it formats quite well. It formats C and Java and C# and even
C++ code for very wide variety of bracing and white-spacing tastes.
It is open source C++ and not too large code-base so when I don't like
something that it does then I can just modify it.