Function Overloading

Discussion in 'C Programming' started by zeus, May 1, 2004.

  1. zeus

    zeus Guest

    I know function overloading is not supported in C.
    I have a few questions about this:
    1. Why? is it from technical reasons? if so, which?
    2. why wasn't it introduced to the ANSI?
    3. Is there any C implementation supporting this feature?

    I assume some of you will claim that there is no need in function
    overloading, so I would like to know your arguments too.

    Thanks,
    zeus
     
    zeus, May 1, 2004
    #1
    1. Advertising

  2. zeus <> scribbled the following:
    > I know function overloading is not supported in C.
    > I have a few questions about this:
    > 1. Why? is it from technical reasons? if so, which?
    > 2. why wasn't it introduced to the ANSI?
    > 3. Is there any C implementation supporting this feature?


    > I assume some of you will claim that there is no need in function
    > overloading, so I would like to know your arguments too.


    Function overloading is just compile-time syntactic sugar for functions
    with different names. It does not add any computational power or ease
    whatsoever.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "All that flower power is no match for my glower power!"
    - Montgomery Burns
     
    Joona I Palaste, May 1, 2004
    #2
    1. Advertising

  3. zeus

    Allan Bruce Guest

    "zeus" <> wrote in message
    news:...
    > I know function overloading is not supported in C.
    > I have a few questions about this:
    > 1. Why? is it from technical reasons? if so, which?
    > 2. why wasn't it introduced to the ANSI?
    > 3. Is there any C implementation supporting this feature?
    >
    > I assume some of you will claim that there is no need in function
    > overloading, so I would like to know your arguments too.
    >
    > Thanks,
    > zeus


    Function overloading is supported in C. Valid overloaded functions are
    those that have different arguements, and possible different return types,
    however an invalid overloaded set of functions is those that differ only by
    return type, i.e.

    /* Valid overlaoded functions */
    int DoSomething(void);
    int DoSomething(int);
    double DoSomething(double);
    void DoSomething(char, int, long);

    /* invalid */
    doulbe DoSomething(void); /* already have a void arg above but with int
    returned */

    HTH
    Allan
     
    Allan Bruce, May 1, 2004
    #3
  4. zeus

    CBFalconer Guest

    Allan Bruce wrote:
    > "zeus" <> wrote in message
    >
    >> I know function overloading is not supported in C.
    >> I have a few questions about this:
    >> 1. Why? is it from technical reasons? if so, which?
    >> 2. why wasn't it introduced to the ANSI?
    >> 3. Is there any C implementation supporting this feature?
    >>
    >> I assume some of you will claim that there is no need in function
    >> overloading, so I would like to know your arguments too.

    >
    > Function overloading is supported in C. Valid overloaded functions
    > are those that have different arguements, and possible different
    > return types, however an invalid overloaded set of functions is
    > those that differ only by return type, i.e.
    >
    > /* Valid overlaoded functions */
    > int DoSomething(void);
    > int DoSomething(int);
    > double DoSomething(double);
    > void DoSomething(char, int, long);
    >
    > /* invalid */
    > doulbe DoSomething(void); /* already have a void arg above but with
    > int returned */


    Utter nonsense. You are thinking of C++, which is another
    language. In point of fact C++ doesn't even have overloading;
    what it has is a means of faking it by adorning function names
    with something describing their parameters, and doing this behind
    your back. By the time the C++ code reaches the linking stage all
    overloading is resolved to distinct function names. This creates
    headaches for symbolic debuggers and other things since the faking
    mechanism is not standardized.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, May 1, 2004
    #4
  5. zeus

    Allan Bruce Guest

    "CBFalconer" <> wrote in message
    news:...
    > Allan Bruce wrote:
    > > "zeus" <> wrote in message
    > >
    > >> I know function overloading is not supported in C.
    > >> I have a few questions about this:
    > >> 1. Why? is it from technical reasons? if so, which?
    > >> 2. why wasn't it introduced to the ANSI?
    > >> 3. Is there any C implementation supporting this feature?
    > >>
    > >> I assume some of you will claim that there is no need in function
    > >> overloading, so I would like to know your arguments too.

    > >
    > > Function overloading is supported in C. Valid overloaded functions
    > > are those that have different arguements, and possible different
    > > return types, however an invalid overloaded set of functions is
    > > those that differ only by return type, i.e.
    > >
    > > /* Valid overlaoded functions */
    > > int DoSomething(void);
    > > int DoSomething(int);
    > > double DoSomething(double);
    > > void DoSomething(char, int, long);
    > >
    > > /* invalid */
    > > doulbe DoSomething(void); /* already have a void arg above but with
    > > int returned */

    >
    > Utter nonsense. You are thinking of C++, which is another
    > language. In point of fact C++ doesn't even have overloading;
    > what it has is a means of faking it by adorning function names
    > with something describing their parameters, and doing this behind
    > your back. By the time the C++ code reaches the linking stage all
    > overloading is resolved to distinct function names. This creates
    > headaches for symbolic debuggers and other things since the faking
    > mechanism is not standardized.
    >


    my compiler must allow it in that case - I`ve never had a problem using
    overloading before
    Allan
     
    Allan Bruce, May 1, 2004
    #5
  6. Allan Bruce <> scribbled the following:
    > "CBFalconer" <> wrote in message
    > news:...
    >> Allan Bruce wrote:
    >> > "zeus" <> wrote in message
    >> >> I know function overloading is not supported in C.
    >> >> I have a few questions about this:
    >> >> 1. Why? is it from technical reasons? if so, which?
    >> >> 2. why wasn't it introduced to the ANSI?
    >> >> 3. Is there any C implementation supporting this feature?
    >> >>
    >> >> I assume some of you will claim that there is no need in function
    >> >> overloading, so I would like to know your arguments too.
    >> >
    >> > Function overloading is supported in C. Valid overloaded functions
    >> > are those that have different arguements, and possible different
    >> > return types, however an invalid overloaded set of functions is
    >> > those that differ only by return type, i.e.
    >> >
    >> > /* Valid overlaoded functions */
    >> > int DoSomething(void);
    >> > int DoSomething(int);
    >> > double DoSomething(double);
    >> > void DoSomething(char, int, long);
    >> >
    >> > /* invalid */
    >> > doulbe DoSomething(void); /* already have a void arg above but with
    >> > int returned */

    >>
    >> Utter nonsense. You are thinking of C++, which is another
    >> language. In point of fact C++ doesn't even have overloading;
    >> what it has is a means of faking it by adorning function names
    >> with something describing their parameters, and doing this behind
    >> your back. By the time the C++ code reaches the linking stage all
    >> overloading is resolved to distinct function names. This creates
    >> headaches for symbolic debuggers and other things since the faking
    >> mechanism is not standardized.


    > my compiler must allow it in that case - I`ve never had a problem using
    > overloading before


    Then you are either compiling as C++ or with non-standard extensions.
    What is your compiler and how are you invoking it?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
    to read anyway."
    - Groucho Marx
     
    Joona I Palaste, May 1, 2004
    #6
  7. zeus

    Chris Torek Guest

    In article <>
    zeus <> writes:
    >I know function overloading is not supported in C.


    Not in general, but C99 has <tgmath.h>.

    >I have a few questions about this:
    >1. Why? is it from technical reasons? if so, which?


    See <tgmath.h>. Since C (at least C99) *does* have function
    overloading, it is impossible to say why it lacks it.

    >2. why wasn't it introduced to the ANSI?


    See <tgmath.h>.

    >3. Is there any C implementation supporting this feature?


    See <tgmath.h>. :)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, May 1, 2004
    #7
  8. "Chris Torek" <> wrote in message
    news:...
    > In article <>
    > zeus <> writes:
    > >I know function overloading is not supported in C.

    >
    > Not in general, but C99 has <tgmath.h>.
    >
    > >I have a few questions about this:
    > >1. Why? is it from technical reasons? if so, which?

    >
    > See <tgmath.h>. Since C (at least C99) *does* have function
    > overloading, it is impossible to say why it lacks it.


    <tgmath.h> uses a lot of trickery with macros to implement a very limited
    set of functions that accept variably-typed arguments. It is not
    overloading in the sense that C++ people use the term.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin
     
    Stephen Sprunk, May 1, 2004
    #8
  9. zeus

    Ben Pfaff Guest

    "Stephen Sprunk" <> writes:

    > <tgmath.h> uses a lot of trickery with macros to implement a very limited
    > set of functions that accept variably-typed arguments.


    You're probably referring to some particular implementation. The
    C standard only specifies the <tgmath.h> interfaces, not how it
    is implemented.
    --
    "In My Egotistical Opinion, most people's C programs should be indented six
    feet downward and covered with dirt." -- Blair P. Houghton
     
    Ben Pfaff, May 1, 2004
    #9
  10. "Ben Pfaff" <> wrote in message
    news:...
    > "Stephen Sprunk" <> writes:
    >
    > > <tgmath.h> uses a lot of trickery with macros to implement a very

    limited
    > > set of functions that accept variably-typed arguments.

    >
    > You're probably referring to some particular implementation. The
    > C standard only specifies the <tgmath.h> interfaces, not how it
    > is implemented.


    True, the type-generic macros could be defined as calls to overloaded
    built-in functions or such, but the point remains that this is not a general
    example of Standard C supporting function overloading. Even macro
    overloading is a stretch.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin
     
    Stephen Sprunk, May 2, 2004
    #10
  11. CBFalconer <> writes:
    [...]
    > Utter nonsense. You are thinking of C++, which is another
    > language.


    Agreed.

    > In point of fact C++ doesn't even have overloading;
    > what it has is a means of faking it by adorning function names
    > with something describing their parameters, and doing this behind
    > your back. By the time the C++ code reaches the linking stage all
    > overloading is resolved to distinct function names. This creates
    > headaches for symbolic debuggers and other things since the faking
    > mechanism is not standardized.


    <OT>
    What you're describing is the manner in which overloading is
    (typically) implemented. There's nothing more or less "fake" about
    the described implementation technique than any other, as long as the
    effect from the programmer's point of view is the same. (The behavior
    of symbol debuggers is outside the scope of the language definition.)

    I don't know (or much care) whether the common "name mangling"
    implementation is actually required by the C++ standard.
    </OT>

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, May 2, 2004
    #11
  12. zeus

    CBFalconer Guest

    Allan Bruce wrote:
    > "CBFalconer" <> wrote in message
    >> Allan Bruce wrote:
    >>> "zeus" <> wrote in message
    >>>
    >>>> I know function overloading is not supported in C.
    >>>> I have a few questions about this:
    >>>> 1. Why? is it from technical reasons? if so, which?
    >>>> 2. why wasn't it introduced to the ANSI?
    >>>> 3. Is there any C implementation supporting this feature?
    >>>>
    >>>> I assume some of you will claim that there is no need in function
    >>>> overloading, so I would like to know your arguments too.
    >>>
    >>> Function overloading is supported in C. Valid overloaded
    >>> functions are those that have different arguements, and possible
    >>> different return types, however an invalid overloaded set of
    >>> functions is those that differ only by return type, i.e.
    >>>
    >>> /* Valid overlaoded functions */
    >>> int DoSomething(void);
    >>> int DoSomething(int);
    >>> double DoSomething(double);
    >>> void DoSomething(char, int, long);
    >>>
    >>> /* invalid */
    >>> doulbe DoSomething(void); /* already have a void arg above but
    >>> with int returned */

    >>
    >> Utter nonsense. You are thinking of C++, which is another
    >> language. In point of fact C++ doesn't even have overloading;
    >> what it has is a means of faking it by adorning function names
    >> with something describing their parameters, and doing this behind
    >> your back. By the time the C++ code reaches the linking stage
    >> all overloading is resolved to distinct function names. This
    >> creates headaches for symbolic debuggers and other things since
    >> the faking mechanism is not standardized.
    >>

    >
    > my compiler must allow it in that case - I`ve never had a problem
    > using overloading before


    Then you are not using a C compiler. However, as Chris Torek
    pointed out elsethread, my statement is not strictly true, in that
    C99 provides effectively overloaded macros in <tgmath.h>. These
    are macros, not functions.

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    CBFalconer, May 2, 2004
    #12
  13. zeus

    Lew Pitcher Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Speaking for myself, and not having read any of the other responses, here's my
    answers to your questions.

    zeus wrote:
    | I know function overloading is not supported in C.
    | I have a few questions about this:
    | 1. Why?
    Why do you think that function overloading /should/ be supported in C?
    My guess that function overloading is not supported in C for the same reasons
    that they don't support roof racks for 747s; it's an unnecessary addition that
    can have destructive impacts.

    | is it from technical reasons? if so, which?
    Probably, no technical reason other than "function overloading isn't seen to be
    necessary in order to write C programs".

    | 2. why wasn't it introduced to the ANSI?
    See above.


    | 3. Is there any C implementation supporting this feature?
    If there are, then their conformance is "implementation defined".


    | I assume some of you will claim that there is no need in function
    | overloading, so I would like to know your arguments too.

    Function overloading is unnecessary from the program pov, and can be overly
    confusing from the developers pov. It is unnecessary.

    - --
    Lew Pitcher

    Master Codewright & JOAT-in-training | GPG public key available on request
    Registered Linux User #112576 (http://counter.li.org/)
    Slackware - Because I know what I'm doing.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFAlEhqagVFX4UWr64RApHmAKD1ZpfWJBooQbpeq6tkuNJhaJYkzgCgrB9N
    3FZ9dlkfXMDCjKpxgATN9/w=
    =t1oI
    -----END PGP SIGNATURE-----
     
    Lew Pitcher, May 2, 2004
    #13
  14. zeus

    Chris Torek Guest

    >"Stephen Sprunk" <> writes:
    >> <tgmath.h> uses a lot of trickery with macros to implement a very limited
    >> set of functions that accept variably-typed arguments.


    In article <news:>
    Ben Pfaff <> writes:
    >You're probably referring to some particular implementation. The
    >C standard only specifies the <tgmath.h> interfaces, not how it
    >is implemented.


    The C99 draft I use *does* say that the <tgmath.h> names (sin,
    acos, etc.) are macros. As such, one could presumably #include
    the header, then #undef them (or some of them) to un-do the
    effect of including <tgmath.h>.

    The principle, however, is still there: if <tgmath.h> can
    overload a name like "sin", so that it actually calls sinf()
    or sinl() if the provided parameter is a float or long double
    -- or even fancier, call csin() when invoked on a complex
    value -- then C99 does provide function overloading, however
    limited.

    It seems particularly odd (and typically committee-ish) to provide
    a limited subset of some facility, rather than pursuing the idea
    to its end, whittling it down to the useful nub, and providing
    *that* instead. In other words, if the endpoint of the idea is to
    allow a single "external name" of a function (or function-like
    macro) to map to multiple "internal names" based on the parameter
    types, it would make more sense to provide a method by which anyone
    -- not just the implementor -- can do this. Only if there is
    something inherently implementation-specific about it is there
    sufficient justification for granting this ability only to the
    implementor. That, however, is a topic for comp.std.c, not comp.lang.c.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, May 2, 2004
    #14
  15. zeus

    Richard Bos Guest

    Chris Torek <> wrote:

    > The principle, however, is still there: if <tgmath.h> can
    > overload a name like "sin", so that it actually calls sinf()
    > or sinl() if the provided parameter is a float or long double
    > -- or even fancier, call csin() when invoked on a complex
    > value -- then C99 does provide function overloading, however
    > limited.


    Quibble: I would say that it provides some overloaded functions (ok,
    some overloaded macros). What it does not provide is function
    overloading - that is, it does not provide a standard mechanism for
    overloading functions.

    Richard
     
    Richard Bos, May 3, 2004
    #15
  16. zeus

    Dan Pop Guest

    In <> Chris Torek <> writes:

    >It seems particularly odd (and typically committee-ish) to provide
    >a limited subset of some facility, rather than pursuing the idea
    >to its end, whittling it down to the useful nub, and providing
    >*that* instead.


    It's obvious that <tgmath.h> was motivated by the desire to bring C
    closer to Fortran for number crunching purposes (Fortran supported this
    feature for ages). A large amount of the C99 additions serve this
    purpose.

    And I wouldn't call it function overloading, it's merely a well documented
    source code transformation performed by the C99 preprocessor. Trivial to
    implement using GNU C's typeof operator and block expressions, if we drop
    the complex support:

    #define sin(x) ({typeof(x) res = 0; \
    switch (sizeof(typeof(x))) { \
    case sizeof(long double): res = sinl(x); break; \
    case sizeof(double): res = sin(x); break; \
    case sizeof(float): res = sinf(x); break; \
    } \
    res;})

    Does this mean that GNU C supports function overloading?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, May 11, 2004
    #16
  17. On 2004-05-11, Dan Pop <> wrote:

    > And I wouldn't call it function overloading, it's merely a well documented
    > source code transformation performed by the C99 preprocessor. Trivial to
    > implement using GNU C's typeof operator and block expressions, if we drop
    > the complex support:


    > #define sin(x) ({typeof(x) res = 0; \
    > switch (sizeof(typeof(x))) { \
    > case sizeof(long double): res = sinl(x); break; \
    > case sizeof(double): res = sin(x); break; \
    > case sizeof(float): res = sinf(x); break; \
    > } \
    > res;})


    This implementation doesn't handle integer arguments.

    --
    Stefan Farfeleder
     
    Stefan Farfeleder, May 11, 2004
    #17
  18. zeus

    Dan Pop Guest

    In <40a0f08a$0$33210$> Stefan Farfeleder <> writes:

    >On 2004-05-11, Dan Pop <> wrote:
    >
    >> And I wouldn't call it function overloading, it's merely a well documented
    >> source code transformation performed by the C99 preprocessor. Trivial to
    >> implement using GNU C's typeof operator and block expressions, if we drop
    >> the complex support:

    >
    >> #define sin(x) ({typeof(x) res = 0; \
    >> switch (sizeof(typeof(x))) { \
    >> case sizeof(long double): res = sinl(x); break; \
    >> case sizeof(double): res = sin(x); break; \
    >> case sizeof(float): res = sinf(x); break; \
    >> } \
    >> res;})

    >
    >This implementation doesn't handle integer arguments.


    It doesn't handle complex arguments, either, but it makes the point it
    was supposed to make: doing tricks with macros doesn't really count as
    function overloading.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, May 11, 2004
    #18
  19. zeus

    Chris Torek Guest

    >In <> Chris Torek <> writes:
    >>It seems particularly odd (and typically committee-ish) to provide
    >>a limited subset of some facility, rather than pursuing the idea
    >>to its end, whittling it down to the useful nub, and providing
    >>*that* instead.


    In article <news:c7qn2s$jrj$> Dan Pop <>
    replies:
    >It's obvious that <tgmath.h> was motivated by the desire to bring C
    >closer to Fortran for number crunching purposes (Fortran supported this
    >feature for ages). A large amount of the C99 additions serve this
    >purpose.


    Indeed, this seems to be the not-very-well-hidden agenda behind
    the <tgmath.h> monstrosities. My point with the aside was not so
    much "these are bad" (although they are) but rather "these are an
    ugly solution to a political problem, namely, pleasing some
    sub-group."

    >And I wouldn't call it function overloading, it's merely a well documented
    >source code transformation performed by the C99 preprocessor. Trivial to
    >implement using GNU C's typeof operator and block expressions, if we drop
    >the complex [and integer] support:
    >
    > #define sin(x) ({typeof(x) res = 0; \
    > switch (sizeof(typeof(x))) { \
    > case sizeof(long double): res = sinl(x); break; \
    > case sizeof(double): res = sin(x); break; \
    > case sizeof(float): res = sinf(x); break; \
    > } \
    > res;})
    >
    >Does this mean that GNU C supports function overloading?


    GNU C does indeed support "overloading" via macros, in a generalized
    form that handles the specifics required for the ugly C99 version.
    (The actual macro needs to use __builtin_classify_type so that it
    can handle integers and complex arguments.)

    Perhaps a better way to phrase it is this. Aside from the exposure
    as a macro (which I grant is a very large "aside"), the sequence:

    #include <tgmath.h>

    float a; long double b; double complex c; int d;
    ...
    a = sin(arg); b = sin(arg); c = sin(arg); d = sin(arg);

    *looks* (syntactically) like an overloaded function, and *acts*
    (semantically) like an overloaded function -- so what should we
    call it? Overloaded functions are already just syntactic sugar.
    C99's bizarre macros are perhaps more "syntactic cyclamates"[%],
    and calling them "overloaded functions" might be a bit overreaching
    -- they are really "overloaded macros" -- but their underlying idea
    is the same.

    [% see <http://www.foodcomm.org.uk/press_97_cyclams.htm> :) (the
    studies are not conclusive, but still...)]
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, May 11, 2004
    #19
  20. zeus

    Guillaume Guest

    >>> #define sin(x) ({typeof(x) res = 0; \
    >>> switch (sizeof(typeof(x))) { \
    >>> case sizeof(long double): res = sinl(x); break; \
    >>> case sizeof(double): res = sin(x); break; \
    >>> case sizeof(float): res = sinf(x); break; \
    >>> } \
    >>> res;})

    >>
    >>This implementation doesn't handle integer arguments.

    >
    > It doesn't handle complex arguments, either, but it makes the point it
    > was supposed to make: doing tricks with macros doesn't really count as
    > function overloading.


    Indeed, but something worse is intriguing: the macro expands to an
    instruction block. I don't see how a block (some instructions surrounded
    by braces { }) can be an R-value? Seems to be a GCC trick, but
    apparently forbidden by the standard (or did I miss anything here?).

    I tried, and it works with GCC, but we still get a warning:
    "warning: ISO C forbids braced-groups within expressions".

    Anyway. Does it qualify as a form of function overloading? Not quite.
    It's not the fact that it's a macro trick (and not even a standard one,
    to begin with), but there is worse. The type of x is only checked
    against its "size", which of course may lead to all kinds of errors.

    If "long double" has the same size as "double", it won't compile.
    And checking a type based only on size criteria is certainly not
    sufficient to qualify the whole thing as proper function overloading.
    (Not to mention that a macro isn't quite like a function and
    nasty side-effects can occur if the argument is itself an expression
    that may have side-effects.)
     
    Guillaume, May 11, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Iyer, Prasad C

    Overloading __init__ & Function overloading

    Iyer, Prasad C, Sep 30, 2005, in forum: Python
    Replies:
    3
    Views:
    6,413
    Fredrik Lundh
    Sep 30, 2005
  2. Fredrik Lundh
    Replies:
    0
    Views:
    451
    Fredrik Lundh
    Sep 30, 2005
  3. Steve Holden
    Replies:
    0
    Views:
    431
    Steve Holden
    Sep 30, 2005
  4. Iyer, Prasad C
    Replies:
    4
    Views:
    580
    John J. Lee
    Sep 30, 2005
  5. Fredrik Lundh
    Replies:
    0
    Views:
    402
    Fredrik Lundh
    Sep 30, 2005
Loading...

Share This Page