inline vs macro

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Dec 19, 2006.

  1. Guest

    hi guys,

    Can you please suggest that in what cases should a macro be
    preferred over inline function and viceversa ? Is there any case where
    using a macro will be more efficient as compared to inline function ?

    thanks for any help in advance ...
     
    , Dec 19, 2006
    #1
    1. Advertising

  2. Guest

    wrote:
    > hi guys,
    >
    > Can you please suggest that in what cases should a macro be
    > preferred over inline function and viceversa ? Is there any case where
    > using a macro will be more efficient as compared to inline function ?
    >
    > thanks for any help in advance ...


    You could refer to the following link,

    http://groups.google.co.in/group/comp.lang.c /browse_thread/thread/2817c5a40313a697/?hl=en#

    And inline functions are much better than Macro, which you will
    understand if you look at the examples in the above thread.
     
    , Dec 19, 2006
    #2
    1. Advertising

  3. jacob navia Guest

    a écrit :
    > hi guys,
    >
    > Can you please suggest that in what cases should a macro be
    > preferred over inline function and viceversa ? Is there any case where
    > using a macro will be more efficient as compared to inline function ?
    >
    > thanks for any help in advance ...
    >


    #define max(a,b) ((a<b)?b:a)

    Defining an inline function(s) for that would be
    quite difficult...

    The same for min(a,b)

    Other "advantages" of macros is that they can capture
    local variables in the calling function:

    #define myhack(a) (a+sqrt(var))

    void fn(double var)
    {
    int a;

    ...
    myhack(a);
    ...
    }

    You see? The argument var is implicitely passed
    to the macro.

    On the other hand:

    An advantage of inline functions is that they
    do not capture local variables in the calling
    function:

    inline double myhack(int a)
    {
    return a+sqrt(var);
    // This "var" refers to a global variable var,
    // NOT to a local variable. This avoids
    // UNINTENTIONAL problems with local
    // variables
    }
     
    jacob navia, Dec 19, 2006
    #3
  4. <> wrote in message
    news:...
    > Can you please suggest that in what cases should a macro be
    > preferred over inline function and viceversa ?


    An inline function has type safety and doesn't suffer from
    double-evaluation problems.

    A macro has type generic-ness and can modify its arguments.

    Only one of them may meet your needs in particular cases, though in the
    simplest examples they may both work equally well.

    > Is there any case where using a macro will be more efficient as
    > compared to inline function ?


    If you can replace one with the other and preserve the caller's syntax,
    there is no reason to expect one to be more efficient than the other. A
    compiler should treat them the same.

    Sometimes you can't replace a macro, though. Consider:

    #define INC(x) (x++)

    A function simply can't do the same thing. You'd have to change callers
    from this:

    int x=0;
    INC(x);

    to:

    int x=0;
    x = inc(x); /* assumes int inc(x) { return x+1; } */

    You might also be calling the macro with varying type arguments; there
    is no way to write an inline function to replace INC() above that can
    handle both doubles and ints correctly.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Stephen Sprunk, Dec 19, 2006
    #4
  5. <> wrote in message
    news:...
    > hi guys,
    >
    > Can you please suggest that in what cases should a macro be
    > preferred over inline function and viceversa ? Is there any case where
    > using a macro will be more efficient as compared to inline function ?
    >
    > thanks for any help in advance ...
    >


    #define MAXOF(x,y) ((x)>(y)?(x):(y))

    This macro can be used for short, int, long, float, double, or any
    combination of them. To use a function would require
    defining many separate functions.


    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Software Reuse Project
     
    Fred Kleinschmidt, Dec 19, 2006
    #5
  6. said:

    <snip>

    > And inline functions are much better than Macro


    Why do you think so? And what do you mean by "better"?

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Dec 19, 2006
    #6
  7. Chris Torek Guest

    In article <>
    <> wrote:
    > Can you please suggest that in what cases should a macro be
    >preferred over inline function and viceversa?


    The advantage of a macro is that it simply performs textual
    substitution.

    The disadvantage of a macro is that it simply performs textual
    substitution.

    Besides the other examples posted so far, macros also have access
    to the preprocessor's "#" and "##" operators:

    #define DEBUG_INTEGER(var) fprintf(stderr, "DEBUG: " #var " = %d\n", var)
    #define DEBUG_STRING(var) fprintf(stderr, "DEBUG: " #var " = %s\n", var)
    void foo(void) {
    int zorg, blaggle;
    char *graump;
    ...
    DEBUG_INTEGER(zorg);
    DEBUG_INTEGER(blaggle);
    DEBUG_STRING(graump);
    ...
    }
    --
    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, Dec 19, 2006
    #7
  8. jacob navia <> writes:
    > a écrit :
    >> hi guys,
    >> Can you please suggest that in what cases should a macro be
    >> preferred over inline function and viceversa ? Is there any case where
    >> using a macro will be more efficient as compared to inline function ?
    >> thanks for any help in advance ...
    >>

    >
    > #define max(a,b) ((a<b)?b:a)
    >
    > Defining an inline function(s) for that would be
    > quite difficult...

    [...]

    Surely you mean:

    #define MAX(a, b) (((a) < (b)) ? (b) : (a))

    (with an added comment warning that one of the arguments will be
    evaluated twice).

    One disadvantage of inline functions is that some compilers may not
    support them, or may not support them correctly. Yes, they're defined
    in C99, the One True Standard for the C programming language, but C99
    is not universally implemented.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 19, 2006
    #8
  9. Guest

    Richard Heathfield wrote:
    > said:
    >
    > <snip>
    >
    > > And inline functions are much better than Macro

    >
    > Why do you think so? And what do you mean by "better"?


    Superior in every way that I can imagine.
    Lack of side effects due to multiple evaluation
    Type safety
    Less prone to undefined behavior

    A function macro offers something for the lazy programmer:
    A poor man's C++ template in C ... Make that a destitute man's C++
    somewhat template like thingy in C. Except that they are universally
    broken.

    But the ability to apply that macro to any argument is one of its
    largest downfalls.

    In short, function macros are the result of hazardous laziness. There
    is not one single instance where the correct functions would not be
    superior. If your compiler does not support inline functions, it is
    time to get a new compiler. If no compiler is available for your
    toaster IC, then just write the code inline instead of using macros.
    Because hey, who likes burnt toast in the morning.

    If I had my way, min(a,b) and max(a,b) would be removed from the
    standard library headers. They are not as bad as gets(), but still
    completely awful.

    > --
    > Richard Heathfield
    > "Usenet is a strange place" - dmr 29/7/1999
    > http://www.cpax.org.uk
    > email: rjh at the above domain, - www.
     
    , Dec 20, 2006
    #9
  10. said:

    >
    > Richard Heathfield wrote:
    >> said:
    >>
    >> <snip>
    >>
    >> > And inline functions are much better than Macro

    >>
    >> Why do you think so? And what do you mean by "better"?

    >
    > Superior in every way that I can imagine.
    > Lack of side effects due to multiple evaluation


    That can be a good thing or a bad thing, depending on whether you want the
    side effects.

    > Type safety


    That can be a good thing or a bad thing, depending on whether you want the
    type safety.

    > Less prone to undefined behavior


    Perhaps. But if you stop people doing stupid things, it's generally at the
    expense of stopping them doing clever things, too. Doug Gwyn once said
    something of the kind.

    <snip>

    > If your compiler does not support inline functions, it is
    > time to get a new compiler.


    It's not for us to tell people what compilers to use.

    > If I had my way, min(a,b) and max(a,b) would be removed from the
    > standard library headers.


    [F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
    granted. Not only have I removed min and max from the standard library
    headers for you, but I have applied this change retroactively, so that it
    shall be as if they had *never* been part of the standard library headers.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Dec 20, 2006
    #10
  11. CBFalconer Guest

    wrote:
    >

    .... snip ...
    >
    > If I had my way, min(a,b) and max(a,b) would be removed from the
    > standard library headers. They are not as bad as gets(), but
    > still completely awful.


    AFAICS they are (not present). They only show up as examples of
    defines.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Dec 20, 2006
    #11
  12. Guest

    Richard Heathfield wrote:
    > said:
    >
    > >
    > > Richard Heathfield wrote:
    > >> said:
    > >>
    > >> <snip>
    > >>
    > >> > And inline functions are much better than Macro
    > >>
    > >> Why do you think so? And what do you mean by "better"?

    > >
    > > Superior in every way that I can imagine.
    > > Lack of side effects due to multiple evaluation

    >
    > That can be a good thing or a bad thing, depending on whether you want the
    > side effects.


    #define MAX(a,b) ((a) > (b) ? (a) : (b))

    unsigned foo = 1;
    unsigned bar = 2;

    unsigned biggest = MAX(++foo, ++bar);

    It does not matter if they want the side effects or not. The side
    effects cause a defect due to the nature of macros that prevents them
    from being used safely.

    > > Type safety

    >
    > That can be a good thing or a bad thing, depending on whether you want the
    > type safety.


    Have you ever heard of the Arianne failure? Type safety.

    > > Less prone to undefined behavior

    >
    > Perhaps. But if you stop people doing stupid things, it's generally at the
    > expense of stopping them doing clever things, too. Doug Gwyn once said
    > something of the kind.


    I would stop them from using gets().
    I would remove function macros from the language.
    Neither feature has any merit, considering that alternatives exist
    which are superior in every way.

    > <snip>
    >
    > > If your compiler does not support inline functions, it is
    > > time to get a new compiler.

    >
    > It's not for us to tell people what compilers to use.


    It's not an order. It's advice.

    > > If I had my way, min(a,b) and max(a,b) would be removed from the
    > > standard library headers.

    >
    > [F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
    > granted. Not only have I removed min and max from the standard library
    > headers for you, but I have applied this change retroactively, so that it
    > shall be as if they had *never* been part of the standard library headers.


    Right, that's C++ with the header defect. Lots of C compilers mimic
    it, though.

    > --
    > Richard Heathfield
    > "Usenet is a strange place" - dmr 29/7/1999
    > http://www.cpax.org.uk
    > email: rjh at the above domain, - www.
     
    , Dec 20, 2006
    #12
  13. jaysome Guest

    On Wed, 20 Dec 2006 07:13:29 +0000, Richard Heathfield
    <> wrote:

    > said:
    >
    >>
    >> Richard Heathfield wrote:
    >>> said:
    >>>
    >>> <snip>
    >>>
    >>> > And inline functions are much better than Macro
    >>>
    >>> Why do you think so? And what do you mean by "better"?

    >>
    >> Superior in every way that I can imagine.
    >> Lack of side effects due to multiple evaluation

    >
    >That can be a good thing or a bad thing, depending on whether you want the
    >side effects.


    Why would you ever want side effects?

    >> Type safety

    >
    >That can be a good thing or a bad thing, depending on whether you want the
    >type safety.


    Why would you ever NOT want type safety?

    >> Less prone to undefined behavior

    >
    >Perhaps. But if you stop people doing stupid things, it's generally at the
    >expense of stopping them doing clever things, too. Doug Gwyn once said
    >something of the kind.


    Possibly.

    ><snip>
    >
    >> If your compiler does not support inline functions, it is
    >> time to get a new compiler.

    >
    >It's not for us to tell people what compilers to use.
    >
    >> If I had my way, min(a,b) and max(a,b) would be removed from the
    >> standard library headers.

    >
    >[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
    >granted. Not only have I removed min and max from the standard library
    >headers for you, but I have applied this change retroactively, so that it
    >shall be as if they had *never* been part of the standard library headers.


    I just looked, and neither of my two hard-copies of the Schildt book
    nor my PDF version of the standard mention anything about macros named
    "min" or "max" now. I'm sure no one other than me has touched the
    books in the past few days; and the modification date of the PDF file
    didn't even change. How could that be?

    Happy Holidays
    --
    jay
     
    jaysome, Dec 20, 2006
    #13
  14. said:

    >
    > Richard Heathfield wrote:
    >> said:
    >>
    >> >
    >> > Richard Heathfield wrote:
    >> >> said:
    >> >>
    >> >> <snip>
    >> >>
    >> >> > And inline functions are much better than Macro
    >> >>
    >> >> Why do you think so? And what do you mean by "better"?
    >> >
    >> > Superior in every way that I can imagine.
    >> > Lack of side effects due to multiple evaluation

    >>
    >> That can be a good thing or a bad thing, depending on whether you want
    >> the side effects.

    >
    > #define MAX(a,b) ((a) > (b) ? (a) : (b))
    >
    > unsigned foo = 1;
    > unsigned bar = 2;
    >
    > unsigned biggest = MAX(++foo, ++bar);
    >
    > It does not matter if they want the side effects or not. The side
    > effects cause a defect due to the nature of macros that prevents them
    > from being used safely.


    So you're saying macros can't be used safely because you can pass them
    stupid arguments? Well, by the same token, functions that take parameters
    can't be used safely because it is possible to pass stupid arguments to
    them.

    >> > Type safety

    >>
    >> That can be a good thing or a bad thing, depending on whether you want
    >> the type safety.

    >
    > Have you ever heard of the Arianne failure? Type safety.


    Have you ever heard of the Therac-25 failure? One of the principal causes of
    this failure was software re-use. So let's stop re-using software. Or
    perhaps we can stop making sweeping generalisations instead.

    >> > Less prone to undefined behavior

    >>
    >> Perhaps. But if you stop people doing stupid things, it's generally at
    >> the expense of stopping them doing clever things, too. Doug Gwyn once
    >> said something of the kind.

    >
    > I would stop them from using gets().


    Sure. It has no safe use.

    > I would remove function macros from the language.


    But these *do* have a safe use.

    <snip>

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Dec 20, 2006
    #14
  15. Ian Collins Guest

    wrote:
    >
    > I would stop them from using gets().
    > I would remove function macros from the language.
    > Neither feature has any merit, considering that alternatives exist
    > which are superior in every way.
    >

    Function macros have one - access to __FILE__ and __LINE__ and ## for
    error logging.

    --
    Ian Collins.
     
    Ian Collins, Dec 20, 2006
    #15
  16. jaysome said:
    > Richard Heathfield wrote:
    >> said:
    >>> Richard Heathfield wrote:
    >>>> said:
    >>>> <snip>
    >>>>
    >>>> > And inline functions are much better than Macro
    >>>>
    >>>> Why do you think so? And what do you mean by "better"?
    >>>
    >>> Superior in every way that I can imagine.
    >>> Lack of side effects due to multiple evaluation

    >>
    >>That can be a good thing or a bad thing, depending on whether you want the
    >>side effects.

    >
    > Why would you ever want side effects?


    Here's an example of a side effect that you want:

    int n = printf("Hello, world.\n");
    This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
    the standard output device. Side effects can be quite handy.

    >
    >>> Type safety

    >>
    >>That can be a good thing or a bad thing, depending on whether you want the
    >>type safety.

    >
    > Why would you ever NOT want type safety?


    Sometimes it gets in the way. That's why void * exists.

    <snip>
    >>
    >>> If I had my way, min(a,b) and max(a,b) would be removed from the
    >>> standard library headers.

    >>
    >>[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish
    >>[is
    >>granted. Not only have I removed min and max from the standard library
    >>headers for you, but I have applied this change retroactively, so that it
    >>shall be as if they had *never* been part of the standard library headers.

    >
    > I just looked, and neither of my two hard-copies of the Schildt book
    > nor my PDF version of the standard mention anything about macros named
    > "min" or "max" now. I'm sure no one other than me has touched the
    > books in the past few days; and the modification date of the PDF file
    > didn't even change.


    See? It worked!

    > How could that be?


    Magic!

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Dec 20, 2006
    #16
  17. Guest

    wrote:
    > hi guys,
    >
    > Can you please suggest that in what cases should a macro be
    > preferred over inline function and viceversa ? Is there any case where
    > using a macro will be more efficient as compared to inline function ?
    >
    > thanks for any help in advance ...


    #include <stdio.h>
    #include <stdlib.h>
    #include <limits.h>
    #include <float.h>

    #define MAX(a,b) ((a) > (b) ? (a) : (b))

    int main(void)
    {
    size_t a,
    b,
    c;
    char *s0,
    *s1,
    *s2;
    long long d = LLONG_MAX;
    float g = FLT_MAX;
    a = 1;
    b = 2;
    c = MAX(++b, ++a);
    s0 = "My name is Skinner The Grinner.";
    s1 = "I am a foo bird but I can't fly";
    s2 = MAX(s1, s0);
    a = MAX(d, g);
    printf("here are my MAX things:c=%u,s2=%s,a=%.0f\n", (unsigned)c,
    s2, (double) a);
    return 0;
    }
     
    , Dec 20, 2006
    #17
  18. CBFalconer Guest

    wrote:
    > Richard Heathfield wrote:
    >> said:
    >>

    .... snip ...
    >>
    >>> If I had my way, min(a,b) and max(a,b) would be removed from the
    >>> standard library headers.

    >>
    >> [F/X: waves magic wand] Since it is the season of gifts, Dann,
    >> your wish is granted. Not only have I removed min and max from
    >> the standard library headers for you, but I have applied this
    >> change retroactively, so that it shall be as if they had *never*
    >> been part of the standard library headers.

    >
    > Right, that's C++ with the header defect. Lots of C compilers
    > mimic it, though.


    No, that's the C standard. Any ISO C standard, new or old. Just
    thank Richard for satisfying your every wish. Ain't alternate
    universes grand.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Dec 20, 2006
    #18
  19. Guest

    Richard Heathfield wrote:
    > said:
    >
    > >
    > > Richard Heathfield wrote:
    > >> said:
    > >>
    > >> >
    > >> > Richard Heathfield wrote:
    > >> >> said:
    > >> >>
    > >> >> <snip>
    > >> >>
    > >> >> > And inline functions are much better than Macro
    > >> >>
    > >> >> Why do you think so? And what do you mean by "better"?
    > >> >
    > >> > Superior in every way that I can imagine.
    > >> > Lack of side effects due to multiple evaluation
    > >>
    > >> That can be a good thing or a bad thing, depending on whether you want
    > >> the side effects.

    > >
    > > #define MAX(a,b) ((a) > (b) ? (a) : (b))
    > >
    > > unsigned foo = 1;
    > > unsigned bar = 2;
    > >
    > > unsigned biggest = MAX(++foo, ++bar);
    > >
    > > It does not matter if they want the side effects or not. The side
    > > effects cause a defect due to the nature of macros that prevents them
    > > from being used safely.

    >
    > So you're saying macros can't be used safely because you can pass them
    > stupid arguments? Well, by the same token, functions that take parameters
    > can't be used safely because it is possible to pass stupid arguments to
    > them.


    No. I am saying that you do not know if MAX(a,b) is a macro or a
    function unless you examine the implementation.

    MAX(++a,++b) is prefectly fine if it is a function and we do not know
    if it is OK if it is a macro.

    The arguments are stupid if it is a macro and not stupid if it is a
    function. But you cannot tell which is which unless you see the actual
    definition. In a ten million line C project, will you know for sure
    which things are macros and which things are functions?
    By their very nature, function macros are defective and cause defects.

    > >> > Type safety
    > >>
    > >> That can be a good thing or a bad thing, depending on whether you want
    > >> the type safety.

    > >
    > > Have you ever heard of the Arianne failure? Type safety.

    >
    > Have you ever heard of the Therac-25 failure? One of the principal causes of
    > this failure was software re-use. So let's stop re-using software. Or
    > perhaps we can stop making sweeping generalisations instead.


    Reusing bad software is worse than not reusing it.

    > >> > Less prone to undefined behavior
    > >>
    > >> Perhaps. But if you stop people doing stupid things, it's generally at
    > >> the expense of stopping them doing clever things, too. Doug Gwyn once
    > >> said something of the kind.

    > >
    > > I would stop them from using gets().

    >
    > Sure. It has no safe use.


    Wrong. It is used safely when you never input more bytes than the size
    of the object.
    In a similar way, function macros are fatally flawed. They can be used
    safely, but normal use is not safe.

    > > I would remove function macros from the language.

    >
    > But these *do* have a safe use.


    Just like gets() -- only with extreme care.

    > <snip>
    >
    > --
    > Richard Heathfield
    > "Usenet is a strange place" - dmr 29/7/1999
    > http://www.cpax.org.uk
    > email: rjh at the above domain, - www.
     
    , Dec 20, 2006
    #19
  20. jaysome Guest

    On Wed, 20 Dec 2006 08:09:07 +0000, Richard Heathfield
    <> wrote:

    >jaysome said:
    >> Richard Heathfield wrote:
    >>> said:
    >>>> Richard Heathfield wrote:
    >>>>> said:
    >>>>> <snip>
    >>>>>
    >>>>> > And inline functions are much better than Macro
    >>>>>
    >>>>> Why do you think so? And what do you mean by "better"?
    >>>>
    >>>> Superior in every way that I can imagine.
    >>>> Lack of side effects due to multiple evaluation
    >>>
    >>>That can be a good thing or a bad thing, depending on whether you want the
    >>>side effects.

    >>
    >> Why would you ever want side effects?

    >
    >Here's an example of a side effect that you want:
    >
    >int n = printf("Hello, world.\n");
    >This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
    >the standard output device. Side effects can be quite handy.


    Of course.

    What I meant was: "Why would you ever want side effects in macros?".

    Your example could easily be extended, to help answer that question.

    #define SQUARED(x) (int)((x)*(x))
    int k = SQUARED(printf("Hello, world.\n"));

    But, what I suspect that Dann meant, was: "Lack of *undesired* side
    effects due to multiple evaluation"; something like this:

    #define ABS(x) ((x) < 0 ? -(x) : (x))
    ... ABS( n++ )

    >>>> Type safety
    >>>
    >>>That can be a good thing or a bad thing, depending on whether you want the
    >>>type safety.

    >>
    >> Why would you ever NOT want type safety?

    >
    >Sometimes it gets in the way. That's why void * exists.


    But the standard uses void * safely, doesn't it? Look at malloc()'s
    prototype in <stdlib.h>.

    Of course, if you use malloc(), then you better:

    1. Include the header file <stdlib.h>.
    2. Not cast its return value.
    3. Check for a return value of NULL.

    Barring any undefined behavior, use of void * seems type safe to me.

    --
    jay
     
    jaysome, Dec 20, 2006
    #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. Abhi
    Replies:
    2
    Views:
    757
    E. Robert Tisdale
    Jul 3, 2003
  2. Alvin
    Replies:
    7
    Views:
    495
    E. Robert Tisdale
    May 6, 2005
  3. Replies:
    3
    Views:
    480
  4. Daniel Vallstrom
    Replies:
    2
    Views:
    2,003
    Kevin Bracey
    Nov 21, 2003
  5. Nish
    Replies:
    4
    Views:
    524
    Thomas Stegen
    Oct 8, 2004
Loading...

Share This Page