Why are member functions allowed to access private data members of aclass?

Discussion in 'C++' started by Dwight Army of Champions, Jun 27, 2010.

  1. I know that no outside functions can directly acces private data
    members of a class, and that all interface should be done through the
    get and set accessor/mutator functions, but my question is: What are
    class member functions allowed to access their own private data
    members? Because of these, data members can be manipulated and changed
    without use of the accessors and mutators, and couldn't such behavior
    wreak havoc on programs? Why not force the class member functions to
    also only use accessors and mutators? That way, if there was a
    problem, then the programmer KNOWS that the issue is with the get and
    set functions and not anywhere else.
     
    Dwight Army of Champions, Jun 27, 2010
    #1
    1. Advertising

  2. Re: Why are member functions allowed to access private data membersof a class?

    Yes I know they are, and they should be the only member functions that
    can access the pivate data members. There should be some special
    designation that identifies them as not just member functions but also
    special member functions.

    On Jun 27, 4:23 pm, "Leigh Johnston" <> wrote:
    > "Dwight Army of Champions" <> wrote in
    > messagenews:..com...
    >
    > > I know that no outside functions can directly acces private data
    > > members of a class, and that all interface should be done through the
    > > get and set accessor/mutator functions, but my question is: What are
    > > class member functions allowed to access their own private data
    > > members? Because of these, data members can be manipulated and changed
    > > without use of the accessors and mutators, and couldn't such behavior
    > > wreak havoc on programs? Why not force the class member functions to
    > > also only use accessors and mutators? That way, if there was a
    > > problem, then the programmer KNOWS that the issue is with the get and
    > > set functions and not anywhere else.

    >
    > That makes no sense: accessors and mutators are also class member functions.
    >
    > /Leigh
     
    Dwight Army of Champions, Jun 27, 2010
    #2
    1. Advertising

  3. Re: Why are member functions allowed to access private data membersof a class?

    I mean, as it is now you have a set_value() function that sets the
    value of one of your data members. But there could potentially be
    another member function out there of the same class that also sets
    this value (by using the this pointer and the assignment operator).
    Shouldn't this be disallowed?

    On Jun 27, 4:29 pm, Dwight Army of Champions
    <> wrote:
    > Yes I know they are, and they should be the only member functions that
    > can access the pivate data members. There should be some special
    > designation that identifies them as not just member functions but also
    > special member functions.
    >
    > On Jun 27, 4:23 pm, "Leigh Johnston" <> wrote:
    >
    >
    >
    > > "Dwight Army of Champions" <> wrote in
    > > messagenews:...

    >
    > > > I know that no outside functions can directly acces private data
    > > > members of a class, and that all interface should be done through the
    > > > get and set accessor/mutator functions, but my question is: What are
    > > > class member functions allowed to access their own private data
    > > > members? Because of these, data members can be manipulated and changed
    > > > without use of the accessors and mutators, and couldn't such behavior
    > > > wreak havoc on programs? Why not force the class member functions to
    > > > also only use accessors and mutators? That way, if there was a
    > > > problem, then the programmer KNOWS that the issue is with the get and
    > > > set functions and not anywhere else.

    >
    > > That makes no sense: accessors and mutators are also class member functions.

    >
    > > /Leigh- Hide quoted text -

    >
    > - Show quoted text -
     
    Dwight Army of Champions, Jun 27, 2010
    #3
  4. Dwight Army of Champions

    Ian Collins Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On 06/28/10 08:29 AM, Dwight Army of Champions wrote:

    [please don't top-post]

    > On Jun 27, 4:23 pm, "Leigh Johnston"<> wrote:
    >> "Dwight Army of Champions"<> wrote in
    >> messagenews:...
    >>
    >>> I know that no outside functions can directly acces private data
    >>> members of a class, and that all interface should be done through the
    >>> get and set accessor/mutator functions, but my question is: What are
    >>> class member functions allowed to access their own private data
    >>> members? Because of these, data members can be manipulated and changed
    >>> without use of the accessors and mutators, and couldn't such behavior
    >>> wreak havoc on programs? Why not force the class member functions to
    >>> also only use accessors and mutators? That way, if there was a
    >>> problem, then the programmer KNOWS that the issue is with the get and
    >>> set functions and not anywhere else.

    >>
    >> That makes no sense: accessors and mutators are also class member functions.
    >>

    > Yes I know they are, and they should be the only member functions that
    > can access the pivate data members. There should be some special
    > designation that identifies them as not just member functions but also
    > special member functions.


    Why? Aren't all (or at least most) member functions mutators?

    --
    Ian Collins
     
    Ian Collins, Jun 27, 2010
    #4
  5. Dwight Army of Champions

    Bo Persson Guest

    Re: Why are member functions allowed to access private data members of a class?

    Dwight Army of Champions wrote:
    > I mean, as it is now you have a set_value() function that sets the
    > value of one of your data members. But there could potentially be
    > another member function out there of the same class that also sets
    > this value (by using the this pointer and the assignment operator).
    > Shouldn't this be disallowed?


    That would be enforcing a single paradigm, which C++ generally doesn't
    do. You are allowed to use set-functions, but not required.

    The class is protected from external manipulation, but the class
    members are part of the class, and supposed to know what they are
    doing.

    A lot of classes do not have a single set_value member, so it
    obviously works well anyway.


    Bo Persson



    >
    > On Jun 27, 4:29 pm, Dwight Army of Champions
    > <> wrote:
    >> Yes I know they are, and they should be the only member functions
    >> that can access the pivate data members. There should be some
    >> special designation that identifies them as not just member
    >> functions but also special member functions.
    >>
    >> On Jun 27, 4:23 pm, "Leigh Johnston" <> wrote:
    >>
    >>
    >>
    >>> "Dwight Army of Champions" <>
    >>> wrote in
    >>> messagenews:...

    >>
    >>>> I know that no outside functions can directly acces private data
    >>>> members of a class, and that all interface should be done
    >>>> through the get and set accessor/mutator functions, but my
    >>>> question is: What are class member functions allowed to access
    >>>> their own private data members? Because of these, data members
    >>>> can be manipulated and changed without use of the accessors and
    >>>> mutators, and couldn't such behavior wreak havoc on programs?
    >>>> Why not force the class member functions to also only use
    >>>> accessors and mutators? That way, if there was a problem, then
    >>>> the programmer KNOWS that the issue is with the get and set
    >>>> functions and not anywhere else.

    >>
    >>> That makes no sense: accessors and mutators are also class member
    >>> functions.

    >>
    >>> /Leigh- Hide quoted text -

    >>
    >> - Show quoted text -
     
    Bo Persson, Jun 27, 2010
    #5
  6. Dwight Army of Champions

    Ian Collins Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On 06/28/10 08:32 AM, Dwight Army of Champions wrote:
    > I mean, as it is now you have a set_value() function that sets the
    > value of one of your data members. But there could potentially be
    > another member function out there of the same class that also sets
    > this value (by using the this pointer and the assignment operator).
    > Shouldn't this be disallowed?


    Setters and getters are a sign of a bad design. If outside entities can
    directly manipulate data members, just make them public.

    --
    Ian Collins
     
    Ian Collins, Jun 27, 2010
    #6
  7. Re: Why are member functions allowed to access private data membersof a class?

    Dwight Army of Champions <>, on
    27/06/2010 13:20:30, wrote:

    > I know that no outside functions can directly acces private data
    > members of a class, and that all interface should be done through the
    > get and set accessor/mutator functions, but my question is: What are
    > class member functions allowed to access their own private data
    > members? Because of these, data members can be manipulated and changed
    > without use of the accessors and mutators, and couldn't such behavior
    > wreak havoc on programs? Why not force the class member functions to
    > also only use accessors and mutators? That way, if there was a
    > problem, then the programmer KNOWS that the issue is with the get and
    > set functions and not anywhere else.


    Further to the replies you already got, if you want to enforce this
    behavior in a particular class, you can always encapsulate the data in
    another class and only allow access through setters and getters - so
    that you can centralize checking and debugging, shall you need to, even
    for the very member functions of the class that owns that data (well,
    not owning it directly anymore, since you'd be proxy-ing it).

    --
    FSC
    http://userscripts.org/scripts/show/59948
     
    Francesco S. Carta, Jun 27, 2010
    #7
  8. Dwight Army of Champions

    Öö Tiib Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On 27 juuni, 23:29, Dwight Army of Champions
    <> wrote:
    > Yes I know they are, and they should be the only member functions that
    > can access the pivate data members. There should be some special
    > designation that identifies them as not just member functions but also
    > special member functions.


    The fact you say you have "accessor" member functions (getters and
    setters) to each data member indicates that you lack proper
    encapsulation. Possibly you lack OO design whatsoever. Get rid of all
    accessors. The next thing where your logic leads is common antipattern
    of DoerAndKnower.
     
    Öö Tiib, Jun 27, 2010
    #8
  9. Dwight Army of Champions

    Roy Smith Guest

    Re: Why are member functions allowed to access private data members of a class?

    In article
    <>,
    Dwight Army of Champions <> wrote:

    > I know that no outside functions can directly acces private data
    > members of a class, and that all interface should be done through the
    > get and set accessor/mutator functions, but my question is: What are
    > class member functions allowed to access their own private data
    > members? Because of these, data members can be manipulated and changed
    > without use of the accessors and mutators, and couldn't such behavior
    > wreak havoc on programs?


    Well, yes. But then again, any buggy code which can change the data in
    your object can wreak havoc. It's up to the programmer to guarantee
    that each mutator enforces the class invariants. You might want to look
    up "design by contract" to get some ideas about how some people have
    addressed this issue.

    > Why not force the class member functions to
    > also only use accessors and mutators? That way, if there was a
    > problem, then the programmer KNOWS that the issue is with the get and
    > set functions and not anywhere else.


    I can see the attractiveness of isolating the enforcement of invariants
    to as small an area in the code as possible. Once you get that code
    right, you've got a powerful tool to enforce correctness. The downside
    is that in most cases, it would probably make things more complicated.
     
    Roy Smith, Jun 27, 2010
    #9
  10. Dwight Army of Champions

    James Kanze Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Jun 27, 9:34 pm, Ian Collins <> wrote:
    > On 06/28/10 08:29 AM, Dwight Army of Champions wrote:


    [...]
    > >> That makes no sense: accessors and mutators are also class
    > >> member functions.


    > > Yes I know they are, and they should be the only member
    > > functions that can access the pivate data members. There
    > > should be some special designation that identifies them as
    > > not just member functions but also special member
    > > functions.


    > Why? Aren't all (or at least most) member functions mutators?


    Depends on the class. In a lot of cases, the only member
    function which is a mutator is operator=.

    On the other hand, most classes don't have very many setters or
    getters, so making them the only means of accessing class
    members would make most class members totally inaccessible after
    construction. Not very useful.

    --
    James Kanze
     
    James Kanze, Jun 28, 2010
    #10
  11. Re: Why are member functions allowed to access private data membersof a class?

    Ian Collins stopped playing his vuvuzela long enough to say:

    > On 06/28/10 08:32 AM, Dwight Army of Champions wrote:
    >> I mean, as it is now you have a set_value() function that sets the
    >> value of one of your data members. But there could potentially be
    >> another member function out there of the same class that also sets
    >> this value (by using the this pointer and the assignment operator).
    >> Shouldn't this be disallowed?

    >
    > Setters and getters are a sign of a bad design. If outside entities can
    > directly manipulate data members, just make them public.


    Nah. You never know when you might want to change the setter/getter to
    do things besides just setting/getting. Keep 'em under wraps.

    --
    Academic politics is the most vicious and bitter form of politics,
    because the stakes are so low.
    -- Wallace Sayre
     
    Chris Ahlstrom, Jun 28, 2010
    #11
  12. Dwight Army of Champions

    Jorgen Grahn Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Sun, 2010-06-27, Dwight Army of Champions wrote:
    > I know that no outside functions can directly acces private data
    > members of a class, and that all interface should be done through the
    > get and set accessor/mutator functions [...]


    Says who? In reality it depends on the problem at hand, the class and
    its environment. Stated as a fundamental rule like that, I have to say it
    sounds very old-fashioned, and will lead to bad code.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 28, 2010
    #12
  13. Dwight Army of Champions

    Jorgen Grahn Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Mon, 2010-06-28, Chris Ahlstrom wrote:
    > Ian Collins stopped playing his vuvuzela long enough to say:
    >
    >> On 06/28/10 08:32 AM, Dwight Army of Champions wrote:
    >>> I mean, as it is now you have a set_value() function that sets the
    >>> value of one of your data members. But there could potentially be
    >>> another member function out there of the same class that also sets
    >>> this value (by using the this pointer and the assignment operator).
    >>> Shouldn't this be disallowed?

    >>
    >> Setters and getters are a sign of a bad design. If outside entities can
    >> directly manipulate data members, just make them public.

    >
    > Nah. You never know when you might want to change the setter/getter to
    > do things besides just setting/getting. Keep 'em under wraps.


    If the calling code is also under your control (as it normally is
    unless you're a library writer) then that's no problem. Just change
    your class, recompile and clean up the calling code which suddenly
    stopped compiling.

    I prefer doing that to paying in advance for things which may never
    happen.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 28, 2010
    #13
  14. Dwight Army of Champions

    Bo Persson Guest

    Re: Why are member functions allowed to access private data members of a class?

    Chris Ahlstrom wrote:
    > Ian Collins stopped playing his vuvuzela long enough to say:
    >
    >> On 06/28/10 08:32 AM, Dwight Army of Champions wrote:
    >>> I mean, as it is now you have a set_value() function that sets the
    >>> value of one of your data members. But there could potentially be
    >>> another member function out there of the same class that also sets
    >>> this value (by using the this pointer and the assignment
    >>> operator). Shouldn't this be disallowed?

    >>
    >> Setters and getters are a sign of a bad design. If outside
    >> entities can directly manipulate data members, just make them
    >> public.

    >
    > Nah. You never know when you might want to change the
    > setter/getter to do things besides just setting/getting. Keep 'em
    > under wraps.


    Nah. If you design a class (struct) with all public data members, you
    already know that the members can be changed independently. Otehrwise
    you wouldn't do that.


    Bo Persson
     
    Bo Persson, Jun 28, 2010
    #14
  15. Dwight Army of Champions

    Jeremy Guest

    Re: Why are member functions allowed to access private data membersof a class?


    > Setters and getters are a sign of a bad design.  If outside entities can
    > directly manipulate data members, just make them public.
    >
    > --
    > Ian Collins



    Actually, mutator functions are not any sign of anything. At the very
    least they allow you to vary the implementation while having the
    interface stay the same. If you made the data members public then any
    time you need to change the implementation you need to track down
    every place in the code that uses that data member and change that
    instance. I would argue that that is a bad design.
     
    Jeremy, Jun 28, 2010
    #15
  16. Dwight Army of Champions

    Öö Tiib Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On 28 juuni, 21:18, Jeremy <> wrote:
    > > Setters and getters are a sign of a bad design.  If outside entities can
    > > directly manipulate data members, just make them public.

    >
    > Actually, mutator functions are not any sign of anything. At the very
    > least they allow you to vary the implementation while having the
    > interface stay the same.


    You about interface like OP suggested that has separate getters and
    setters for all private data members? Internal details have leaked all
    over the place for random Joe to manage and now it can stay forever
    like that? Who cares if such get/set/hack/grab interface can stay same
    forever? It *should* change ASAP.

    > If you made the data members public then any
    > time you need to change the implementation you need to track down
    > every place in the code that uses that data member and change that
    > instance. I would argue that that is a bad design.


    PODs are with everything public. POD is not good design? Go ahead and
    argue then? Lets copy-paste something. All public, no getters-setters:

    namespace SI
    {
    struct Prefix
    {
    enum Id
    {
    NoPrefix,
    Deca, Hecto, Kilo, Mega, Giga, Tera, Peta, Exa,
    Zetta, Yotta, Deci, Centi, Milli, Micro, Nano,
    Pico, Femto, Atto, Zepto, Yocto, Count
    };
    Id id;
    wchar_t const* name;
    wchar_t const* symbol;
    int factor;
    double multiplier() const { return pow( 10.0, factor ); }
    // ...
    // few other functions like multiplier()
    };

    Prefix const prefixes[Prefix::Count] =
    {
    { Prefix::NoPrefix, L"", L"", 0 },
    { Prefix::Deca, L"deca-", L"da", 1 },
    { Prefix::Hecto, L"hecto-", L"h", 2 },
    { Prefix::Kilo, L"kilo-", L"k", 3 },
    { Prefix::Mega, L"mega-", L"M", 6 },
    { Prefix::Giga, L"giga-", L"G", 9 },
    { Prefix::Tera, L"tera-", L"T", 12 },
    { Prefix::peta, L"peta-", L"P", 15 },
    { Prefix::Exa, L"exa-", L"E", 18 },
    { Prefix::Zetta, L"zetta-", L"Z", 21 },
    { Prefix::Yotta, L"yotta-", L"Y", 24 },
    { Prefix::Deci, L"deci-", L"d", -1 },
    { Prefix::Centi, L"centi-", L"c", -2 },
    { Prefix::Milli, L"milli-", L"m", -3 },
    { Prefix::Micro, L"micro-", L"ì", -6 },
    { Prefix::Nano, L"nano-", L"n", -9 },
    { Prefix::pico, L"pico-", L"p", -12 },
    { Prefix::Femto, L"femto-", L"f", -15 },
    { Prefix::Atto, L"atto-", L"a", -18 },
    { Prefix::Zepto, L"zepto-", L"z", -21 },
    { Prefix::Yocto, L"yocto-", L"y", -24 }
    };
    }

    Ok. So all about measurement unit prefixes in International System of
    Units (SI) defined with 50 lines of code. Now do same with your "good"
    getter-setter java design and show it to us.
     
    Öö Tiib, Jun 28, 2010
    #16
  17. Dwight Army of Champions

    Jorgen Grahn Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Mon, 2010-06-28, Jeremy wrote:
    >
    >> Setters and getters are a sign of a bad design.  If outside entities can
    >> directly manipulate data members, just make them public.

    ....
    >> Ian Collins

    >
    > Actually, mutator functions are not any sign of anything. At the very
    > least they allow you to vary the implementation while having the
    > interface stay the same. If you made the data members public then any
    > time you need to change the implementation you need to track down
    > every place in the code that uses that data member and change that
    > instance. I would argue that that is a bad design.


    "Track down" is misleading, because in 99% of all projects, you know
    that the compiler will list the places for you. See my posting
    elsewhere in the thread.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 28, 2010
    #17
  18. Dwight Army of Champions

    red floyd Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Jun 28, 6:39 am, Jorgen Grahn <> wrote:
    > On Sun, 2010-06-27, Dwight Army of Champions wrote:
    >
    > > I know that no outside functions can directly acces private data
    > > members of a class, and that all interface should be done through the
    > > get and set accessor/mutator functions [...]

    >
    > Says who?  In reality it depends on the problem at hand, the class and
    > its environment. Stated as a fundamental rule like that, I have to say it
    > sounds very old-fashioned, and will lead to bad code.
    >


    Ny guess: Says his (sadly mistaken) instructor, probably.
     
    red floyd, Jun 29, 2010
    #18
  19. Dwight Army of Champions

    Puppet_Sock Guest

    Re: Why are member functions allowed to access private data membersof a class?

    On Jun 27, 4:47 pm, Ian Collins <> wrote:
    [snip]
    > Setters and getters are a sign of a bad design.  If outside entities can
    > directly manipulate data members, just make them public.


    Set and Get fcns are a sign of shallow design. It is not
    universal that such is bad. Sometimes a shallow design is
    the right thing to do.

    The thing to do to get the design right is to think of a
    class as an exporter of some kind of service. It does
    some kind of job for you. Maybe that job is something very
    high level, involving a deep and complicated abstraction.
    "Behave as a shipping terminal" for example. In such a
    case you are unlikely to want get/set fcns, as in that case
    it would be extremely likely to be bad design. You want to
    have fcns that represent what the "shipping terminal" can
    do. Probably things like "receive truckload" or such.

    You want to make the solution space match the problem space.

    But sometimes the service is way less complicated. It could
    be "carry around the coordinates of a point in a graphical
    interface" or some such. In such cases a shallow design
    *may* be appropriate. Maybe, or maybe not depending on the
    context. But if it is appropriate, then get/set *might*
    be the way to go.

    Get/set also tend to be leaky spots in data hiding. If you
    have get/set fcns that give/take an integer, for example,
    it is a strong indication that the object has an integer
    inside. So there is a strong tendancy to do things like
    calculating the integer outside the object instead of
    inside. Often that is doing things in the wrong place.
    You could imagine the shipping terminal class being short-
    circuited by having total cargo stored be calculated outside
    the class code. Once again, the context will tell you if
    that is important.
    Socks
     
    Puppet_Sock, Jun 30, 2010
    #19
  20. Re: Why are member functions allowed to access private data members of a ?class?

    Dwight Army of Champions <> wrote:
    > I know that no outside functions can directly acces private data
    > members of a class, and that all interface should be done through the
    > get and set accessor/mutator functions


    That's a gross oversimplification, and in fact the overuse of accessors
    can often lead to bad design.

    While not always completely possible, and in many cases not completely
    necessary, it's nevertheless a good design principle that the public
    interface of a class should be as abstract as possible and reveal as
    little as possible about its internal implementation details.

    Public member variables are usually considered bad design because they
    expose internal implementation details to the outside, hence potentially
    causing outside code to start *depending* on those implementation details,
    making changing those details without breaking existing code harder.

    Accessor functions are only *slightly* better than public member variables,
    especially if there are many such accessors. Now the outside code will not
    depend on the member variables directly, but it will depend on the accessors.
    Hence removing, renaming or doing other kinds of changes to these accessors
    will probably break existing code. (It's not completely unusual that when
    refactoring a class its member variables are redesigned from scratch, hence
    often making some of the accessors obsolete or in need of heavy modification
    which changes significantly their signature.)

    The ideal situation is when the public interface of the class is so
    abstract that the outside code depends as little as possible on these
    internal implementation details. This makes it much easier to change these
    details without having to change the public interface and hence breaking
    existing code. (Naturally, as I already said, this is not always completely
    possible, but it would nevertheless be the ideal case.)

    There are some languages (such as C#) where all public member variables
    can be replaced with accessors without any change in syntax in the outside
    code. While this might sound handy at first, my personal opinion is that
    this kind of language feature is actually a mistake which, rather ironically,
    often leads to rigid code which is hard to refactor and modify. That's
    because the feature induces programmers to put member variables in the
    public interface of classes (thinking "I can always replace them with
    accessors if needed, so it doesn't matter"), making outside code depend
    on these implementation details, thus making it harder to change these
    details later. In other words, this feature often induces people to write
    less abstract code, to their own detriment.

    > but my question is: What are
    > class member functions allowed to access their own private data
    > members?


    I find that question rather strange. How should they access their own
    data then? If your answer is "through accessors", then exactly how do you
    implement those accessors? Accessors *are* member functions, after all.
    If member functions couldn't access member variables directly, then you
    couldn't implement accessors.

    (Yes, accessors must be regular member functions. That's the whole idea
    of an accessor: That you could modify it to do something completely
    different than simply return/set a member variable. Heck, the equivalent
    member variable might not actually exist at all.)

    From a design point of view, restricting access rights exists to stop
    outside code from accessing member variables directly, not to stop inside
    code from doing so. Inside code is restricted to a single module and thus
    is well encapsulated, making refactoring easier.

    > Because of these, data members can be manipulated and changed
    > without use of the accessors and mutators, and couldn't such behavior
    > wreak havoc on programs?


    Why would this be so?

    > Why not force the class member functions to
    > also only use accessors and mutators?


    And how do you suggest those accessors and mutators be implemented?
     
    Juha Nieminen, Jun 30, 2010
    #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. Alfred E Neuman
    Replies:
    3
    Views:
    281
    Alfred E Neuman
    Nov 4, 2003
  2. CoolPint
    Replies:
    8
    Views:
    1,029
    Jeff Schwab
    Dec 14, 2003
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,250
    Smokey Grindel
    Dec 2, 2006
  4. ssb
    Replies:
    58
    Views:
    1,709
    Chris M. Thomasson
    Sep 14, 2009
  5. trans.  (T. Onoma)
    Replies:
    6
    Views:
    145
    trans. (T. Onoma)
    Oct 1, 2004
Loading...

Share This Page