In this interview, C++ creator Bjarne Stroustrup suggests C++ programmers can get the most from C++ by avoiding the perils of staying too low level and venturing too object-oriented in C++ programming style.

http://www.artima.com/intv/goldilocks.html

What do you think of Bjarne's comments?

Thanks for posting this article, it made for interesting reading.

I'm relatively new to C++ and am curious about the libc++ library referred to on the first page of the article. Is this libstdc++ or something else? I don't see the callbacks, signals, and slots he's referring to in the implementation I'm using. I've attempted a web search using google with the pertinent phrases, but struck out. Likewise, with my C++ books.

Any pointers or beatings with the clue stick would be appreciated.

Trevor

> In this interview...
> http://www.artima.com/intv/goldilocks.html

Goldilocks?

Stroustrup has indirectly exposed the core reason why engineering has yet to truly come into its own as a valid profession and in most corporate settings remains sadly trapped between management and paradigms such as OOPS. His admonitions about overdoing the creation of classes will never be accepted on the same level as object oriented engineering itself. They require a mature thoughtfullness and passion would result in very fine design and coding in any language or paradigm. These qualities cannot be directly controlled by customers or corporate management and thus do not represent, nor should they, a commodity that they are interested in purchasing. For this, we need leadership from passionate individuals within the engineering community itself and directly on the product development floor. It is up to the engineers to stop waiting for management to ask them to do it and to stop waiting for a better paradigm. We must take responsibility entirely for these matters and show the world what we can do.

-codegopher :-)
mcrane@iii.com

Oops! I meant "OOP", not OOPS. I hope my typos and grammatical lapses to not obscure my point too much.

-codegopher :-)

This is probably the best interview with Bjarne Stroustrup I've ever seen. I think often he's put in a position of "now that new craze X has come along, can you defend C++ as a language given what's been learned from the new craze". In this interview, Venners is following the track of "what makes good design in C++" and "how can people write better C++", and the responses he gets are incredible!

I think in part this shows Venner's experience with interviewing others. He's also using a lot of pair-programming type language to get clarification on Stroustrup's points.

Bill Venners: You said that the invariant helps you decide what goes into the interface.

I read back and didn't see where he said that. But it's an interesting idea. Which was followed up with:

Bill Venners: Could you elaborate on how? Let me attempt to restate what you said, and see if I understand it. The functions that are taking any responsibility for maintaining the invariant should be in the class.

Bjarne Stroustrup: Yes.

Bill Venners: Anything that's just using the data, but not defending the invariant, doesn't need to be in the class. (Followed by Stroustrup's elaboration.)

Wow. This is a new way of thinking about designing objects for me. It's too new to know whether I agree with it or not. If you needed 50 methods, you still need that functionality, don't you? Where do you put it?

Stroustrup mentions static methods as a possibility for Java, but they have some ring of ugliness to them. Is there some convention or heuristic that can be followed?

> > In this interview...
> > http://www.artima.com/intv/goldilocks.html
>
> Goldilocks?

I chose the filename because the article reminded me of Goldilocks and the Three Bears, in that one C++ program is too low level, another one is to object-oriented, and a third one is just right:

http://www.ongoing-tales.com/SERIALS/oldtime/FAIRYTALES/goldilocks.html

The "Sweet Spot" title came from my teenage readings about tennis. I read somewhere that a tennis racket has an oval area in the lower center called the "sweet spot." When you hit the ball there, you get the maximum power out of the tool. And it sounds and feels good too. Thok. I felt that metaphor fit well with the point Bjarne was trying to make about C++ style.

That's libsigc++, which is an independent project separate from the standard C++ library. See link to sourceforge project at the end of the interview (does this qualify as beating with a stick?). It's a cool library.

This is a great interview, by the way. Thanks!

Russell

Thanks for the gentle bruising with the clue stick :-) AFAIT, the article got updated to include the correct library name and reference since yesterday, no, no, honestly...

Trevor

> Thanks for the gentle bruising with the clue stick :-)
> AFAIT, the article got updated to include the correct
> library name and reference since yesterday, no, no,
> honestly...
>
Yes, a reader emailed me suspecting it was a typo. Bjarne agreed. I fixed it and added the link in the resources section.

The advice Scott Meyers gives iirc is to have any supplementary functions that don't need direct access to the class data (and hence don't need to be member functions) in the same namespace as the class. He explains it better than i do so perhaps a quick google is in order. Perhaps you could start with his artima interview, again on that elusive 'sweet spot'.

http://www.artima.com/intv/mincomp4.html

The interesting part of the interview was the necessity to keep the number of virtual functions / member functions to a minimum. I wonder if there is any numerical limit on the number of functions. Agreed it differs from each application, but in general what do you think is an optimal number of functions in a class ? Both in terms of performance and also in terms of maintainability.
And the idea of the invariants is excellent !

For Java, I tend to follow a "rule of ten". Each method has 10 lines, each class has 10 methods, and each package has 10 classes. Those are obviously rough guidelines, but larger ratios make the code difficult to read and maintain.

> For Java, I tend to follow a "rule of ten". Each method
> has 10 lines, each class has 10 methods, and each package
> has 10 classes. Those are obviously rough guidelines, but
> larger ratios make the code difficult to read and
> maintain.

So, how would you refactor JFrame in Java, or CWnd in MFC, for example? Or at least, what general approach would you take?

This is something that came up with Scott Meyer's interview and some others, if I remember. I've been trying to get Bill to follow up by asking about refactoring a specific example of a well-known class with a ton of methods, such as either of the two mentioned above.

> So, how would you refactor JFrame in Java, or
> CWnd in MFC, for example? Or at least, what
> general approach would you take?
>
> This is something that came up with Scott Meyer's
> interview and some others, if I remember. I've been
> trying to get Bill to follow up by asking about
> refactoring a specific example of a well-known class with
> a ton of methods, such as either of the two mentioned
> above.

Ken Arnold touched on this with his <code>getKnobs()</code> notion. Basically he suggested having the handful of methods that most people use most of the time in the interface, plus a <code>getKnobs()</code> method that allows people to tweak all the little details that sometimes some people will want to tweak. Kind of like flipping down that little hidden panel on your TV set to reveal little knobs that let you mess with the color, horizontal scan rate, and so on:

http://www.artima.com/intv/taste4.html