C++ Member Function Lookup

I'm reading `C++ Common Knowledge' to find out more about this fascinating pile of crap. I'm currently in the section `Member Function Lookup' and discovered this gem:

class Foo {
public:
        void x(int) {}
};

class Bar : Foo {
        int x; /* This is fuckin' private. */
};

int main()
{
        Bar bar;
        bar.x(3);
        return 0;
}

I understand what it does and why it does it, but what the fuck was Bjarne thinking when he decided this? If this is object-oriented programming, I'm Ada Lovelace. HIBT?

But what the fuck was Bjarne thinking when he decided this?

``This seems to be a great idea! Indeed, I am smart, moreover, I am a genius. I will proceed to masturbate.''

LOVELACE MY ANUS

What the fuck are you thinking, giving a variable the same name as a function?

It may be confusing, but it shouldn't matter if you separate the function and variable namespaces. Lisp-2's (like CL) do this well:
#'function-name == (function function-name)
variable-name
(function-name variable-name)

(defun list-of-list (list)
  (list list))

>>4
There are two severe problems with the approach C++ is taking: first of all, Bar's x is private. I, by their very definition, shouldn't need to be concerned about members I can't see. Even if it was public, the right thing would be to realize that `int x' doesn't match the required signature for `bar.x(3)' and continue the search to the base classes.
>>5
OH RLY? funcall my anus.

>>6
Why not replace funcall with a special symbol via reader macro, then? The only thing special about funcall is that it requires the function to be passed in the variable namespace.

>>7
Did you notice that this thread is not about Common Lisp? It is about C++. I know how to deal with funcall the way I want. >>5 was the one who brought CL into this thread.

>>5
Why stop at 2? Why not let every little trivial type in your language have its own namespace? That'd really clean things up.

>>6
That doesn't answer my question. Why would you ever need to give a variable the same name as a function? Why don't you complain about things that actually matter, rather than this trivial bullshit nobody could care less about?

>>9
That's why it's actually called a Lisp-n.

>>10
Okay, let's rephrase it:
class Foo {
public:
        void x(int) {}
};

class Bar : Foo {
        void x() {} /* This is still fuckin' private. */
};

int main()
{
        Bar bar;
        bar.x(3);
        return 0;
}
Will you shut up now?

I'm not sure what this thread is going on about, but it's been worth twelve posts so far.

>>10
I don't know about C++, but I actually (ab)use the fact that there's a separate namespace for functions and variables in CL (well, there's also the package system which allows for even better control). For example, I almost always use "list" as a name for an argument representing a list on a function that's meant to just do some generic operation on lists. At the same time, "list" is also a function which just conses up a list. In Scheme and Lisp-1's, where there is a single namespace, people just name such arguments "lst"/"lyst" or similar to avoid shadowing the "list" function.

>>14
Lyst! Lyst! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
In what distant deeps or skies
Burnt the fire of thine eyes?
On what wings dare he aspire?
What the hand dare sieze the fire?
And what shoulder, & what art.
Could twist the sinews of thy heart?
And when thy heart began to beat,
What dread hand? & what dread feet?
What the hammer? what the chain?
In what furnace was thy brain?
What the anvil? what dread grasp
Dare its deadly terrors clasp?
When the stars threw down their spears,
And watered heaven with their tears,
Did he smile his work to see?
Did he who made the Lamb make thee?
Lyst! Lyst! burning bright
In the forests of the night,
What immortal hand or eye
Dare frame thy fearful symmetry?

>>10
I could care less.

>>16
Then by all means, do.

>>1
Of all the things in C++, this seems like a really *good* idea to me. Why would you want your subclass to be affected by private variables in the base class that you know nothing about?

There's a reason why Sepplesix is bringing in inheritance specifiers to clarify your intent. Unfortunately, they're ugly as fuck, so it's unlikely that they'll find a great deal of use.

you stupid fuck, learn to fucking use fucking C++ class hierarchies..bitch...cut ur self and die

>>18
What do you mean? The base class function is public and the one in the subclass is private, which I know nothing about. Still it blocks my way to the base class.

>>20
You mad?

>>22
NO, U MAD

Breaking news: clarity of semi-OOP language compromised because of gimped message-passing clone! More at twelve!

>>21
Oh wait, I misread the original posting; I thought Foo extended Bar, not the other way around. I actually tried to compile the thing now and I get what you're saying. Sorry, >>18 retracted; just another thing to hate about sepples I guess.

I don't really get this thread, but neither >>1 or >>12 compile under GCC.

>>26

you mena g++?

>>27
wow that was fast, but sure

>>28
That's what SHE said.

>>29
Back to [i]/r9k/[i], Randall.

Of course Bjarne was wrong, but was it intentional?  Public instance variable are a heresy in first place. Everytime g++ spits you three pages of arcane STL errors, it's like the Stroustrup is slapping his limp dick as your face. Cunning, ^{cunningBjarne}.

>>26
That is the point of this thread.

35 Name: Anonymous 2011-02-04 12:40

36 Name: Anonymous 2011-02-04 17:54

---

Don't change these.

Name:		Email:
Entire Thread Thread List