exporting duplicate symbols 
Author Message
 exporting duplicate symbols

Is there a way in standard C to cause two or more symbol names to be
exported which refer to the same exact externally referenceable
object?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://www.*-*-*.com/ |

-----------------------------------------------------------------



Fri, 29 Aug 2003 21:59:12 GMT  
 exporting duplicate symbols

Quote:
> Is there a way in standard C to cause two or more symbol names to be
> exported which refer to the same exact externally referenceable
> object?

I am confused! Please explain in more detail.

--

"LISP  is worth learning for  the profound enlightenment  experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days."   -- Eric S. Raymond



Fri, 29 Aug 2003 22:53:53 GMT  
 exporting duplicate symbols

Quote:

>Is there a way in standard C to cause two or more symbol names to be
>exported which refer to the same exact externally referenceable
>object?

No.  This is usually trivial in assembly, but C is not assembler
(much as one might sometimes wish :-) ).

If your C compiler has an "assembler escape", or you have an
assembler that works with the compiler, you can use that.  Obviously
this will not be portable.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc


Note: PacBell news service is rotten



Sat, 30 Aug 2003 00:33:56 GMT  
 exporting duplicate symbols


|> Is there a way in standard C to cause two or more symbol names to be
|> exported which refer to the same exact externally referenceable
|> object?
|>
|
| I am confused! Please explain in more detail.

Chris Torek provided a confident answer.  But I'll still explain.

When a symbol is exported, it represents a specific relocateable
point in a program object for some purpose.  It may be a global
variable or a function name.  Maybe something else, too.  What
I was looking for is a way to export 2 or more symbols so that
all of them refer to the same exact point in the object file.

Alternatives to this include:

1.  For functions, make the alias function simply call the function
    it is an alias for.  This is not a true alias, but close enough.
    This can't be done portably if the function involved uses a
    variable argument list, and a "v" version isn't available.

2.  At the C level, use #define to allow the symbol to be referenced
    with a different name in the source.  There will be only one
    actually exported symbol.  If one is trying to make symbols for
    already compiled programs to link to, with different names, this
    will not work.

3.  What Chris Torek said, the non-portable use of assembly language.
    Alternatively some linkers may provide a mechanism to create a
    symbol equal to another, but this is also non-portable.

Final answer: no trivial portable solution.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Sat, 30 Aug 2003 01:53:09 GMT  
 exporting duplicate symbols

Quote:


> |> Is there a way in standard C to cause two or more symbol names to be
> |> exported which refer to the same exact externally referenceable
> |> object?
> |>
> |
> | I am confused! Please explain in more detail.

> Chris Torek provided a confident answer.  But I'll still explain.

> When a symbol is exported, it represents a specific relocateable
> point in a program object for some purpose.  It may be a global
> variable or a function name.  Maybe something else, too.  What
> I was looking for is a way to export 2 or more symbols so that
> all of them refer to the same exact point in the object file.

If two symbols have exactly the same signature
(definition/declaration) and are used in exactly the
same way, what would you gain from having two symbols?

Quote:
> Alternatives to this include:

> 1.  For functions, make the alias function simply call the function
>     it is an alias for.  This is not a true alias, but close enough.
>     This can't be done portably if the function involved uses a
>     variable argument list, and a "v" version isn't available.

Well I suppose you could be using some sort of function
pointer construct or simply write a wrapper function
that calls the aliased function.

Quote:

> 2.  At the C level, use #define to allow the symbol to be referenced
>     with a different name in the source.  There will be only one
>     actually exported symbol.  If one is trying to make symbols for
>     already compiled programs to link to, with different names, this
>     will not work.

If you have precompiled libraries, you'll probably have to use
exactly the symbols defined inside the library. Otherwise
write macros to convert to exactly these symbols.

Quote:

> 3.  What Chris Torek said, the non-portable use of assembly language.
>     Alternatively some linkers may provide a mechanism to create a
>     symbol equal to another, but this is also non-portable.

> Final answer: no trivial portable solution.

If you explain your actual goal a little bit, there probably
is a trivial sollution, one you may not have thought of.

--

"LISP  is worth learning for  the profound enlightenment  experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days."   -- Eric S. Raymond



Sat, 30 Aug 2003 16:37:39 GMT  
 exporting duplicate symbols

| If two symbols have exactly the same signature
| (definition/declaration) and are used in exactly the
| same way, what would you gain from having two symbols?
|
|> Alternatives to this include:
|>
|> 1.  For functions, make the alias function simply call the function
|>     it is an alias for.  This is not a true alias, but close enough.
|>     This can't be done portably if the function involved uses a
|>     variable argument list, and a "v" version isn't available.
|
| Well I suppose you could be using some sort of function
| pointer construct or simply write a wrapper function
| that calls the aliased function.

Yes, I could.  That's what I wanted to avoid.

|> 2.  At the C level, use #define to allow the symbol to be referenced
|>     with a different name in the source.  There will be only one
|>     actually exported symbol.  If one is trying to make symbols for
|>     already compiled programs to link to, with different names, this
|>     will not work.
|
| If you have precompiled libraries, you'll probably have to use
| exactly the symbols defined inside the library. Otherwise
| write macros to convert to exactly these symbols.

I have precompiled executeables that use different symbols.

|> 3.  What Chris Torek said, the non-portable use of assembly language.
|>     Alternatively some linkers may provide a mechanism to create a
|>     symbol equal to another, but this is also non-portable.
|>
|> Final answer: no trivial portable solution.
|>
|
| If you explain your actual goal a little bit, there probably
| is a trivial sollution, one you may not have thought of.

To avoid the wrapper function.

I've also found in another thread another use for this.  Functions like
strchr() which take a (const char *) and return it as (char *) are
technically a "loophole" in the C typing system.  What I would rather
see are 2 versions of the function, one with const, and one without.
The generated code would be the same.  The prototype in the header
would be different.  It would ensure that if you used a const pointer
as an argument, you could not (accidentally) assign it to a non-const
pointer and end up clobbering something without at least a proper
warning.  Of course that can stil be done with a wrapper or just
duplicate code.  But if there was an easy way to avoid it I would
have wanted to know it.  Apparently there is not.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Sat, 30 Aug 2003 20:27:42 GMT  
 exporting duplicate symbols

...

Quote:
> I've also found in another thread another use for this.  Functions like
> strchr() which take a (const char *) and return it as (char *) are
> technically a "loophole" in the C typing system.  What I would rather
> see are 2 versions of the function, one with const, and one without.
> The generated code would be the same.  The prototype in the header
> would be different.  [and const-safe]

This is a different problem; here you need two (apparently) visible
declarations for the _same_ name, and maybe the same code.

C++ has such overloading, and uses it to make the C library
(which it retains in addition to adding a whole bunch of new
C++-only stuff) const-safe in the way you want.  Assuming
a system with a reasonable C++ implementation available,
you might consider writing in the "better C" subset of C++
and you can still port to C-only systems if needed.  (If you
have precompiled, perhaps 3rd-party, C code, make sure
you get a C++ compiler that interoperates correctly with
the appropriate C compiler; this is common but not really
guaranteed/required.)  <PEDANTIC> C++ is not strictly
a superset of C:  there are some legal C programs that
either are illegal in C++ or give different/wrong results.
But with a little care, any algorithm that can be written in C
can be written in the subset of C that is also correct as C++. </>
<HOPE> Please let's not have another debate about whether
Bjarne's judgement of what is "better" is really better or not.
Everyone can and should decide this for themselves. </>

C99 adds some fortran-like "generic" stdlib functions
in <tgmath.h> where the same name invokes a different
function depending on the argument (floating-point) type.
All implementations I know of so far use magic, but
there has been discussion (mostly by Tribble) of providing
this ability to user-defined functions, and IIRC Jacob Navia
is doing (or has done?) this in LCC.  If dejagoogle is working,
search comp.lang.c and comp.std.c a few months back,
or try (according to my notes) http://www.qss.cz/lcc
or http://www.q-software-solutions.com/lcc

--
- David.Thompson 1 now at worldnet.att.net



Wed, 10 Sep 2003 13:11:25 GMT  
 exporting duplicate symbols

Quote:


> ...
> > I've also found in another thread another use for this.  Functions like
> > strchr() which take a (const char *) and return it as (char *) are
> > technically a "loophole" in the C typing system.  What I would rather
> > see are 2 versions of the function, one with const, and one without.
> > The generated code would be the same.  The prototype in the header
> > would be different.  [and const-safe]

> This is a different problem; here you need two (apparently) visible
> declarations for the _same_ name, and maybe the same code.

Many moons ago I designed an object linking system.  It included
the ability to input equates, something like:

     mysillyroutine=strcmp

at link time.  Using this eliminated the need to ever define
mysillyroutine, and all calls to it would actually use strcmp.
Its primary use was to make different libraries that performed the
same function equivalent.

Since it did it all on a name basis, it worked equally well for
data ids.

--

http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Thu, 11 Sep 2003 00:20:58 GMT  
 exporting duplicate symbols


| ...
|> I've also found in another thread another use for this.  Functions like
|> strchr() which take a (const char *) and return it as (char *) are
|> technically a "loophole" in the C typing system.  What I would rather
|> see are 2 versions of the function, one with const, and one without.
|> The generated code would be the same.  The prototype in the header
|> would be different.  [and const-safe]
|
| This is a different problem; here you need two (apparently) visible
| declarations for the _same_ name, and maybe the same code.

It could be solved in a different way.  But it could also be solved
by overloading the linked symbol, too.

| C++ has such overloading, and uses it to make the C library
| (which it retains in addition to adding a whole bunch of new
| C++-only stuff) const-safe in the way you want.  Assuming
| a system with a reasonable C++ implementation available,
| you might consider writing in the "better C" subset of C++

What subset of C++ does you consider to be "better C"?  Is there some
document (maybe that you wrote or read) that details this?  I am not
of the opinion that C++ (in whole) is better than C (instead, I think
it is different than C, like measuring oranges and limes for "best
citrus fruit").

| and you can still port to C-only systems if needed.  (If you
| have precompiled, perhaps 3rd-party, C code, make sure
| you get a C++ compiler that interoperates correctly with
| the appropriate C compiler; this is common but not really
| guaranteed/required.)  <PEDANTIC> C++ is not strictly
| a superset of C:  there are some legal C programs that
| either are illegal in C++ or give different/wrong results.

Or at least "unexpected" :-)

| But with a little care, any algorithm that can be written in C
| can be written in the subset of C that is also correct as C++. </>
| <HOPE> Please let's not have another debate about whether
| Bjarne's judgement of what is "better" is really better or not.
| Everyone can and should decide this for themselves. </>

Agreed.

| C99 adds some Fortran-like "generic" stdlib functions
| in <tgmath.h> where the same name invokes a different
| function depending on the argument (floating-point) type.
| All implementations I know of so far use magic, but
| there has been discussion (mostly by Tribble) of providing
| this ability to user-defined functions, and IIRC Jacob Navia
| is doing (or has done?) this in LCC.  If dejagoogle is working,
| search comp.lang.c and comp.std.c a few months back,
| or try (according to my notes) http://www.qss.cz/lcc
| or http://www.q-software-solutions.com/lcc

I haven't looked at that, but IWSTM that one easy way to express
something like type checking in macro "functions" would be to put
casts in the prototypes, such as:

#define sin((double)x) dsin((x))
#define sin((long double)x) ldsin((x))

Obviously the preprocessor would have to sort this out, and it would
not know the types of symbols or expressions at macro expansion time,
so it may not be practical.  OTOH, merging preprocess and compiler
may be the only way to make smarter macros.  I don't know what C++
has done in this area since I haven't used C++.

Many times I have some function I wrote using, for example, type long
as an argument, but would be suitable to use for type int if I made
a cast to handle the cases where the host platform has a different size
for int and long.  Rather than code a separate function I just code a
macro to cast it from a different name:

void print_long(long value) { ... }

#define print_int(value) print_long((long)(value))

The problem I run into with that is that the casting destroys the
type checking I can get with normal prototypes.  Some way to define
a function alias/macro at the the compiler (rather than preprocessor)
level would be a nice feature.  I just don't want the "baggage" I
would get from C++ to go with what it has.

BTW, I don't want to start the C vs C++ debate either.  As long as
people respect the fact that I do not want to use C++ for reasons
I prefer to keep off this thread, they shouldn't be posting things
like "why not just use C++ since it has what you want".  There are
people who do believe that this language or that language is better.
I know what language is better for _me_ and that's not a topic of
any debate.  If C people "steal" some of the ideas from C++ people,
the C++ people should be proud of that, instead of being offended
because the C people didn't take the whole thing.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Thu, 11 Sep 2003 01:29:01 GMT  
 exporting duplicate symbols

Quote:


>| you might consider writing in the "better C" subset of C++

>What subset of C++ does you consider to be "better C"?  Is there some
>document (maybe that you wrote or read) that details this?  I am not
>of the opinion that C++ (in whole) is better than C (instead, I think
>it is different than C, like measuring oranges and limes for "best
>citrus fruit").

If this is so, then...

Quote:
>I haven't looked at that, but IWSTM that one easy way to express
>something like type checking in macro "functions" would be to put
>casts in the prototypes, such as:

>#define sin((double)x) dsin((x))
>#define sin((long double)x) ldsin((x))

...maybe not easy, but at least different.

Quote:
>Obviously the preprocessor would have to sort this out, and it would
>not know the types of symbols or expressions at macro expansion time,
>so it may not be practical.  OTOH, merging preprocess and compiler
>may be the only way to make smarter macros.  I don't know what C++
>has done in this area since I haven't used C++.

...maybe not smarter, but at least different.

Quote:
>The problem I run into with that is that the casting destroys the
>type checking I can get with normal prototypes.  Some way to define
>a function alias/macro at the the compiler (rather than preprocessor)
>level would be a nice feature.  I just don't want the "baggage" I
>would get from C++ to go with what it has.

...maybe not nice, but at least different.

Quote:
>BTW, I don't want to start the C vs C++ debate either.

Perhaps, but I often see posts harping on one word, and then
continuing in the same vein.

Quote:
>As long as
>people respect the fact that I do not want to use C++ for reasons
>I prefer to keep off this thread, they shouldn't be posting things
>like "why not just use C++ since it has what you want".

But since it might have what you want, that is not an unreasonable
suggestion.  So-called sidebars, or secondary responses to some
things definitely have their place.  If they are deemed unimportant,
then they can be discarded.

Quote:
>There are
>people who do believe that this language or that language is better.
>I know what language is better for _me_ and that's not a topic of
>any debate.

I think that's fine and uncontroversial.

Quote:
>If C people "steal" some of the ideas from C++ people,
>the C++ people should be proud of that, instead of being offended
>because the C people didn't take the whole thing.

I don't think C++ people are getting offended over that.
--
Greg Comeau                 Comeau C/C++ 4.2.45.2 "it's so close"
ONLINE COMPILER ==>         http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo!       NEW: Try out our C99 mode!



Thu, 11 Sep 2003 10:26:16 GMT  
 exporting duplicate symbols

| Many moons ago I designed an object linking system.  It included
| the ability to input equates, something like:
|
|      mysillyroutine=strcmp
|
| at link time.  Using this eliminated the need to ever define
| mysillyroutine, and all calls to it would actually use strcmp.
| Its primary use was to make different libraries that performed the
| same function equivalent.
|
| Since it did it all on a name basis, it worked equally well for
| data ids.

Sounds like just what I want.  Interestingly, I found ways to do
this easily when I worked on IBM mainframes.  Maybe some ELF .o
hacking could pull off the same thing.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Fri, 12 Sep 2003 11:12:43 GMT  
 exporting duplicate symbols

|>BTW, I don't want to start the C vs C++ debate either.
|
| Perhaps, but I often see posts harping on one word, and then
| continuing in the same vein.

Such as?  I know I wasn't saying one language or the other is
better, but I was refining my thought that some ideas of one
could be used to improve another.  Of course someone might think
the idea stinks and would not be an improvement.  But that would
be a different issue than one whole language vs another.

|>As long as
|>people respect the fact that I do not want to use C++ for reasons
|>I prefer to keep off this thread, they shouldn't be posting things
|>like "why not just use C++ since it has what you want".
|
| But since it might have what you want, that is not an unreasonable
| suggestion.  So-called sidebars, or secondary responses to some
| things definitely have their place.  If they are deemed unimportant,
| then they can be discarded.

Well if someone does want to resume the C vs C++ debate (as if it
hasn't ever ended) then there's nothing I can do to stop them and
probably nothing to discourage it.  But I don't care to be a part
of it.

|>There are
|>people who do believe that this language or that language is better.
|>I know what language is better for _me_ and that's not a topic of
|>any debate.
|
| I think that's fine and uncontroversial.
|
|>If C people "steal" some of the ideas from C++ people,
|>the C++ people should be proud of that, instead of being offended
|>because the C people didn't take the whole thing.
|
| I don't think C++ people are getting offended over that.

I've met some who appear to be.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Fri, 12 Sep 2003 11:19:42 GMT  
 exporting duplicate symbols

Quote:


>|>BTW, I don't want to start the C vs C++ debate either.
>|
>| Perhaps, but I often see posts harping on one word, and then
>| continuing in the same vein.

>Such as?  I know I wasn't saying one language or the other is
>better, but I was refining my thought that some ideas of one
>could be used to improve another.  Of course someone might think
>the idea stinks and would not be an improvement.  But that would
>be a different issue than one whole language vs another.

Such as that I see harping about the use of the word better,
but other words about other things from harpers are often
in the same vein.  And yet, somehow their choice is ok.
Seems to me the context should be accepted in all cases or none.

Quote:
>|>As long as
>|>people respect the fact that I do not want to use C++ for reasons
>|>I prefer to keep off this thread, they shouldn't be posting things
>|>like "why not just use C++ since it has what you want".
>|
>| But since it might have what you want, that is not an unreasonable
>| suggestion.  So-called sidebars, or secondary responses to some
>| things definitely have their place.  If they are deemed unimportant,
>| then they can be discarded.

>Well if someone does want to resume the C vs C++ debate (as if it
>hasn't ever ended) then there's nothing I can do to stop them and
>probably nothing to discourage it.  But I don't care to be a part
>of it.

Saying that there is a debate resumes it.
Saying that you don't want to be part of it, means you are.
The point is that not all responsed in group X will always be
about X, some many be about Y.  That's just natural.  Sure,
enough of those responses will be out of order ("off-topic"),
but many will not be.  Just substituting "C++" for "Y" does
not mean anything.  The context does.

Quote:
>|>There are
>|>people who do believe that this language or that language is better.
>|>I know what language is better for _me_ and that's not a topic of
>|>any debate.
>|
>| I think that's fine and uncontroversial.
>|
>|>If C people "steal" some of the ideas from C++ people,
>|>the C++ people should be proud of that, instead of being offended
>|>because the C people didn't take the whole thing.
>|
>| I don't think C++ people are getting offended over that.

>I've met some who appear to be.

I though you/somebody meant the group as a whole.  Sure, there
are such individuals.  But the fair minded person also knows that
there are C persons of such a mindset, and therefore, doesn't even
mention it.  There may be a point here, but it isn't any of this.
--
Greg Comeau                 Comeau C/C++ 4.2.45.2 "it's so close"
ONLINE COMPILER ==>         http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo!       NEW: Try out our C99 mode!



Fri, 12 Sep 2003 13:18:41 GMT  
 exporting duplicate symbols

|>Well if someone does want to resume the C vs C++ debate (as if it
|>hasn't ever ended) then there's nothing I can do to stop them and
|>probably nothing to discourage it.  But I don't care to be a part
|>of it.
|
| Saying that there is a debate resumes it.

Believing that the debate has somehow ended doesn't make it so.

| Saying that you don't want to be part of it, means you are.

I have a side.  If that means to you that I am part of it, then
that is apparently the way you look at it.  I'm not actively
pursuing that debate here.

| The point is that not all responsed in group X will always be
| about X, some many be about Y.  That's just natural.  Sure,
| enough of those responses will be out of order ("off-topic"),
| but many will not be.  Just substituting "C++" for "Y" does
| not mean anything.  The context does.

Sure.  I can agree with that.

|>| I don't think C++ people are getting offended over that.
|>
|>I've met some who appear to be.
|
| I though you/somebody meant the group as a whole.  Sure, there
| are such individuals.  But the fair minded person also knows that
| there are C persons of such a mindset, and therefore, doesn't even
| mention it.  There may be a point here, but it isn't any of this.

The phrase "people say ..." is too often interpreted by some to mean
"everyone says ..." and by others to mean "a few people say ...".
I didn't mean to imply that everyone believes a certain way when I
identify a group and say there are people in that group who possess
a certain attitude.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------



Sun, 14 Sep 2003 15:28:26 GMT  
 exporting duplicate symbols

Quote:
> On Sat, 24 Mar 2001 05:11:25 GMT David Thompson


...

Quote:
> What subset of C++ does you consider to be "better C"?  Is there some
> document (maybe that you wrote or read) that details this?  ...

In quotes, it means what Stroustrup defined as IHO "better".
For details see BS3 = The C++ Programming Language 3ed
and/or D&E = The Design and Evolution of C++.
To oversimplify a long story, he designed C++ as C with
some (relatively few) things he considered dangerous/bad
removed and classes/OO and (later) templates and exceptions
added.  That intermediate stage, "bad" features removed
but none of the C++-specific stuff added, is "better C".

Quote:
> | C99 adds some Fortran-like "generic" stdlib functions
> | in <tgmath.h> ...
> | there has been discussion (mostly by Tribble) of providing
> | this ability to user-defined functions, and IIRC Jacob Navia
> | is doing (or has done?) this in LCC.  ...

> I haven't looked at that, but IWSTM that one easy way to express
> something like type checking in macro "functions" would be to put
> casts in the prototypes, such as:

> #define sin((double)x) dsin((x))
> #define sin((long double)x) ldsin((x))

#define's don't have prototypes, only "identifier" lists.  They are
more like "K&R1" (old-style, nonprototype) functions, but still
not the same.  Several possible syntaxes for a compiler (not
preprocessor) feature were discussed in the Tribble threads;
AIR the final result was something vaguely like yours:
  alias {
    sin(double x) = dsin(x);
    sin(long double x) = ldsin(x);
  };
This is from my memory; if you want his exact proposal
ISTR it is on his website (URL in his many articles) but
remember it is neither standardized nor implemented.

Quote:
> Obviously the preprocessor would have to sort this out, and it would
> not know the types of symbols or expressions at macro expansion time,
> so it may not be practical.  OTOH, merging preprocess and compiler
> may be the only way to make smarter macros.  I don't know what C++
> has done in this area since I haven't used C++.

Since the preprocessor currently doesn't know anything
about types (or scopes), this would be a _huge_ change.
Doing it in the compiler would seem likely to be very like
either the overloading or template functions now in C++.
<PEDANTIC>The standard doesn't require a separate
preprocessor and compiler, or even a compiler at all;
read preprocessing functionality and translation
phase 7 functionality as needed.</>

Quote:
> Many times I have some function I wrote using, for example, type long
> as an argument, but would be suitable to use for type int if I made
> a cast to handle the cases where the host platform has a different size
> for int and long.  Rather than code a separate function I just code a
> macro to cast it from a different name:

> void print_long(long value) { ... }

> #define print_int(value) print_long((long)(value))

This particular case doesn't require a cast.  Calling a function
having a visible prototype declaration with a long parameter,
using an int parameter, will convert (as-if by assignment).
In general most cases that can work right with a single
definition will work with a (single) prototype and no casts.

Quote:
> The problem I run into with that is that the casting destroys the
> type checking I can get with normal prototypes.  Some way to define
> a function alias/macro at the the compiler (rather than preprocessor)
> level would be a nice feature.  I just don't want the "baggage" I
> would get from C++ to go with what it has.

What baggage?  If you use only the "better C" subset,
on any decent implementation you should get the same
result as for C.  In fact most C++ compilers are actually
combined C and C++, and will produce exactly the same
object either way (except probably debugging symbols).
If you don't use any of the added stuff it "shouldn't" cost
you anything -- this is not a formal requirement, but is
as much "in the spirit of C++" as "do what the programmer
said if at all possible" is "in the sprit of C".

Quote:
> BTW, I don't want to start the C vs C++ debate either.  As long as
> people respect the fact that I do not want to use C++ for reasons
> I prefer to keep off this thread, they shouldn't be posting things
> like "why not just use C++ since it has what you want".  ...

Well, if C++ has the feature(s) you want, and C doesn't,
using C++ is certainly the quickest way to get them.
If you insist on having them in C, you will have to either
write or modify an implementation yourself to do it,
or persuade someone else to do so.  (And if you want
them in _Standard C_ you will have to persuade pretty
much all compiler vendors and most standards
"national bodies" to support the change.)

If you only hate C++, Ada also has overloading and generics
(and OO in a slightly different model).  However mixing
Ada and C, though probably possible, is likely to be
much less straightforward than mixing C++ and C.

--
- David.Thompson 1 now at worldnet.att.net



Mon, 22 Sep 2003 13:07:53 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. duplicate symbol table entries in libc.a

2. Turbo C 3.0, duplicated symbols when linking

3. Template Expansions produce duplicate symbol errors in Linker

4. duplicate 'new' symbols

5. Duplicate symbols when linking

6. Duplicate Resource Symbols

7. duplicate resource symbols in vc5

8. Exporting public symbols

9. Exported symbols & strings as longwords

10. Exporting symbols

11. My DLL exports some symbols but not all of them

12. API for reading exported symbols from DLL?

 

 
Powered by phpBB® Forum Software