Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28875 > unrolled thread

Macros

Back to article view | Back to comp.lang.c

Contents

  Macros "BartC" <bc@freeuk.com> - 2012-12-02 17:53 +0000
    Re: Macros Öö Tiib <ootiib@hot.ee> - 2012-12-02 10:11 -0800
      Re: Macros James Kuyper <jameskuyper@verizon.net> - 2012-12-02 13:58 -0500
        Re: Macros Öö Tiib <ootiib@hot.ee> - 2012-12-02 13:37 -0800
        Re: Macros falk@rahul.net (Edward A. Falk) - 2012-12-04 23:59 +0000
          Re: Macros James Kuyper <jameskuyper@verizon.net> - 2012-12-04 19:14 -0500
            Re: Macros Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-12-05 00:58 +0000
              Re: Macros James Kuyper <jameskuyper@verizon.net> - 2012-12-04 20:44 -0500
            Re: Macros Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 20:03 -0500
              Re: Macros James Kuyper <jameskuyper@verizon.net> - 2012-12-04 20:48 -0500
                Re: Macros Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-05 23:17 +0200
      Re: Macros "BartC" <bc@freeuk.com> - 2012-12-02 19:54 +0000
        Re: Macros Ian Collins <ian-news@hotmail.com> - 2012-12-03 09:14 +1300
          Re: Macros Greg Martin <greg@softsprocket.com> - 2012-12-02 12:38 -0800
            Re: Macros pete <pfiland@mindspring.com> - 2012-12-02 16:28 -0500
              Re: Macros Rui Maciel <rui.maciel@gmail.com> - 2012-12-02 22:59 +0000
          Re: Macros "BartC" <bc@freeuk.com> - 2012-12-02 21:11 +0000
        Re: Macros "BartC" <bc@freeuk.com> - 2012-12-02 22:55 +0000
          Re: Macros ImpalerCore <jadill33@gmail.com> - 2012-12-03 06:48 -0800
          Re: Macros Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-12-09 03:15 -0800
    Re: Macros Ian Collins <ian-news@hotmail.com> - 2012-12-03 07:19 +1300
    Re: Macros James Dow Allen <jdallen2000@yahoo.com> - 2012-12-02 10:29 -0800
    Re: Macros Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-02 15:52 -0500
    Re: Macros Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-12-02 22:56 -0700
    Re: Macros Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-12-02 22:56 -0700
      Re: Macros "BartC" <bc@freeuk.com> - 2012-12-03 12:20 +0000
        Re: Macros Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-03 17:01 +0000
    Re: Macros Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-12-02 22:57 -0700
    Re: Macros "Heinrich Wolf" <invalid@invalid.invalid> - 2012-12-03 09:48 +0100
      Re: Macros Öö Tiib <ootiib@hot.ee> - 2012-12-03 07:34 -0800

Page 2 of 2 — ← Prev page 1 [2]

#28877

BartC wrote:
> 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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#28878

On Dec 3, 12:53 am, "BartC" <b...@freeuk.com> wrote:
> I'm trying out these macros to save on typing and errors** :

:-)


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

:-)  :-)

[toc] | [prev] | [next] | [standalone]

#28884

On 12/2/12 12:53 PM, BartC wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#28895

"BartC" <bc@freeuk.com> writes:

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

[toc] | [prev] | [next] | [standalone]

#28896

"BartC" <bc@freeuk.com> writes:

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

[toc] | [prev] | [next] | [standalone]

#28899

"Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message
news:1b7gozsmph.fsf@snowball.wb.pfeifferfamily.net...
> "BartC" <bc@freeuk.com> writes:
>
>> I'm trying out these macros to save on typing and errors** :
>>
>> #define else } el##se {

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

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#28903

"BartC" <bc@freeuk.com> writes:

> "Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message
> news:1b7gozsmph.fsf@snowball.wb.pfeifferfamily.net...
<snip>
>> 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.

You should have given up in it for it for other reasons, as you solution
illustrates perfectly: if syntax-disrupting macros are ever used, you
can't implement a simple syntax converter without either implementing a
full C pre-processor or running the source though one first.  The former
is tedious and the latter makes it hard to keep things readable.

There is a fine tradition (on Unix at least) of writing what have become
know as "little languages" -- small syntax layers over a low-level
language to produce a higher-level one (ratfor and grap spring to mind,
but I am sure there are others) so you are in good company with this
solution.  Lex and YACC were supposed to make this easy but they never
quite made it trivial (I'm looking forward to Perl 6 for this purpose).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28897

"BartC" <bc@freeuk.com> writes:

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

[toc] | [prev] | [next] | [standalone]

#28898

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. 

[toc] | [prev] | [next] | [standalone]

#28901

On Monday, 3 December 2012 10:48:35 UTC+2, Heinrich Wolf  wrote:
> 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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web