$ & _

[antianti]

Hi folks,

When in the history of C did it become acceptable to use $
in a variable or function name?

Why do some people say that it is a bad idea to begin
a variable name with an underscore?

Is it bad form to have a variable or function that is a
single $ or _ ?

Thanks.

[Richard Heathfield]

an******@rocketmail.com said:

Hi folks,

When in the history of C did it become acceptable to use $
in a variable or function name?

As far as I know, it's never been legal to do that in a C program. If you
do so, implementations are free to reject your program. Conversely, they
are free to accept it - this is one of those situations where an
implementation can extend the language, at the expense of portability to
implementations that haven't extended it in that direction with that
syntax. I guess that you have encountered such an extension.

Why do some people say that it is a bad idea to begin
a variable name with an underscore?

In certain circumstances (and by no means obscure or unlikely
circumstances), the Standard reserves identifiers beginning with an
underscore for exclusive use by the implementation. The idea is to reduce
the likelihood of a conflict between the implementation's identifiers and
your own. If you go around _starting _identifiers _with _underscores _all
_over _the _place, you are increasing that likelihood. So it's a bad idea,
so don't do it.

Is it bad form to have a variable or function that is a
single $ or _ ?

It depends on whether you are composing an entry for the IOCCC.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

an******@rocketmail.com writes:

When in the history of C did it become acceptable to use $
in a variable or function name?

Never. Some compilers may accept it, but only as a non-standard
extension.

Why do some people say that it is a bad idea to begin
a variable name with an underscore?

Because names starting with underscores are reserved to the
implementation. For example, an implementation is free to define
__FOO as a macro in <stdio.h>, or even to predefine it without putting
it in a header. If you then try to declare "int _FOO = 42;", your
__FOO will be replaced with the macro definition.

Actually the rule is a bit more complicated than that, and *some*
identifiers starting with underscores are safe to use in *some*
circumstances (it depends on whether the initial underscore is
followed by another underscore, by an uppercase letter, or by
something else). But it's easier just to avoid such identifiers
altogether. It's not as if there were a shortage of valid identifiers
that *don't* start with an underscore. You can even use trailing
underscores if you like.

Is it bad form to have a variable or function that is a
single $ or _ ?

Yes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Jack Klein]

On Sun, 27 Jul 2008 17:48:57 -0700 (PDT), an******@rocketmail.com
wrote in comp.lang.c:

Hi folks,

When in the history of C did it become acceptable to use $
in a variable or function name?

Never. This is an extension provided by some compilers. It is not
part of the C language.

Why do some people say that it is a bad idea to begin
a variable name with an underscore?

Identifiers beginning with two consecutive underscores are reserved
for the implementation in all contexts. Identifiers beginning with a
single underscore are reserved for the implementation

Is it bad form to have a variable or function that is a
single $ or _ ?

It is bad form to have any identifier containing a '$' character, even
on a compiler that accepts this as an extension, because it makes the
code non-standard and non-portable.

It is bad form to have an identifier consisting of a single underscore
unless you are the implementation, that is a programmer or maintainer
of the compiler itself or its library.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[antianti]

On Jul 27, 9:58*pm, Keith Thompson <[e-mail]:

Is it bad form to have a variable or function that is a
single $ or _ ?

Yes.

Why?

I'm reminded how in Javascript some clever person defined
something like this
function $(name) {
return getElementById(name);
}
which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.

[CBFalconer]

an******@rocketmail.com wrote:

>
When in the history of C did it become acceptable to use $
in a variable or function name?

It never did.

Why do some people say that it is a bad idea to begin a
variable name with an underscore?

Because those names are (more or less) reserved for the
implementor.

Is it bad form to have a variable or function that is a
single $ or _ ?

You can't use the '$'.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

Jack Klein <ja*******@spamcop.netwrites:

On Sun, 27 Jul 2008 17:48:57 -0700 (PDT), an******@rocketmail.com
wrote in comp.lang.c:

[...]

>Why do some people say that it is a bad idea to begin
a variable name with an underscore?

Identifiers beginning with two consecutive underscores are reserved
for the implementation in all contexts. Identifiers beginning with a
single underscore are reserved for the implementation

Actually, the rule is (C99 7.1.3):

All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for any
use.

All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary and
tag name spaces.

An easier rule to remember is:

All identifiers that begin with an underscore are always reserved
for any use.

It's not the rule the standard actually imposes, but as a programmer
you can't go wrong by pretending that it is. (You can declare
"int _foo;" at block scope, but why would you want to?)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

an******@rocketmail.com wrote:

On Jul 27, 9:58 pm, Keith Thompson <[e-mail]:

>>Is it bad form to have a variable or function that is a
single $ or _ ?

Yes.

Why?

I'm reminded how in Javascript some clever person defined
something like this
function $(name) {
return getElementById(name);
}
which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.

Or an abomination, depending on who you ask.

--
Ian Collins.

[Peter Nilsson]

Keith Thompson wrote:

...
An easier rule to remember is:

All identifiers that begin with an underscore are always reserved
for any use.

It's not the rule the standard actually imposes, but as a programmer
you can't go wrong by pretending that it is. (You can declare
"int _foo;" at block scope, but why would you want to?)

One case would be in a function macro that's defined as a do/while
block and uses a temporary. The temporary name is subject to
macro expansion and can also accidentally hide parameter
arguments on invokation. So you need a naming convention that
mitigates this. Unfortunately, a lot of people choose a leading
underscore.

The other common bad use of leading underscores are struct tags
and include guards.

--
Peter

[Giacomo Catenazzi]

an******@rocketmail.com wrote:

Is it bad form to have a variable or function that is a
single $ or _ ?

GNU gettext uses _ as a macro

for non internationalized programs:
#define _(String) (String)
and for internationalized programs:
#define _(String) gettext (String)

gettext used _ to simplify internationalization
of existing program, with few readability impacts
(and few worry for authors which doesn't know details
about gettext)

ciao
cate

[Flash Gordon]

an******@rocketmail.com wrote, On 28/07/08 03:09:

On Jul 27, 9:58 pm, Keith Thompson <[e-mail]:

>>Is it bad form to have a variable or function that is a
single $ or _ ?

Yes.

Why?

Tell me what the following code fragment does on an implementation where
$ is a valid identifier.

*$(-_)=0;

I don't just means what functions are called, but exactly what you think
will happen. Then consider the following code which does something
different:

int salary =
Search(employee_list,Search(employee_list,"Fred")->boss_name)->salary;

The first is not more complex than the second, but which is more likely
to be understandable?
--
Flash Gordon

[Mark McIntyre]

an******@rocketmail.com wrote:

On Jul 27, 9:58 pm, Keith Thompson <[e-mail]:

>>Is it bad form to have a variable or function that is a
single $ or _ ?

Yes.

Why?

Think about hte poor maintainer trying to get your code working later.

Which code fragment is more informative?
reload_database(foo,bar);
$(foo,bar);

I'm reminded how in Javascript some clever person defined
something like this
function $(name) {

Personally I consider that horrible for the exact reason stated above.

which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.

Well, it was a solution. There's nothing especially clever about it to
be honest.

And holding up Javascript as an example of programming excellence is a
bit like holding up the Golden Arches as an example of haute cuisine.....

[santosh]

Peter Nilsson wrote:

Keith Thompson wrote:

>...
An easier rule to remember is:

All identifiers that begin with an underscore are always reserved
for any use.

It's not the rule the standard actually imposes, but as a programmer
you can't go wrong by pretending that it is. (You can declare
"int _foo;" at block scope, but why would you want to?)

One case would be in a function macro that's defined as a do/while
block and uses a temporary. The temporary name is subject to
macro expansion and can also accidentally hide parameter
arguments on invokation. So you need a naming convention that
mitigates this. Unfortunately, a lot of people choose a leading
underscore.

What is your preferred method of dealing with this?

The other common bad use of leading underscores are struct tags
and include guards.

[Ian Collins]

Mark McIntyre wrote:

an******@rocketmail.com wrote:

>I'm reminded how in Javascript some clever person defined
something like this
function $(name) {

Personally I consider that horrible for the exact reason stated above.

>which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.

Well, it was a solution. There's nothing especially clever about it to
be honest.

And holding up Javascript as an example of programming excellence is a
bit like holding up the Golden Arches as an example of haute cuisine.....

That's more than a little unfair. The $ abomination comes form one
particular library, which many of us JavaScript programmers despise.
JavaScript is a most enjoyable language to craft excellent code.

--
Ian Collins.

[santosh]

Ian Collins wrote:

Mark McIntyre wrote:

>an******@rocketmail.com wrote:

>>I'm reminded how in Javascript some clever person defined
something like this
function $(name) {

Personally I consider that horrible for the exact reason stated
above.

>>which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.

Well, it was a solution. There's nothing especially clever about it
to be honest.

And holding up Javascript as an example of programming excellence is
a bit like holding up the Golden Arches as an example of haute
cuisine.....

That's more than a little unfair. The $ abomination comes form one
particular library, which many of us JavaScript programmers despise.
JavaScript is a most enjoyable language to craft excellent code.

I suppose that the innumerable JavaScript associated vulnerabilities
with various web browsers tends to tarnish the language's image, just
like the association between VB and viruses or between assembler and
viruses.

[Ian Collins]

santosh wrote:

Ian Collins wrote:

>Mark McIntyre wrote:

>>an******@rocketmail.com wrote:

I'm reminded how in Javascript some clever person defined
something like this
function $(name) {
Personally I consider that horrible for the exact reason stated
above.

which is now considered standard. It's wasn't something
that the language designers had planned but it was
a clever solution to a common problem.
Well, it was a solution. There's nothing especially clever about it
to be honest.

And holding up Javascript as an example of programming excellence is
a bit like holding up the Golden Arches as an example of haute
cuisine.....

That's more than a little unfair. The $ abomination comes form one
particular library, which many of us JavaScript programmers despise.
JavaScript is a most enjoyable language to craft excellent code.

I suppose that the innumerable JavaScript associated vulnerabilities
with various web browsers tends to tarnish the language's image, just
like the association between VB and viruses or between assembler and
viruses.

Not to mention C and buffer overflows :) Although the browser
vulnerabilities are faults of the implementation, not the language.

--
Ian Collins.

[Mark McIntyre]

Ian Collins wrote:

>And holding up Javascript as an example of programming excellence is a
bit like holding up the Golden Arches as an example of haute cuisine.....

That's more than a little unfair. The $ abomination comes form one
particular library, which many of us JavaScript programmers despise.
JavaScript is a most enjoyable language to craft excellent code.

Hmm. I use javascript myself, but its not exactly a paragon of good design.

[blargg]

In article <GB******************@flpi146.ffdc.sbc.com>, "Mabden"
<Ma****@sbcglobal.netwrote:

...
I kinda tend to the "Mongol Horde" mentality when the discussion
gets to stupid superfical stuff, or if you can't convince me you are worthy
to have an opinion. This is one of those kind of questions, ie "Why is VB
case-insensitive: I want my Prt and PRT functions to work together?" Well,
they won't - so get over it and rename one. There's NO work-around (worth
doing) so suck it up and move forward. Same with this rule.

I've found that knowing why things are the case often tunes my intuition
to that of the designer(s). The more tuned, the more I can "cheat" and
just know how the language works without even having read the standard
(not that one should avoid the standard, just that this makes it less
surprising and arbitrary seeming).

[santosh]

blargg wrote:

<snip>

I've found that knowing why things are the case often tunes my
intuition to that of the designer(s). The more tuned, the more I can
"cheat" and just know how the language works without even having read
the standard (not that one should avoid the standard, just that this
makes it less surprising and arbitrary seeming).

I would've thought that reading the Standard (or a digestible version of
it like Harbison & Steele) would make for lesser surprises and
arbitrariness than random implementations.

Also learning all the details of the C language by just studying an
implementation (obviously one which is perfectly conforming) is next to
impossible, without an authoritative reference like K&R (for C90, and
not quite comprehensive), Harbison & Steele or the Standard itself.

[CBFalconer]

blargg wrote:

"Mabden" <Ma****@sbcglobal.netwrote:

>...
I kinda tend to the "Mongol Horde" mentality when the discussion
gets to stupid superfical stuff, or if you can't convince me you
are worthy to have an opinion. This is one of those kind of
questions, ie "Why is VB case-insensitive: I want my Prt and PRT
functions to work together?" Well, they won't - so get over it
and rename one. There's NO work-around (worth doing) so suck it
up and move forward. Same with this rule.

I've found that knowing why things are the case often tunes my
intuition to that of the designer(s). The more tuned, the more I
can "cheat" and just know how the language works without even
having read the standard (not that one should avoid the standard,
just that this makes it less surprising and arbitrary seeming).

So simply read the available documentation, including the standard
(marked as C99 below).

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2(C99, txt)
<http://www.dinkumware.com/c99.aspx (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **