#define macro to enclose an older macro with strings

[Dead RAM]

Hey people, i'll try to keep this short ;)

Here is what I want to type (or at least close too)...

#define VER_BUILD 1
#define STR_VER_BUILD "VER_BUILD"

But what happends is the preprocessor see the quots in STR_VER_BUILD and
replaces that text with "VER_BUILD"...
I need it to see the VER_BUILD and replace it with 1, and only after doing
that replacement enclose the 1 in quots...
I tried using a number sign without any luck (number sign in a macro that
takes params encloses the next param in quots).

#define VER_BUILD 1
#define THING_TO_STR(thing) # thing
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Both these tries gave me the result of STR_VER_BUILD being replaced with
"VER_BUILD"... Instead of what I wanted... VER_BUILD being replaced with 1
and STR_VER_BUILD being replaced with "1"

Just so there isn't any confusion... any other place were i used VER_BUILD
alone, the preprocessor replaced that with 1.

[John Harrison]

"Dead RAM" <de*****@hotmail.com> wrote in message
news:1o********************@twister01.bloor.is.net .cable.rogers.com...

Hey people, i'll try to keep this short ;)

Here is what I want to type (or at least close too)...

#define VER_BUILD 1
#define STR_VER_BUILD "VER_BUILD"

But what happends is the preprocessor see the quots in STR_VER_BUILD and
replaces that text with "VER_BUILD"...
I need it to see the VER_BUILD and replace it with 1, and only after doing
that replacement enclose the 1 in quots...
I tried using a number sign without any luck (number sign in a macro that
takes params encloses the next param in quots).

#define VER_BUILD 1
#define THING_TO_STR(thing) # thing
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Both these tries gave me the result of STR_VER_BUILD being replaced with
"VER_BUILD"... Instead of what I wanted... VER_BUILD being replaced with 1
and STR_VER_BUILD being replaced with "1"

This is a good example of the weirdness that is the C pre-processor. This
minor variation works

#define VER_BUILD 1
#define _THING_TO_STR(thing) # thing
#define THING_TO_STR(thing) _THING_TO_STR(thing)
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Don't ask me to explain why because I don't know. It just a trick worth
knowing.

john

[John Harrison]

>

#define VER_BUILD 1
#define _THING_TO_STR(thing) # thing
#define THING_TO_STR(thing) _THING_TO_STR(thing)
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR with
something more suitable.

john

[Dario (drinking coffee in the office…)]

Dead RAM wrote:

Hey people, i'll try to keep this short ;)

Here is what I want to type (or at least close too)...

#define VER_BUILD 1
#define STR_VER_BUILD "VER_BUILD"

But what happends is the preprocessor see the quots in STR_VER_BUILD and
replaces that text with "VER_BUILD"...
I need it to see the VER_BUILD and replace it with 1, and only after doing
that replacement enclose the 1 in quots...
I tried using a number sign without any luck (number sign in a macro that
takes params encloses the next param in quots).

#define VER_BUILD 1
#define THING_TO_STR(thing) # thing
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Both these tries gave me the result of STR_VER_BUILD being replaced with
"VER_BUILD"... Instead of what I wanted... VER_BUILD being replaced with 1
and STR_VER_BUILD being replaced with "1"

Just so there isn't any confusion... any other place were i used VER_BUILD
alone, the preprocessor replaced that with 1.

#include <stdio.h>
#include <stdlib.h>
#define STR_VER_BUILD "1"
#define VER_BUILD atoi(STR_VER_BUILD)
int main(void) {
printf("%d = \"%s\"\n", VER_BUILD, STR_VER_BUILD);
return 0;
}

[hack_tick]

hi there
"John Harrison" <jo*************@hotmail.com> wrote in message
news:2l************@uni-berlin.de...
[..]

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR with
something more suitable.

is it just the case with Macros or with All the identifiers ? is it Standard
?

[hack_tick]

BTW its working with VC6 for macros and identifiers(i tried with variable's
name only)

[Karl Heinz Buchegger]

hack_tick wrote:

hi there
"John Harrison" <jo*************@hotmail.com> wrote in message
news:2l************@uni-berlin.de...
[..]

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR with
something more suitable.

is it just the case with Macros or with All the identifiers ? is it Standard

All identifiers and yes it is Standard. Names starting with an underscore
followed by an uppercase letter are reserved for the compiler to aid in
implementing its own macros and templates without interfering with user
written source code.

--
Karl Heinz Buchegger
kb******@gascad.at

[Karl Heinz Buchegger]

hack_tick wrote:

BTW its working with VC6 for macros and identifiers(i tried with variable's
name only)

Sure it works. This rule is more on the level of an (enforced) agreement.
There is nothing wrong with those names per se. But the compiler needs some names
(for macros, templates, ...) on it's own (eg. open the iostream header
file, if it exists on your implementation and see for yourself). That's
why the standard reserves such names for exclusive use of compiler writers only.
Just avoid such names and your macros will not interfere with something you
get unexpected by including some system header files.

--
Karl Heinz Buchegger
kb******@gascad.at

[Dead RAM]

I don't know how... or why... but ummm... 0.o thanks...

As a side note... I hate the guy who built the pre-processor... but love the
brain that caused this hack to show up ;)

[JKop]

Dead RAM posted:

#define VER_BUILD 1
#define THING_TO_STR(thing) # thing
#define STR_VER_BUILD THING_TO_STR(VER_BUILD)

Both these tries gave me the result of STR_VER_BUILD being replaced
with "VER_BUILD"... Instead of what I wanted... VER_BUILD being
replaced with 1 and STR_VER_BUILD being replaced with "1"

This in some perverse way actually pleases me.
unsigned char const ver_build = 1;

const char* const str_ver_build = "1";
-JKop

[Phlip]

JKop wrote:

This in some perverse way actually pleases me.

unsigned char const ver_build = 1;

const char* const str_ver_build = "1";

unsigned char const ver_build = 2;
const char* const str_ver_build = "1";

Ooops.

The OP is trying to fold duplication, so changes in only one place propagate
correctly.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[JKop]

Phlip posted:

JKop wrote:

This in some perverse way actually pleases me.

unsigned char const ver_build = 1;

const char* const str_ver_build = "1";
unsigned char const ver_build = 2;
const char* const str_ver_build = "1";

Ooops.

The OP is trying to fold duplication, so changes in only

one place propagate correctly.

I was going to let him you his *own* brain power for the
rest.

[Phlip]

JKop wrote:

I was going to let him you his *own* brain power for the
rest.

I have ... "special" reasons to always avoid relying on brain power.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ali Cehreli]

On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:

#define VER_BUILD 1 #define _THING_TO_STR(thing) #
thing #define THING_TO_STR(thing) _THING_TO_STR(thing) #define
STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR
with something more suitable.

Two other reserved names:

- Identifiers with two leading underscores

- Identifiers with a leading underscore followed by a lower case
letter to be used in the global namespace. (I don't remember the exact
wording of this one, but the reference to the global namespace makes
it confusing even if I did.)

All these rules about underscore are good enough reasons to avoid any
name that has a leading underscore.

Ali

[AVR]

Ali Cehreli wrote:

On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:

#define VER_BUILD 1 #define _THING_TO_STR(thing) #
thing #define THING_TO_STR(thing) _THING_TO_STR(thing) #define
STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR
with something more suitable.

Two other reserved names:

- Identifiers with two leading underscores

- Identifiers with a leading underscore followed by a lower case
letter to be used in the global namespace. (I don't remember the exact
wording of this one, but the reference to the global namespace makes
it confusing even if I did.)

All these rules about underscore are good enough reasons to avoid any
name that has a leading underscore.

I'm working on a tool which has several thousand lines of code, and
around 20 developers working concurrently. The convention we follow (and
not a novel one, according to our coding standards) is that all private
variables are to be named with leading underscores, followed by lowercase.
Though I'm a relative newcomer, I was wondering if such a scheme would
be adopted in the first place if the points that you made above were
even considered. Kindly clarify.
thanks,
AVR

[John Harrison]

On Wed, 14 Jul 2004 00:28:51 +0530, AVR <an*******@spyDONOTSPAMmac.com>
wrote:

Ali Cehreli wrote:

On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:

#define VER_BUILD 1 #define _THING_TO_STR(thing) #
thing #define THING_TO_STR(thing) _THING_TO_STR(thing) #define
STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR
with something more suitable.

Two other reserved names:
- Identifiers with two leading underscores
- Identifiers with a leading underscore followed by a lower case
letter to be used in the global namespace. (I don't remember the exact
wording of this one, but the reference to the global namespace makes
it confusing even if I did.)
All these rules about underscore are good enough reasons to avoid any
name that has a leading underscore.

I'm working on a tool which has several thousand lines of code, and
around 20 developers working concurrently. The convention we follow (and
not a novel one, according to our coding standards) is that all private
variables are to be named with leading underscores, followed by
lowercase.
Though I'm a relative newcomer, I was wondering if such a scheme would
be adopted in the first place if the points that you made above were
even considered. Kindly clarify.

That scheme is fine, and it's one I use myself (I'm assuming my private
variable you mean class member variable). What isn't allowed though is to
use a name with a leading underscore in the global namespace, i.e. outside
of a class or other namespace.

john

[Ali Cehreli]

On Tue, 13 Jul 2004 11:58:51 -0700, AVR wrote:

Ali Cehreli wrote:

On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:

#define VER_BUILD 1 #define _THING_TO_STR(thing) #
thing #define THING_TO_STR(thing) _THING_TO_STR(thing) #define
STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR
with something more suitable.

Two other reserved names:

- Identifiers with two leading underscores

- Identifiers with a leading underscore followed by a lower case letter
to be used in the global namespace. (I don't remember the exact wording
of this one, but the reference to the global namespace makes it
confusing even if I did.)

All these rules about underscore are good enough reasons to avoid any
name that has a leading underscore.

I'm working on a tool which has several thousand lines of code, and
around 20 developers working concurrently. The convention we follow (and
not a novel one, according to our coding standards) is that all private
variables are to be named with leading underscores, followed by
lowercase.
Though I'm a relative newcomer, I was wondering if such a scheme would
be adopted in the first place if the points that you made above were
even considered. Kindly clarify.

Running the following query at groups.google.com finds some past
threads on this subject:

underscore "in the global namespace"

Quoting from one of those messages, the standard says:

"each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace"

So it's actually OK to use them for member names.

I agree with Francis Glassborow's comments in the same thread though:

"When given a choice between two things that are in almost all
respects identical but one of which has a possible (if only
remote) point of failure I universally opt for the other. I know
that it is unlikely that I will want a global variable visible in
the scope of a class, but why spend time worrying about it? Using
a trailing underscore works everywhere and has no lurking nasties,
leading underscores can result in rare surprises."

"Actually their very rareness makes them deeply poisonous because
you won't even be looking for trouble when it strikes (silently)."

Ali

[Jack Klein]

On Tue, 13 Jul 2004 11:52:08 -0700, Ali Cehreli <ac******@yahoo.com>
wrote in comp.lang.c++:

On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:

#define VER_BUILD 1 #define _THING_TO_STR(thing) #
thing #define THING_TO_STR(thing) _THING_TO_STR(thing) #define
STR_VER_BUILD THING_TO_STR(VER_BUILD)

Before some else points it out, identifiers with a leading underscore
followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR
with something more suitable.

Two other reserved names:

- Identifiers with two leading underscores

That's the C version. ISO C++ actually reserves identifiers with two
successive underscores _anywhere_ within, not just at the beginning.
- Identifiers with a leading underscore followed by a lower case
letter to be used in the global namespace. (I don't remember the exact
wording of this one, but the reference to the global namespace makes
it confusing even if I did.)

All these rules about underscore are good enough reasons to avoid any
name that has a leading underscore.

Ali

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[John Harrison]

> I'm working on a tool which has several thousand lines of code, and

around 20 developers working concurrently.

I've just read that again. You need 20 programmers for several thousand
lines of code! Do you all work one day a week or something? Or does
management keep you so busy with admin that you don't have any time for
programming?

Just curious.

Of course one of the problems of having so many programmers is that you can
spend all your time ensuring good communication between each other so that
you don't have any time for coding, which just encourages management to hire
even more programmers, which just makes the problem worse. See The Mythical
Man Month by Frederick P Brooks.

john

[AVR]

John Harrison wrote:

I'm working on a tool which has several thousand lines of code, and
around 20 developers working concurrently.

I've just read that again. You need 20 programmers for several thousand

Sorry for posting twice. I didn't realize.
lines of code! Do you all work one day a week or something? Or does
management keep you so busy with admin that you don't have any time for
programming?
I wasn't concentrating on specifics earlier. I just checked and:

[avr@localhost src]$ find .|grep .cpp$ | sed -e "s/^\ */cat\ /" | bash \
| wc -l
72372
[avr@localhost src]$ find .|grep .h$ | sed -e "s/^\ */cat\ /" | bash \
| wc -l
48517

I should have said hundreds of thousands, I guess ;-). And probably
there aren't 20 employees. Maybe 15. And some are interns like me.

Just curious.

Of course one of the problems of having so many programmers is that you can
spend all your time ensuring good communication between each other so that
you don't have any time for coding, which just encourages management to hire
even more programmers, which just makes the problem worse. See The Mythical
I agree. This is more so if you don't have regular team meetings etc.
We do, fortunately.
Man Month by Frederick P Brooks.

john

[John Harrison]

"AVR" <an*******@no.spy.spam.mac.net> wrote in message
news:cd**********@news01.intel.com...

John Harrison wrote:

I'm working on a tool which has several thousand lines of code, and
around 20 developers working concurrently.

I've just read that again. You need 20 programmers for several thousand

Sorry for posting twice. I didn't realize.

You didn't post twice, I just read twice.

lines of code! Do you all work one day a week or something? Or does
management keep you so busy with admin that you don't have any time for
programming?

I wasn't concentrating on specifics earlier. I just checked and:

[avr@localhost src]$ find .|grep .cpp$ | sed -e "s/^\ */cat\ /" | bash \
| wc -l
72372
[avr@localhost src]$ find .|grep .h$ | sed -e "s/^\ */cat\ /" | bash \
| wc -l
48517

I should have said hundreds of thousands, I guess ;-). And probably
there aren't 20 employees. Maybe 15. And some are interns like me.

Still seems very high to me. Here's a project I'm involved in

cat `find . -name *.cpp` | wc -l
68287

cat `find . -name *.h ` | wc -l
13900

cat `find . -name *.java` | wc -l
158184

Six programmers, all of us part time (in that we work on other projects as
well). I guess your deadlines are tighter than ours!

john