Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Defining an alias

Reply
Thread Tools

Defining an alias

 
 
jacob navia
Guest
Posts: n/a
 
      12-19-2009
Sometimes you need to have two functions that have the same body.

For instance, in my container library I have a function
"Add" that will add an element at the end of the list,
and another "Pop" that will take out the first element of the list.

If you implement a queue as a list, the function "Enqueue" will be
the same as "Add", and "Dequeue" the same as "Pop". The only
way to do this in standardese is:

int Enqueue(List *l, void *item)
{
return Add(l,item);
}

This is wasteful since the call overhead is payed for
no reason.

The syntax for doing that under lcc-win is:

int __declspec(naked) SomeNewName(int a, int b) { }
int SomeOtherName(int a,int b)
{
// Here we have the real body of the function
}

The first declaration specifies a "naked" function i.e. one which
the compiler will treat as special and not generate any prologue
nor epilogue to it, and will not complain about missing return
values.

The second declaration is the body of the function. The first one
will be just an assembler label. It wilk take zero bytes of space.

"Naked" functions are supposed to be assembly language ones, by the way.

All this syntax is quite horrible. I am conforted however, because gcc
has an even uglier syntax:

http://gcc.gnu.org/onlinedocs/gcc-4....tributes.html:

The alias attribute causes the declaration to be emitted as an alias for another symbol, which must
be specified. For instance,

void __f () { /* Do something. */; }
void f () __attribute__ ((weak, alias ("__f")));


defines `f' to be a weak alias for `__f'. It is an error if `__f' is not defined in the same
translation unit.

It is not clear what "weak" means in this context, and I am not sure that
gcc does the same thing as lcc-win...

Any ideas? Which syntax would be better?

Thanks
 
Reply With Quote
 
 
 
 
Alan Curry
Guest
Posts: n/a
 
      12-19-2009
In article <hgh6b7$cbt$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> wrote:
>Sometimes you need to have two functions that have the same body.
>
>For instance, in my container library I have a function
>"Add" that will add an element at the end of the list,
>and another "Pop" that will take out the first element of the list.
>
>If you implement a queue as a list, the function "Enqueue" will be
>the same as "Add", and "Dequeue" the same as "Pop". The only
>way to do this in standardese is:
>
>int Enqueue(List *l, void *item)
>{
> return Add(l,item);
>}
>
>This is wasteful since the call overhead is payed for
>no reason.


Some people would just make it static inline in the header file, then there's
no overhead (if the compiler does inlines at all).

>
>The syntax for doing that under lcc-win is:
>
>int __declspec(naked) SomeNewName(int a, int b) { }
>int SomeOtherName(int a,int b)
>{
> // Here we have the real body of the function
>}


I see nothing that actually specifies where SomeNewName's "real body" is to
be found. Does it just take the next one in the source file? Adjacency in the
source code seems like a flimsy thing to rely on.

>http://gcc.gnu.org/onlinedocs/gcc-4....tributes.html:
>
>The alias attribute causes the declaration to be emitted as an alias for
>another symbol, which must
>be specified. For instance,
>
> void __f () { /* Do something. */; }
> void f () __attribute__ ((weak, alias ("__f")));
>
>
>defines `f' to be a weak alias for `__f'. It is an error if `__f' is not
>defined in the same
>translation unit.


weak symbols are used in libraries (libc especially) to provide a function
that is available in the user's namespace, but will get out of the way if he
provides his own definition. So you can call a non-stdc function like fork()
and the linker will find the one in libc, or you can have your own global
variable called fork in a plain C program and the linker won't complain about
the conflict, since the one in libc is weak.

The double-underscore version of the function is there because the
implementation of standard C functions needs to call the non-stdc functions
sometimes. system() must call fork(), so it uses __fork() to avoid a conflict
in a program that makes use of system() but also has an unrelated global
variable or function named "fork". fopen() must call open(), so it calls
__open() which is a weak alias for open(), etc.

>
>It is not clear what "weak" means in this context, and I am not sure that
>gcc does the same thing as lcc-win...


The gcc syntax actually tells you that the 2 names are related, by having the
alias "__f" attribute attached to the declaration of f. They don't need to be
one right after the other in a specific order, like your "naked" thing does.

--
Alan Curry
 
Reply With Quote
 
 
 
 
Seebs
Guest
Posts: n/a
 
      12-19-2009
On 2009-12-19, jacob navia <(E-Mail Removed)> wrote:
> It is not clear what "weak" means in this context, and I am not sure that
> gcc does the same thing as lcc-win...


"weak" is a traditional thing in linkers at least on the recent unixy systems
I've used. A weak reference is a reference which exists if needed but not
found, but which never clashes with anything.

So, as an example: Some BSDish systems used to declare a symbol "end" which
referred to the end of the program's space, roughly. That could be a problem
if you defined a symbol named "end" and tried to call it or use it. So!
Solution is, make it a weak reference. If you refer to end and link without
providing anything named end, you pick that one up. If you provide your own,
yours wins.

This is often used to handle things where a given function name is in the
user's namespace but is traditional. For instance, in standard C, the user
is permitted to define a function named "open". In unix-land, open is a
standard system call, which is usually (but not always) accessed through a
C wrapper. The gcc approach would be that the library would provide a
symbol named something like __open or __syscall_open, and then a "weak
alias" under the name open.

> Any ideas? Which syntax would be better?


The gcc syntax is more flexible, because it can be used to refer to things
that aren't defined anywhere near you. You can have many references to a
single thing, and the "weak" reference allows you to ensure that you are
more resilient in the face of possible namespace clashes.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      12-19-2009
jacob navia wrote:
> Sometimes you need to have two functions that have the same body.
>
> For instance, in my container library I have a function
> "Add" that will add an element at the end of the list,
> and another "Pop" that will take out the first element of the list.
>
> If you implement a queue as a list, the function "Enqueue" will be
> the same as "Add", and "Dequeue" the same as "Pop". The only
> way to do this in standardese is:
>
> int Enqueue(List *l, void *item)
> {
> return Add(l,item);
> }
>
> This is wasteful since the call overhead is payed for
> no reason.


But surely most, if not all, compiler will inline such a trivial function?

<snip>

> All this syntax is quite horrible. I am conforted however, because gcc
> has an even uglier syntax:
>
> http://gcc.gnu.org/onlinedocs/gcc-4....tributes.html:
>
> The alias attribute causes the declaration to be emitted as an alias for
> another symbol, which must be specified. For instance,
>
> void __f () { /* Do something. */; }
> void f () __attribute__ ((weak, alias ("__f")));
>
>
> defines `f' to be a weak alias for `__f'. It is an error if `__f' is not
> defined in the same
> translation unit.
>
> It is not clear what "weak" means in this context, and I am not sure that
> gcc does the same thing as lcc-win...


The usual meaning (at least in Unix land) is described here:
http://en.wikipedia.org/wiki/Weak_symbol

The example above appears to be an extension of the weak symbol concept.

> Any ideas? Which syntax would be better?


Let the compiler inline the call.

--
Ian Collins
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      12-19-2009
jacob navia <(E-Mail Removed)> writes:
>the same as "Add", and "Dequeue" the same as "Pop". The only
>way to do this in standardese is:
>int Enqueue(List *l, void *item)
>{
> return Add(l,item);
>}


Why not

int (*Enqueue)(List *l, void *item) = Add;

?

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      12-19-2009
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>int (*Enqueue)(List *l, void *item) = Add;


Rereading this, I would like to add a »const«:

int (*const Enqueue)(List *l, void *item) = Add;

 
Reply With Quote
 
Beej Jorgensen
Guest
Posts: n/a
 
      12-19-2009
On 12/18/09 5:01 PM, Ian Collins wrote:
> But surely most, if not all, compiler will inline such a trivial function?
> Let the compiler inline the call.


Seconded. If that wasn't working, I'd probably use the function pointer
solution.

-Beej

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-19-2009
jacob navia a écrit :


(snip)

Thanks for the answers guys. Yes, the "static inline" syntax is better.

I think that the container library will require C99 then, and leave
Microsoft compilers out... They have inline, but I do not remember if
they accept it in C mode.

jacob
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-19-2009
jacob navia <(E-Mail Removed)> writes:
> jacob navia a écrit :
> (snip)
>
> Thanks for the answers guys. Yes, the "static inline" syntax is better.
>
> I think that the container library will require C99 then, and leave
> Microsoft compilers out... They have inline, but I do not remember if
> they accept it in C mode.


What's wrong with the const function pointer solution?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      12-19-2009
On 2009-12-19, Keith Thompson <(E-Mail Removed)> wrote:
> What's wrong with the const function pointer solution?


Can't be inlined.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
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
reference/alias in perl vs reference/alias in C++ grocery_stocker C++ 9 05-24-2008 04:32 AM
XP X64 Pro, IE7, Delphi 2007, IntraWeb, MS Access, ODBC Alias problem: Insufficient memory for this operation. Alias: SomeDatabase. Skybuck Flying Windows 64bit 13 01-09-2008 07:34 PM
what's incorrect ALIAS =?ISO-8859-15?Q?Stefan_Schw=E4rzler?= VHDL 1 08-04-2005 01:55 PM
[vhdl] how to wire two signals together? alias not adequate Khashishi VHDL 3 09-22-2004 10:36 PM
defining or not defining destructors johny smith C++ 8 07-02-2004 08:51 AM



Advertisments