The coding standards are the least of your worries!
The coding standards are the least of your worries!
Posted Jun 2, 2010 19:48 UTC (Wed) by rev (guest, #15082)In reply to: The coding standards are the least of your worries! by ikm
Parent article: GCC begins move to C++
Posted Jun 2, 2010 19:54 UTC (Wed)
by ikm (guest, #493)
[Link] (5 responses)
Yes, that's exactly what I'm doing. What's wrong with it, exactly?
Posted Jun 2, 2010 20:09 UTC (Wed)
by ikm (guest, #493)
[Link] (2 responses)
What I want to say is, protected/private inheritance makes sense. A classic example is when you want to make an active object:
class Foo: QThread
You don't want start() and stop() to be exposed to the outside world, and yet you want it to be a thread (by being able to override the actual thread function).
Lastly, stating that something in the language is plain "meaningless" is implying that the people who agreed to add it to the standard are morons. This rarely makes sense.
Posted Jun 2, 2010 21:21 UTC (Wed)
by rev (guest, #15082)
[Link] (1 responses)
Your Foo class in your example is now a QThread except that it isn't: the outside world cannot call any of the methods that make it a QThread.
That you find yourself forced to use protected inheritance in your example is due to a modelling flaw in the QThread class. Not unlike the situation in which I found myself forced to subclass a HTTPConnection only to be able to get to the headers of a HTTP request. The QThread class should have something like a Worker member having the run() method. You implement a Worker (ie subclass it and implement the virtual run() function). You have a Qthread instance var, feed it your worker implementation, and call start() on your QThread.
A useful way, BTW, to find out whether you have woven different concepts into a single class, that thus should be decomposed into different classes is this:
Picture all the instance variables of your class and it superclass on one side. Likewise, picture all functions on the other side. Now draw a line between a function and a variable when said function uses that variable, If the resulting class now tends to consists of several unconnected graphs you have reason to consider decomposing your classes: the belong to the same hierarchy but appear to be unrelated.
Applied to the QThread example: the designers of the QThread should have asked themselves the question: is it desirable that an implementation of the run() function have access to the protected instance variables? The answer is no. Because QThread deals with the machinery of threading while the run() functions deals with matters of the user's problem domain, like reading messages from a queue. The stuff in the run() function is therefore another beast that needs to sit in its own class.
I find your 'moron' remark rather odd. Firstly, no language is perfect, no language designer is. Secondly, C++ was conceived at a time when understanding of OO was, by today's standards, rather limited.
Posted Jun 2, 2010 21:34 UTC (Wed)
by ikm (guest, #493)
[Link]
Maybe to the world, but not to him. To him, he is a werewolf. At night, when there is a full moon, he transforms into an unholy beast and hunts basic_strings. The world doesn't have to know.
Posted Jun 2, 2010 20:38 UTC (Wed)
by rev (guest, #15082)
[Link]
Please see my HTTP connection example in my post http://lwn.net/Articles/390256/ to see why this is, in general bad.
Posted Jun 2, 2010 20:57 UTC (Wed)
by rev (guest, #15082)
[Link]
To recapitulate:
When you write an HAS-A as an IS-A you really tied two concepts into one which are not.
Suppose you have class D: C
Suppose later you need another flavor of C, say B, or you have to rewrite D You will have to rewrite D and its relationship.
Now write:
class D {
You one day need a B. Introduce an abstract base class A for both B and C:
class D {
Now you have the advantage that you can easily change 'a' to be a B or a C.
BTW, there's people that take this advantage to the next level. They recognized that A has become a dependency of D. And rather than hard-wiring this dependency in your code created tools that allow you to specify in a configuration file whether 'a' should be an B or a C. Some day another kind of A is needed? Write a class E, deploy it, modify the config file and there you go.
The coding standards are the least of your worries!
The coding standards are the least of your worries!
{
...
private:
virtual void run();
}
The coding standards are the least of your worries!
The coding standards are the least of your worries!
The coding standards are the least of your worries!
The coding standards are the least of your worries!
private:
C c;
}
private:
A a;
}