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 1 of 2  [1] 2  Next page →

#28875 — Macros

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


-- 
Bartc 

[toc] | [next] | [standalone]

#28876

On Sunday, 2 December 2012 19:53:27 UTC+2, Bart  wrote:
> 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.

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

#28879

On 12/02/2012 01:11 PM, � wrote:
> On Sunday, 2 December 2012 19:53:27 UTC+2, Bart  wrote:
>> 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.

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

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

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

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

#28889

On Sunday, 2 December 2012 20:58:16 UTC+2, James Kuyper  wrote:
> On 12/02/2012 01:11 PM, Öö Tiib wrote:
> > On Sunday, 2 December 2012 19:53:27 UTC+2, Bart  wrote:
> >> #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.
> 
> 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 use as 
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".

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

#28922

In article <k9g8c9$4sd$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>> 
>> You are violating standards here. 
>> You may not use language keywords as macro names.
>
>Citation, please?

Hardly matters.  Unless you're entering the obfuscated C programming
contest, doing this is a double-plus ungood idea, standard or no standard.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

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

#28923

On 12/04/2012 06:59 PM, Edward A. Falk wrote:
> In article <k9g8c9$4sd$1@dont-email.me>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
>>>
>>> You are violating standards here. 
>>> You may not use language keywords as macro names.
>>
>> Citation, please?
> 
> Hardly matters.  Unless you're entering the obfuscated C programming
> contest, doing this is a double-plus ungood idea, standard or no standard.

It don't like the idea of doing it, but I also don't like saying
incorrect things about what does and does not violate the requirements
of the standard. Using language keywords does not violate any
requirements imposed by the C standard. Code which does such things
might be hard to read and understand, but it has well-defined behavior
according to the C standard (unless some other feature of the program is
problematic).

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

#28924

On 2012-12-05, James Kuyper <jameskuyper@verizon.net> wrote:
> On 12/04/2012 06:59 PM, Edward A. Falk wrote:
>> In article <k9g8c9$4sd$1@dont-email.me>,
>> James Kuyper  <jameskuyper@verizon.net> wrote:
>>>>
>>>> You are violating standards here. 
>>>> You may not use language keywords as macro names.
>>>
>>> Citation, please?
>> 
>> Hardly matters.  Unless you're entering the obfuscated C programming
>> contest, doing this is a double-plus ungood idea, standard or no standard.
>
> It don't like the idea of doing it, but I also don't like saying
> incorrect things about what does and does not violate the requirements
> of the standard. Using language keywords does not violate any
> requirements imposed by the C standard. Code which does such things
> might be hard to read and understand, but it has well-defined behavior
> according to the C standard (unless some other feature of the program is
> problematic).

There is, however, a slightly related rule in the standard about
keywords as macro names; one that might even be the source of the
(common?) belief stated above.

  The program shall not have any macros with names lexically identical
  to keywords currently defined prior to the inclusion of [any standard]
  header or when any macro defined in the header is expanded.
  (N1570 7.1.2p4)

It's not an outright ban, but it is a limitation.

-- 
Heikki Kallasjoki

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

#28931

On 12/04/2012 07:58 PM, Heikki Kallasjoki wrote:
> On 2012-12-05, James Kuyper <jameskuyper@verizon.net> wrote:
...
>> requirements imposed by the C standard. Code which does such things
>> might be hard to read and understand, but it has well-defined behavior
>> according to the C standard (unless some other feature of the program is
>> problematic).
> 
> There is, however, a slightly related rule in the standard about
> keywords as macro names; one that might even be the source of the
> (common?) belief stated above.
> 
>   The program shall not have any macros with names lexically identical
>   to keywords currently defined prior to the inclusion of [any standard]
>   header or when any macro defined in the header is expanded.
>   (N1570 7.1.2p4)
> 
> It's not an outright ban, but it is a limitation.

Yes, it is a limitation, but an avoidable one. With respect to my
earlier statement, violation of that limitation counts as "some other
feature of the program" that "is problematic".


-- 
James Kuyper

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

#28925

On 12/4/2012 7:14 PM, James Kuyper wrote:
> On 12/04/2012 06:59 PM, Edward A. Falk wrote:
>> In article <k9g8c9$4sd$1@dont-email.me>,
>> James Kuyper  <jameskuyper@verizon.net> wrote:
>>>>
>>>> You are violating standards here.
>>>> You may not use language keywords as macro names.
>>>
>>> Citation, please?
>>
>> Hardly matters.  Unless you're entering the obfuscated C programming
>> contest, doing this is a double-plus ungood idea, standard or no standard.
>
> It don't like the idea of doing it, but I also don't like saying
> incorrect things about what does and does not violate the requirements
> of the standard. Using language keywords does not violate any
> requirements imposed by the C standard. [...]

     7.1.2p4: "[...] The program shall not have any macros with
names lexically identical to keywords currently defined prior to
the inclusion of the header or when any macro defined in the header
is expanded."

     So, yes: You *can* #define `if' or `void' or `case' et al., but
only in restricted circumstances:

	#define int wuzzat
	#include <stdio.h>  // BZZZT!

	#include <stdio.h>
	#define int wuzzat
	size_t whiffle = BUFSIZ;  // BZZZT!

	#include <setjmp.h>
	#define int wuzzat
	...
	switch(setjmp(buf)) {  // BZZZT!
	

	#include <math.h>
	#define int wuzzat
	...
	return sin(x);  // BZZZT!  (`(sin)(x)' would be OK)

     Here's what I know: Anyone who engaged in this sort of thing,
even in formally permissible contexts, might not be fired after
the code review.  He would, however, become a figure of fun and
an object of scorn, the butt of continuing jokes.  (Did I mention
"companion of owls?"  Probably best that I didn't.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#28932

On 12/04/2012 08:03 PM, Eric Sosman wrote:
...
>      Here's what I know: Anyone who engaged in this sort of thing,
> even in formally permissible contexts, might not be fired after
> the code review.  He would, however, become a figure of fun and
> an object of scorn, the butt of continuing jokes.  (Did I mention
> "companion of owls?"  Probably best that I didn't.)

That seems reasonable. I never defended is a good idea, I only objected
to the incorrect explanation of what was wrong with it.
-- 
James Kuyper

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

#28956

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/04/2012 08:03 PM, Eric Sosman wrote:
> ...
> >      Here's what I know: Anyone who engaged in this sort of thing,
> > even in formally permissible contexts, might not be fired after
> > the code review.  He would, however, become a figure of fun and
> > an object of scorn, the butt of continuing jokes.  (Did I mention
> > "companion of owls?"  Probably best that I didn't.)
> 
> That seems reasonable. I never defended is a good idea, I only objected
> to the incorrect explanation of what was wrong with it.

And I'm glad you did. This has been an educational sub-thread.

To be frank, it might have been simpler if the standard had just
banned it outright, but that's just bikeshedding.

Phil
-- 
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.

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

#28880

"Öö Tiib" <ootiib@hot.ee> wrote in message
news:5814fff9-1958-4e28-9708-ac8cc4ed760e@googlegroups.com...
> On Sunday, 2 December 2012 19:53:27 UTC+2, Bart  wrote:
>> 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.

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

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

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.

-- 
Bartc 

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

#28881

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

-- 
Ian Collins

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

#28883

On 12-12-02 12:14 PM, Ian Collins wrote:
> BartC wrote:
>>
>> 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.
>

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

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

#28888

Greg Martin wrote:
 
> Famous last words ... I'm the only one who'll ever read this anyway.

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.

-- 
pete

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

#28892

pete wrote:

> 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

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

#28885

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:ai1r54Fijb1U4@mid.individual.net...
> BartC wrote:
>>
>> 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?

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

-- 
Bartc 

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

#28891

"BartC" <bc@freeuk.com> wrote in message 
news:bmOus.898237$Ol2.302588@fx25.am4...

> "Öö Tiib" <ootiib@hot.ee> wrote in message

>> You may do something like:
>>
>> #define BartcElse } else {

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

-- 
Bartc 

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

#28900

On Dec 2, 5:55 pm, "BartC" <b...@freeuk.com> wrote:
> "BartC" <b...@freeuk.com> wrote in message
>
> news:bmOus.898237$Ol2.302588@fx25.am4...
>
> > "Öö Tiib" <oot...@hot.ee> wrote in message
> >> You may do something like:
>
> >> #define BartcElse } else {
> > 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.)

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.

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

#29094

On Dec 2, 10:55 pm, "BartC" <b...@freeuk.com> wrote:
> "BartC" <b...@freeuk.com> wrote in message
>
> news:bmOus.898237$Ol2.302588@fx25.am4...
>
> > "Öö Tiib" <oot...@hot.ee> wrote in message
> >> You may do something like:
>
> >> #define BartcElse } else {
> > 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.)

Perl

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web