Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > alternate function names

Reply
Thread Tools

alternate function names

 
 
phil-news-nospam@ipal.net
Guest
Posts: n/a
 
      12-09-2003
This question is borderline between language and programming, but I want to
focus more on the language standards issue, rather than the programming issue,
so I am posting here.

I have a number of functions which are front-ended by macros which make some
changes in the way the functions are called. There are various things being
done, but one simple example would be a function that takes a variable number
of (const char *) arguments and joins all the strings together into a single
string, where a NULL is the sentinel at the end of the arguments. The macro
front end adds that NULL so the calling program is less cluttered with detail.

What I have been doing with this is giving the macro the interface name and
naming the function slightly different. I have been putting a "_" in front
of the function name, which I want to get away from doing. So I have a macro
like:
#define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
and a function definition like:
char *_strjoin(const char *s,...)

The alternative I'm looking at is to just use the same name for both macro
and function, like:
#define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
and:
char *(strjoin)(const char *s,...)

This approach works, but I'm worried about confusion it may cause. So what I
want to do here is see if there is a better alternative to using a different
function name than the one shown above. Would lots of "_" characters help
avoid conflicts? Like maybe:
#define strjoin(a...) (__strjoin__(a,((const char*)(NULL))))
and:
char *__strjoin__(const char *s,...)

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
 
Reply With Quote
 
 
 
 
Morris Dovey
Guest
Posts: n/a
 
      12-09-2003
Phil...

Frankly, I'd rather code the NULL; and if I were a maintainer I
would prefer to see the NULL than spend time puzzling over a macro.

BTW, identifiers beginning with underscores or with "str" are
reserved. My multi-string concatenator started out as strs() and
became rtss() for this reason. )-:

--
Morris Dovey (WB0YEF)
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

 
Reply With Quote
 
 
 
 
phil-news-nospam@ipal.net
Guest
Posts: n/a
 
      12-09-2003
On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey <(E-Mail Removed)> wrote:

| Frankly, I'd rather code the NULL; and if I were a maintainer I
| would prefer to see the NULL than spend time puzzling over a macro.

I hold the opposite view. But if I were to find a suitable alternate name
for the function itself, you could code direct function calls and use the
NULL. I find it a big pain. My library is intended to remove many of the
pains in programming while still giving me C level access.


| BTW, identifiers beginning with underscores or with "str" are
| reserved. My multi-string concatenator started out as strs() and
| became rtss() for this reason. )-:

I already have a huge number of string functions. But one thing they all
do have is they begin with "str_" (the example I previously posted did not
show a real name from that library). I think it is more important to have
recognizable and understandable names for functions. I would not have
guessed what rtss() is even about without you saying so. So what did you
do, just reverse "str" to "rts" for everything?

Footnote 146 in the last draft for C99 shows usage of an identifier that
is reserved (7.1.3). What it's doing is hiding the reserved usage. So it
would seem to imply that such reservations do not apply behinds the scenes.
But it's unclear if this is an implemention C, or an implemention of something
in C.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
 
Reply With Quote
 
Simon Biber
Guest
Posts: n/a
 
      12-09-2003
<(E-Mail Removed)> wrote:
> On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey <(E-Mail Removed)> wrote:
> | BTW, identifiers beginning with underscores or with "str" are
> | reserved. My multi-string concatenator started out as strs() and
> | became rtss() for this reason. )-:
>
> I already have a huge number of string functions. But one thing
> they all do have is they begin with "str_" (the example I previously
> posted did not show a real name from that library).


Actually, "str_" is OK. The str prefix is only reserved when followed
by a lowercase letter.

Reserved identifiers include:

is[abcdefghijklmnopqrstuvwxyz]*
to[abcdefghijklmnopqrstuvwxyz]*
cerf
cerfc
cexp2
cexpm1
clog10
clog1p
clog2
clgamma
ctgamma
cerf[fl]
cerfc[fl]
cexp2[fl]
cexpm1[fl]
clog10[fl]
clog1p[fl]
clog2[fl]
clgamma[fl]
ctgamma[fl]
E[0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
PRI[abcdefghijklmnopqrstuvwxyzX]*
SCN[abcdefghijklmnopqrstuvwxyzX]*
LC_[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
SIG[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
SIG_[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
int*_t
uint*_t
INT*_MAX
INT*_MIN
INT*_C
UINT*_MAX
UINT*_MIN
UINT*_C
str[abcdefghijklmnopqrstuvwxyz]*
mem[abcdefghijklmnopqrstuvwxyz]*
wcs[abcdefghijklmnopqrstuvwxyz]*

--
Simon.


 
Reply With Quote
 
Morris Dovey
Guest
Posts: n/a
 
      12-09-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey
> <(E-Mail Removed)> wrote:
>
> | Frankly, I'd rather code the NULL; and if I were a
> | maintainer I would prefer to see the NULL than spend time
> | puzzling over a macro.
>
> I hold the opposite view. But if I were to find a suitable
> alternate name for the function itself, you could code direct
> function calls and use the NULL. I find it a big pain. My
> library is intended to remove many of the pains in programming
> while still giving me C level access.


Understandable - in my case I seem to have spent too much of my
career cleaning up other peoples' messes. It's been a real PIA to
run into (really messy) macro definitions that I need to
understand to eliminate as a contributor to the current mess; and
too often the problem has at least involved one of these macros.

> | BTW, identifiers beginning with underscores or with "str"
> | are reserved. My multi-string concatenator started out as
> | strs() and became rtss() for this reason. )-:
>
> I already have a huge number of string functions. But one
> thing they all do have is they begin with "str_" (the example
> I previously posted did not show a real name from that
> library). I think it is more important to have recognizable
> and understandable names for functions. I would not have
> guessed what rtss() is even about without you saying so. So
> what did you do, just reverse "str" to "rts" for everything?


I think nearly everyone eventually has a similar collection. In
my case, I did just what you inferred: I turned all the 'stirs'
into 'rats' (str --> rts). Visit http://www.iedu.com/mrd/c for a
representative sampling of the ugly naming.

> Footnote 146 in the last draft for C99 shows usage of an
> identifier that is reserved (7.1.3). What it's doing is
> hiding the reserved usage. So it would seem to imply that
> such reservations do not apply behinds the scenes. But it's
> unclear if this is an implemention C, or an implemention of
> something in C.


For more than you'd ever want to know about the subject, do a
Google groups search in comp.lang.c on "reserved str" (without
quotes) and prepare to see this beaten to death ( repeatedly

I adopted the attitude that since clients see my code I wouldn't
embarrass myself more than absolutely necessary. I changed the
names (growling all the while).
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

 
Reply With Quote
 
J. J. Farrell
Guest
Posts: n/a
 
      12-10-2003
(E-Mail Removed) wrote in message news:<(E-Mail Removed)>...
> This question is borderline between language and programming, but I want to
> focus more on the language standards issue, rather than the programming issue,
> so I am posting here.
>
> I have a number of functions which are front-ended by macros which make some
> changes in the way the functions are called. There are various things being
> done, but one simple example would be a function that takes a variable number
> of (const char *) arguments and joins all the strings together into a single
> string, where a NULL is the sentinel at the end of the arguments. The macro
> front end adds that NULL so the calling program is less cluttered with detail.
>
> What I have been doing with this is giving the macro the interface name and
> naming the function slightly different. I have been putting a "_" in front
> of the function name, which I want to get away from doing. So I have a macro
> like:
> #define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
> and a function definition like:
> char *_strjoin(const char *s,...)
>
> The alternative I'm looking at is to just use the same name for both macro
> and function, like:
> #define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
> and:
> char *(strjoin)(const char *s,...)
>
> This approach works, but I'm worried about confusion it may cause. So what I
> want to do here is see if there is a better alternative to using a different
> function name than the one shown above. Would lots of "_" characters help
> avoid conflicts? Like maybe:
> #define strjoin(a...) (__strjoin__(a,((const char*)(NULL))))
> and:
> char *__strjoin__(const char *s,...)


I've often seen the macro named as the upper-case version of the function,
so STRJOIN in your case. This is used to imply "essentially the same as
the function, but doing some fiddling about first before either providing
similar functionality or actually calling the function". It gives a clear
hint that it's probably related to the function, but also makes clear that
there must be something different about it.

You shouldn't be using tokens beginning with underscore, or with 'str'
followed by a lower case letter - they're reserved for the implementation.
There are rules about exactly when they are reserved, but it's simplest
to avoid them altogether.
 
Reply With Quote
 
Derk Gwen
Guest
Posts: n/a
 
      12-10-2003
# What I have been doing with this is giving the macro the interface name and
# naming the function slightly different. I have been putting a "_" in front
# of the function name, which I want to get away from doing. So I have a macro
# like:

You can have a function name the same as a #define with arguments. Parenthesise
the function name but not the #define:

#define xyzzy(parrot) (xyzzy)(parrot-2,parrot+2)
int (xyzzy)(int plugh,int plover);
int (xyzzy)(int plugh,int plover) {
return plugh*plover;
}

int main(int argc,char **argv) {
printf("%d\n",(xyzzy)(4,);
printf("%d\n",xyzzy(6));
return 0;
}

# #define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
# and a function definition like:
# char *_strjoin(const char *s,...)
#
# The alternative I'm looking at is to just use the same name for both macro
# and function, like:
# #define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
# and:
# char *(strjoin)(const char *s,...)
#
# This approach works, but I'm worried about confusion it may cause. So what I
# want to do here is see if there is a better alternative to using a different

As long as you use #defines with arguments and parenthesise the function name,
there will be no confusion in the compiler. (If you look at some of your
implementation standard headers, you'll see them doing this trick.) Whether
it confuses other programmers is a different issue.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
This is one wacky game show.
 
Reply With Quote
 
phil-news-nospam@ipal.net
Guest
Posts: n/a
 
      12-10-2003
On Wed, 10 Dec 2003 08:28:27 +1100 Simon Biber <(E-Mail Removed)> wrote:

| Actually, "str_" is OK. The str prefix is only reserved when followed
| by a lowercase letter.

OK, glad to hear that.


| Reserved identifiers include:

Do you have a citation? A C99 section number would do. I didn't see
it directly the way I searched, but maybe I missed an interpretation
of different parts in different places apart from each other.


| is[abcdefghijklmnopqrstuvwxyz]*

I have a few is_* names.


| str[abcdefghijklmnopqrstuvwxyz]*
| mem[abcdefghijklmnopqrstuvwxyz]*

And a few mem_* as well.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
 
Reply With Quote
 
phil-news-nospam@ipal.net
Guest
Posts: n/a
 
      12-10-2003
On Tue, 09 Dec 2003 16:01:10 -0600 Morris Dovey <(E-Mail Removed)> wrote:

| Understandable - in my case I seem to have spent too much of my
| career cleaning up other peoples' messes. It's been a real PIA to
| run into (really messy) macro definitions that I need to
| understand to eliminate as a contributor to the current mess; and
| too often the problem has at least involved one of these macros.

Well, I hope that ultimately, my code won't need to be cleaned up.

*knocks on wood*


| I think nearly everyone eventually has a similar collection. In
| my case, I did just what you inferred: I turned all the 'stirs'
| into 'rats' (str --> rts). Visit http://www.iedu.com/mrd/c for a
| representative sampling of the ugly naming.

OK, you showed yours, I'll show mine:
http://libh.slashusr.org/source/string/src/lib/h/

The main library page is just:
http://libh.slashusr.org/


| For more than you'd ever want to know about the subject, do a
| Google groups search in comp.lang.c on "reserved str" (without
| quotes) and prepare to see this beaten to death ( repeatedly

Being one to try things differently than told to do, I used the quotes
Your post came in number 2 (searched by relevance mode). The first one
that came up clarified a lot.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
 
Reply With Quote
 
phil-news-nospam@ipal.net
Guest
Posts: n/a
 
      12-10-2003
On 9 Dec 2003 16:26:54 -0800 J. J. Farrell <(E-Mail Removed)> wrote:

| I've often seen the macro named as the upper-case version of the function,
| so STRJOIN in your case. This is used to imply "essentially the same as
| the function, but doing some fiddling about first before either providing
| similar functionality or actually calling the function". It gives a clear
| hint that it's probably related to the function, but also makes clear that
| there must be something different about it.

I used to do that back when I didn't use macros very much. Now I use them
quite a lot. Many are front ends to functions. Many are just used on their
own without a function behind the scenes. I program using these functions
and macros a lot. And I've found code with so much UPPER CASE ALL OVER is
harder to read. Now I'm thinking more in terms of API design regardless of
whether I implement as macro or function.


| You shouldn't be using tokens beginning with underscore, or with 'str'
| followed by a lower case letter - they're reserved for the implementation.
| There are rules about exactly when they are reserved, but it's simplest
| to avoid them altogether.

Avoiding the beginning with underscore is the motivation of my original post
for this thread. My example of strjoin() was a bad choice of name. The
actual function is called str_dup_arg() because there are other variations
that do things like copy or append to a target, and accept strings in forms
like an array of pointers. You can view the actual source, still with the
leading underscore on the function name (which hopefully by the next version
will be changed), here:
http://libh.slashusr.org/source/stri.../str_dup_arg.c
That whole section (string) is being majorly changed, which inspired this
issue in the first place. Next version will be quite different.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
checking for mis-spelled variable names / function names News123 Python 2 11-26-2008 12:37 AM
what's 'alternate' in <link rel=alternate>? Chris ASP .Net 2 03-04-2007 04:45 PM
Alternate initializers or alternate class? transfire@gmail.com Ruby 10 07-17-2006 03:20 AM
member function names identical to class names Ares Lagae C++ 8 09-24-2004 11:23 AM
PEP 322 - alternate method names AC Python 0 08-26-2004 04:27 PM



Advertisments