Scott Meyers on Programming C++

Bill Venners writes "Artima.com has published a four-part interview with Scott Meyers, author of Effective C++, More Effective C++, and Effective STL. In Multiple Inheritance and Interfaces, Scott describes how his view of multiple inheritance has changed with time, the C++ community's take on Java's interface, and a schism of focus between the C++ and other prominent development communities. In Designing Contracts and Interfaces, Scott discusses interface contracts, private data, and designing minimal and complete interfaces. In Meaningful Programming, Scott discusses the importance of saying what you mean and understanding what you say, the three fundamental relationships between classes, and the difference between virtual and non-virtual functions. In Const, RTTI, and Efficiency, Scott describes the utility of const, the appropriate time to use RTTI, a good attitude about efficiency, and Scott Meyers' current quest for general programming principles."

Comments

Meyer's books on C++

[Henry V .009]

I own each of Meyer's books, and they are all wonderful. If you work with C++ in any sort of professional capacity get a hold of copies right now.

Re:Meyer's books on C++

[Henry V .009]

Of course--choose the language to fit the problem. And for the most part, if you have a very simple application that you want to finish up very quickly, C# or Java or such can be very good. I find, however, that C++ is the best tool for a number of complicated things. And that's what interests me for the most part.

Re:Meyer's books on C++

[Henry V .009]

Ah, but it's the data structures in C++ that I love. Once you know how to use the STL, you'll find that it's quite the tool for data structures.

Best quote from the extended interview

[Lumpish Scholar]

Meyers: "... we have templates in C++, but there's no way to write user interfaces or talk to databases. Java has no templates, but you can write user interfaces up the wazoo and you can talk to databases with no trouble at all."

Re:Best quote from the extended interview

[Anonymous Brave Guy]

And soon, Java will have templates, too (in upcoming version 1.5).

Just to set the record straight... Java will have some support for generics (no bad thing), but none of the specs I've seen show the same power as C++ templates.

Good articles

[amorico]

One thing he says though is not necessarily true in java:

". . .interfaces also have no data. I have come to appreciate that if you use abstract base classes and eliminate any data from them, then a lot of the difficulties of multiple inheritance that I wrote about just go away, even in C++."

Interfaces in java can have member variables but they are always public (universally accessible), static (not associated with any particular instance of a class) and final (unchanging). Thus, if you use data members in interfaces you cannot hide them in the implementing class, but this is mitigated by them being read only. I have not seen anyone use these inherited constants (which is what they amount to), and I can't think of a major drawback to using them, but I don't know of any advantage either.

Does anyone know why interfaces have data members at all?

Re:Good articles

[Tom7]

> Does anyone know why interfaces have data members at all?

It's so that you can define constants (you know, MAX_SET_SIZE), because Java has no preprocessor. I'm not sure why constants in interfaces are so important, but my guess it is the language's answer to some whiny C/C++ programmer on the design team who couldn't express his favorite idiom without it.

Re:Good articles

[adamy]

One way that they are used is to define a short cut to a set of a constants. Put all you constants in an interface, and then any class that needs those constants can implmenbet the interface, and they car refere to the constants without using the entire class path.

Also, many classes use them for related Symbolc constants to functions that are overly flexible. See the Calendar implementation for get/set (Yes, an ABC, not an interface, but the result is the same).

I actually think of this as an indicator of Bad design. Use of symbolic constants, especially as a replacement for Enum, is a serious breach of OO design in most cases. Static immutable instances of classes that the enum represents are quite often a better way to go. This was a tip I got from the other Effective Book: Effective Java
Found here at Amazon

Re:Good articles

[fingal]

I actually think of this as an indicator of Bad design. Use of symbolic constants, especially as a replacement for Enum, is a serious breach of OO design in most cases. Static immutable instances of classes that the enum represents are quite often a better way to go.

The Static immutable instances of classes gets half-way there, but doesn't stop people creating new instances of the classes and then you are back where you where to begin with. A better thing to do is to forcibly limit the instances of the classes to a fixed number of instances like so:-

public class MyEnum {
private MyEnum() { }
public final static MyEnum OPTION1 = new MyEnum();
public final static MyEnum OPTION2 = new MyEnum();
public final static MyEnum OPTION3 = new MyEnum();
}

Now you are guaranteed that there is only ever going to be MyEnum.OPTION1, MyEnum.OPTION2 and MyEnum.OPTION3.

Re:Good articles

[Pseudonym]

I'm not sure why constants in interfaces are so important, but my guess it is the language's answer to some whiny C/C++ programmer on the design team who couldn't express his favorite idiom without it.

It's because Java doesn't have enumerated types, which are often part of an object's interface.

Sure you can do without enums (e.g. by using an ABC and deriving the relevant constants), but you wouldn't want to.

Re:Good articles

[adamy]

Actually, that is covered in the section of the book to which i referred. A Very good point.

I noticed on your site you've developed a CM tool in Java. Did you use this pattern in your code? It makes for an interesting style when developing select boxes, doesn't it? I found we typically developed a static array with the required static elements. For Instance

public static final MyEnum[] FIRST_AND_THIRD - {OPTION1, OPTION3};

Also a strange thing we had to do was:

private static final Hashtable all; //static block for init:
{
all = new Hashtable;
all.put(OPTION1.getName(), OPTION1) //etc

}
public static MyEnum findByName(String name){
return all.get(name);
}

Have you found this to be the case as well?

Re:Good articles

[adamy]

Actuall, this is also covered in the effective Java book. He talks about overloading equals, as well as the serialization methods (I think it is writeObject, but I'd have to check). All in all a great book on getting better at some of the more esoteric portions of java

Re:Good articles

[Anonymous Brave Guy]

Does anyone know why interfaces have data members at all?

They wouldn't normally have state, but there might be constants relating to the interface itself, typically passed used when determining what parameters to pass to functions in that interface. Given Java's lack of enumerated types, this is particularly important to avoid passing magic numbers or arbitrary boolean parameters everywhere.

Re:Good articles

[Julian Morrison]

And with 10,000 of those defined in your code, that's 10,000 instances of slightly-relabled Object to be constructed at startup and sit in RAM afterward, doing diddly-squat. A "public static final int CONST_FOO = 1" type definition meanwhile occupies precisely 4 bytes of space and takes no time to initialize.

Remember, even bare Object instances have behavior. You can wait on them, notify them, get their hashcode, etc etc... they are not negligible.

Standard APIs

[adamy]

One reason Java has standard libraries is that Sun pushed big time for standard libraries. C++ Hasn't had anyone pushing for stuff like that. Bjarne Stroustrup says that he favors a minimal standard library, and so in C++ the standard library is minimal.

Interfaces are the primary mechanism where Java has enforced the APIs for JDBC, EJB, Servlet etc.

Now that Java is about to get Templates, I wonder how that will change the way they go about standard APIs, especially for collections.

What libraries would make sense to have in C++? Network stuff, Database access, Web Programming, Graphics (OpenGL, DirectX), Windows Apps (Qt, MFC), XML, Logging, OS abstractions (Memory and Threading come to mind, Semaphore/Mutex, IPC). But the real question is, 'Does the lack of standard libraries help or hurt development in these fields?' I'd venture to say a both POV could be argued.

Re:Standard APIs

[Nynaeve]

Bjarne Stroustrup says that he favors a minimal standard library, and so in C++ the standard library is minimal.

From C++ Answers From Bjarne Stroustrup:
I think my most obvious mistake was not to introduce templates before multiple inheritance and not to ship a larger library with Release 1 of my C++ compiler

Does he still favor a minimal library? If so, does anyone know why?

Re:Standard APIs

[adamy]

I was actually refereeing to what was written in the C++ Programming Language book. Don't have w/ me here at work so I can't get an exact quote, but the discussion dealt with something along the lines of:

What should be in some library, everything. But what should be in the standard library...and he goes on to specify that it should a be a pretty small subset. I'll set if I can find it tonight at home.

Re:Standard APIs

[m8pple]

There is some work towards improving the C++ standard library via boost, which is the semi-official testing ground for candidates. Most of the libraries are simply utilities for exploiting the language efficiently and safely, but there are also some more systems orientated libraries such as a cross platform threading library, filesytem support, type safe printf etc.

There has been talk of doing some higher level things such as networking, graphics and user interfaces, but nobody can come up with specifications that are simple enough, or that are easily ported between platforms.

Coolest new bit is the Spirit parser generator. Who needs seperate lex+yacc files, embed that BNF in the C++ :)

Java has no templates...

[SilenceDK]

Meyers is apparently not the only one thinking that java needs templates: Preparing for Generics

public final static variables in interfaces (was R

[fingal]

Does anyone know why interfaces have data members at all?

It can be a very useful way of exposing constants. For example, consider the following:-

public interface VariableList {
public final static String VAL1 = "val1";
public final static String VAL2 = "val2";
public final static String[] VAL_ARRAY = { VAL1, VAL2 };
public final static List VAL_LIST = Collections.unmodifiableList( Arrays.asList( VAL_ARRAY ) );
}

This will provide you with a slightly more flexible set of constants that are automatically acquired by anything that implemnts the VariableList interface.

Alternatively, you can use Mutable variables. Remember that it is only the references to the variable that is final. If the Object itself contains information then it accessed by all classes that implement the interface. For example:-

public interface CountMe {
public Set INSTANCES = new Set();
}

If we now stipulate that all instances of CountMe that want to be included in the CountMe functionality should register themselves inside the INSTANCES variable, for example:-

import java.util.*;

public class Test {

public Test() {
Class1 class1 = new Class1();
Class2 class2 = new Class2();
Iterator instances = class1.INSTANCES.iterator();
while( instances.hasNext() ) {
System.out.println(instances.next());
}
}

public interface CountMe {
public Set INSTANCES = new HashSet();
}

public class Class1 implements CountMe {
public Class1() {
INSTANCES.add(this);
}
}

public class Class2 implements CountMe {
public Class2() {
INSTANCES.add(this);
}
}

public static void main(String[] args) {
new Test();
}
}

and there you have it - data sharing across interfaces with no extending classes at all. Of course, you cannot force classes to register themselves in the INSTANCES variable, but if you wanted to extend a couple of base classes then it would be trivial to make a couple of implementations of CountMe that extend each of them which enforce the functionality explicitly.

I've always thought Meyers was wrong about MI...

[swillden]

... and this article has helped me to understand precisely why we disagreed. And he's still wrong, although he's getting closer.

I've been writing C++ code professionally since about 91, when Scott published his first book. I think I was lucky that I didn't come across his book for a few years, particularly because of his skepticism of MI. I might have followed his advice and my career would have been the worse for it.

I have always made heavy use of MI in my code, and 80% of the time I've written C++ classes that are exactly analogous to Java interfaces; it just always seemed like a good idea to me. Also, I was a big fan of Robert C. Martin and his notions about how you can analyze design quality by looking at the abstractness of the classes and the dependencies between them (dependencies on abstract classes, especially pure abstract classes(*) are, much better than dependencies on classes that do a lot of stuff for the simple reason that classes that do a lot have more potential to change, so purely abstract firewalls tend to limit the ripple effect).

To avoid self-aggrandizement, I didn't independently invent the notion of pure abstractions. I had fiddled with Objective-C and it had a construct (whose name I forget) that allowed you to define a pure interface. You could then use that pure interface type as a function parameter and the compiler would verify that objects you passed to that function met the interface requirements -- allowing you to get compile-time typechecking in an otherwise completely dynamically-typed language.

However, as I said, I think only about 80% of my MI usage is with pure abstractions. Probably 10% of the time I use MI, I do it to facilitate a style of programming called "mix-in" programming. The idea is that you have a bunch of purely abstract classes that define the potential interfaces, and you have a bunch of concrete classes that implement the pure abstractions in various useful ways and then you can create useful classes by mixing together appropriate base classes (with the occasional bit of glue). Mix-ins aren't appropriate for everything, but they can be a very elegant solution for many toolkit kinds of scenarios. Diamond inheritance doesn't really happen, because none of the mixed-together classes have enough code in them to make it worth inheriting from them. If you need something almost like one mixed-together class, you just mix a completely new one.

In practice, not only do pure abstractions and mix-ins sidestep all of the "problems" that make people leery of MI, they're also not at all confusing to less competent programmers. I've found that with just the tiniest explanation of how the structure is put together, people can see immediately how it works and why it's good (well, once they've understood the idea of polymorphism, anyway).

I think C++ MI can also be used more fully to good effect, but that must, indeed, be done judiciously.

(*) Scott said in the interview that the C++ community doesn't have a name for interface classes. Maybe not, but I've been using the term "pure abstract class" for close to a decade and I don't think I've come across a single marginally-competent C++ programmer who didn't immediately understand the term, and I'm pretty sure I picked the term up from comp.lang.c++.

population of your encompassing hashtables...

[fingal]

The easiest way of making a cleaner approach to storing the ranges of items in the maps (without having to remember to update lots of locations when you change the contents of your MyEnum[] is to use the contents of the Array itself. So if you just want a List then you would say:-

public final static List FIRST_AND_THIRD_LIST = Collections.unmodifiableList( Arrays.AsList( FIRST_AND_THIRD ) );

Now in your example, you are using a Hashtable with a method of MyEnum called getName(). I would be tempted to extract this Nameable method into an interface (Named) and then create a dedicated Map that would look something like this:-

public class NamedMap
extends HashMap {
public NamedMap() { super(); }

public NamedMap(Collection collection) {
this();
put(collection);
}

public Object put(Named named) {
put(named.getName(), named);
}

public Object put(Collection collection) {
Iterator items = collection.iterator();
while (items.hasNext()) {
Object item = items.next();
if (item instanceof Named) {
put((Named) item);
}}}

}

Then you can finish up by adding another constant to your MyEnum class that provides you with the Map functionality that you wanted:-

public final static Map FIRST_AND_LAST_MAP = new NamedMap(FIRST_AND_THIRD_LIST);

Now if you change the definition of FIRST_AND_LAST then all of your other constants (List and Map) will get updated automatically thereby ensuring that you preserve the main benefit of utilising constants: only having to remember to Get Things Right Once.

Re:population of your encompassing hashtables...

[adamy]

Looks good. Have you done this in the past.

Also, one thing I had wondered, do you overload toString to return the internationalized string, or do you return the key to the properties file for external use? The first controls all access in one place, but the second makes it easier to centralize internationalization one place and turn it over to the translators.

Re:population of your encompassing hashtables...

[fingal]

Also, one thing I had wondered, do you overload toString to return the internationalized string, or do you return the key to the properties file for external use? The first controls all access in one place, but the second makes it easier to centralize internationalization one place and turn it over to the translators.

I would generally say that something as generic as toString() shouldn't be tied to a particular meaning (especially when interfaces are concerned). Instead, I would be much more likely to provide a seperate Interface that described i8n (if I was using it). Another reason for this is that I kind of feel that toString() should be "relatively" constant for a given Object and if the value changed as some external entity changed the current language then this might confuse matters. I would be more likely to return the name of the key, with some additional information to make it clear that this is the key to a MyEnum Object such as "MyEnum(key)" to clarify the difference between it and a normal String with a value of "key". All depends on the context though...

overloading equals

[fingal]

Don't forget to overload hashCode() as well if you are going to supply your own implementation of equals(). You'll have all sorts of fun trying to make sense of putting your Objects into hashed data structures otherwise.

The equals-hashCode contract states that two objects that are equal must return the same hashCode.

Re:I've always thought Meyers was wrong about MI..

[swillden]

The approach I'm aiming for involves designing quite a large number of fairly minimal classes and plugging them together using MI to get the final behaviour I want.

Yes, that's mix-in programming in a nutshell. Thanks, you stated it better than I did. You can see why "diamond" inheritance isn't a concern in that kind of a structure -- there's really never any need to inherit from a "plugged-together" class; if you need another class with slightly different behavior, you grab your toolbox and plug it tothether.

Re:I've always thought Meyers was wrong about MI..

[bvenners]

I think I was lucky that I didn't come across his book for a few years, particularly because of his skepticism of MI. I might have followed his advice and my career would have been the worse for it.

Funny, you had the opposite experience that I had. I discovered Scott's book quite by accident when I first started programming C++. It guided me away from multiple inheritance, which I ended up never using until I turned to Java five years later.

To avoid self-aggrandizement, I didn't independently invent the notion of pure abstractions. I had fiddled with Objective-C and it had a construct (whose name I forget) that allowed you to define a pure interface.

Your comment about Objective-C reminded me of something James Gosling once said in one of my interviews. I went to Artima.com and searched for it, but couldn't find it. To my surprise, the comment wasn't in the article anywhere. I went back to the text file that originally came back from the transcriber in 1999, and there was his comment. Somehow it never got published. So I just published it four years after he said it. Sorry.

Like you, Gosling found inspiration for Java's interface from the corresponding construct in Objective-C. Here's what he said in 1999:

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

Re:I've always thought Meyers was wrong about MI..

[swillden]

Like you, Gosling found inspiration for Java's interface from the corresponding construct in Objective-C.

That is very cool...

In case anyone is wondering, the Objective-C construct in question is the "protocol". A protocol is essentially nothing more than a list of methods, with no implementations. A class can indicate that it intends to "conform" to one or more protocols, and the compiler will issue a warning if doesn't implement everything. Methods can also specify that their parameters should conform to a certain set of protocols and object references (id's) can specify that they can only point to objects that conform to a certain set of protocols.

The compiler will perform compile-time type checking wherever it has enough information. So, if you create an object instance and then a few lines later try to assign it to an id or pass it to a method that have a protocol specification, and the object doesn't implement all of the methods required, the compiler will complain. I don't think it's even necessary that the class *specify* conformance to a protocol, the compiler can still check by seeing if all of the required methods are present. Of course, if the compiler doesn't have all of the information it needs, then run-time typechecks are generated.

Protocols were primarily invented, I believe, to make it feasible to detect errors at compile time rather than at run time. In practice, though, anyone who used them quickly discovered that they're also a very effective tool for understanding and defining the structure of a complex program -- and they did it without limiting or constraining the dynamic typing of the language at all.

It's a small step from seeing how protocols can layer structure onto a dynamically-typed language to seeing how they can define structure in a statically-typed language, where the structure must be completely verifiable at compile time because there are limited (or no!) facilities for run-time checks.

My favorite programming language is, and maybe always will be, Objective-C++. It turns out that although Objective-C and C++ are both OO extensions to C, they take completely different approaches, both philosophically and syntactically. In fact, the syntaxes of the extensions are so completely orthogonal that you can just lump them together into a single language, without ambiguity. Since NeXT built their Objective-C compiler on top of gcc, and others were building C++ on top of gcc, the merger was natural.

The result is a language that has all the expressive power and flexibility of a fully dynamically-typed language *and* all of the on-the-metal performance of a statically-typed language designed to be as efficient as C. The programmer gets to choose the tradeoffs between expressiveness and performance on a class by class basis, and can easily mix and match, passing C++ objects to Objective-C class methods and vice-versa.

Of course, the result also has all of the arcane complexity of C++, and although Objective-C is very simple, the resulting design decisions are anything but, since there are two very different views of object orientation to be mixed and matched. For the programmer who has mastered both views and also understands the dusty corners of C++, the combination is extremely powerful and, IMO, wholly appropriate to everything from on-the-metal bit twiddling to rapid development of large, complex applications...

... as long as they can be written by this single programmer, because the odds of finding two people who can agree on enough of the myriad design tradeoffs to get any useful work done is next to nil. And don't even *think* about bringing a novice developer onto the project.

Re:Scott Meyers

[elflord]

If he'd stayed in college and got his degree, maybe he could write with some authority, but as it stands... No.

He has a Ph.D. Have a nice day.

Re:Type Safe Enum considered harmful

[adamy]

Seems to me that if your type checking is failing due to different class loaders, you may have a bigger problems than just the enumerations.

THe best thing about the type safe enum is that it can quite possibly grow into a full blown class. Many of my classes start off this way, gather functionality, and ended up being more than just a enumeration.

That being said...does this pattern work in C++. I would think so but I haven't tried it.

C++ community not using interfaces?

[spongman]

But I would say that while the C++ community was focusing on templates, the STL, and exceptions... what they were not doing was component-based development.

I don't know where Scott's been for the last 10 years but COM specifically uses multiple inheritance of abstract base classes without data or implementation to specify interfaces for component-based development (and I believe that CORBA does the same).

I'd guess that win32 C++ programmers make up the largest such subset of all C++ programmers. So which C++ community is he talking about exactly?

Re:I've always thought Meyers was wrong about MI..

[spongman]

it can become a performance concern as soon as you start referencing pointers to members of such a class.

Re:I've always thought Meyers was wrong about MI..

[swillden]

Somewhat. The overhead isn't usually that severe anyway, unless you're making calls to a member function pointer in a tight loop, and maybe not even then, depending on the details. However, this is one of the tradeoffs that has to be considered. I use member function pointers primarily to implement closures for building flexible callbacks and tend to avoid them in performance-critical situations in general.

Re:I've always thought Meyers was wrong about MI..

[alienmole]

Scott said in the interview that the C++ community doesn't have a name for interface classes. Maybe not, but I've been using the term "pure abstract class" for close to a decade and I don't think I've come across a single marginally-competent C++ programmer who didn't immediately understand the term, and I'm pretty sure I picked the term up from comp.lang.c++.

In the interview, Scott exhibits amazing ignorance for an author of his supposed stature. As someone else pointed out, use of interfaces has been common in the Win32 world, with COM, for at least about eight years. Smalltalk has used implicit interfaces for decades, and that's where the Objective-C construct presumably came from.

Scott seems to have a very ad-hoc approach to programming - "I do it this way because it seems simpler and it works". That's fine, but if you're going to be writing about this stuff, you'd think you'd perhaps study it a bit, understand the formal underpinnings (type theory in this case), to be able to put your choices into a wider context - but he doesn't do this, unless he's playing dumb in the interview to avoid confusing the readership.

Basically, Scott seems to be a step above authors like Bruce Eckel, who write intro/overview "how to program in language X" books. One shouldn't be looking to him for insight into software design.

Re:I've always thought Meyers was wrong about MI..

[swillden]

Scott seems to have a very ad-hoc approach to programming - "I do it this way because it seems simpler and it works".

My take on his books has always been that they're intended to help novices avoid common pitfalls, rather than to provide insight for experienced developers. When they're considered from that point of view, I think they're valuable books, overall. With respect to a few specific topics, like MI, I disagree with his position even for novices.

As someone else pointed out, use of interfaces has been common in the Win32 world, with COM, for at least about eight years.

Hehe. That strikes me as a rather odd example, since COM is so much newer than all of the other technologies we're discussing, with the sole exception of Java, which was invented at about the same time as COM. But you're certainly correct that this idea isn't new.

Re:I've always thought Meyers was wrong about MI..

[swillden]

Ah, I see what you meant. That is a very good example, then. I only used the COM stuff when it was new, and it basically had to be done in C at that point (and was a huge pain). That experience drove me to get a job writing code for embedded systems -- as far away from MS as I could manage...

Of course, the mixin approach was described in the C++ context at least as far back as Booch's OO book.

Really? Wow, I've completely forgotten that. Next time I'm in the office I'll have to grab my copy and see what Booch had to say about it. I've been working at home for two years now, but I still have to cart a box full of stuff home every time I go to the office -- it's been a slow migration :-)

I would expect someone writing books about C++ to be aware of all this, but Scott's comments against MI never seemed to take any of this into account.

I fully agree with this sentiment. Although I think Booch's book came after Scott's first book, an author of C++ texts should definitely be familiar with all of the major literature (and, preferably, most of the minor literature as well).

Re:I've always thought Meyers was wrong about MI..

[swillden]

Afaict, Booch's 1st edition ('91) came out the year before Meyer's 1st edition of Effective C++ ('92). Not as big a gap as I remembered - I think I only came across Meyers a few years after that.

My confusion probably arose from the fact that I had Booch's book within a few weeks after it came out and didn't run across Meyer's book until about 1995.

Cool! No-one ever regretted avoiding Microsoft... ;) What kind of embedded systems?

I was working on boards that were pretty close to PCs, in terms of power, Motorola 68000 processors and, I believe 4MB of RAM and 4MB of flash. Initially they were running PSOS and the application (control system for routers of audio and video signals) had just been ported, more or less, to VxWorks when I got there. I've worked on a variety of Unix and embedded systems since and haven't really done any more "serious" Windows programming. And now I'm happily hacking on tiny machines running Linux, even though that means I'm mostly writing C.

It's all fun, actually, but I like to be able to have a little deeper understanding of what's going on and it always seemed that with Windows there was just too much stuff hidden from me. Linux is, of course, ideal in that respect. How much you understand is dependent on how much time you have to invest in learning, not on how much someone will allow you to learn.

Re:I've always thought Meyers was wrong about MI..

[Anonymous Coward]

There is a certain zen to MI. Much like there is the goto, programming in assembly, and programming in C. At first, young grasshopper you must study. Wax on, wax off. Once you master that then you may move on to crane kick, but not until the proper time.

I can list off 10,000 reasons why C shouldn't be used for much of anything. I have a masters in software engineering from SEI and I can list off dozens of real world fuckups that were caused or allowed because of the C language and costed millions of dollars and at times possibly even risked lives. Then you go out into the world and you will continually stumble into situation when you want portable assembly and there is no better than C. Would I write the code that controls the 767 in C? Not if I didn't have to. Would I write a huge GUI with hundreds of dialogs and controls in C? Not unless you were holding a weapon and threatening me. Now a kernel? A low level library? Something that talks to the metal? I don't know of anything better than C. Ada is nice at times, Forth is wonderful for certain tasks. C is amazing at most of it. You can see the opcodes that get produced as you write it, it's beautiful. Last embedded project I built from scratch we wrote enough assembly to get a CRT0 working and then enough C to get a JVM working and the rest was gravy.

I can wax the same way about gotos. I can point to pieces of code that a absolutely beautiful because they have gotos and couldn't be made as elegent without them. Drivers in the linux kernel use them from time to time. Mind you, most of this stuff is low level but that's what it's for. Tool for the job, you know? And it's beautiful when it works.

In the hands on a newbie it is a little frightening. I think of it like the table saw in shop class. It's the most deadly tool in the room, every shop teacher has personal stories to tell you about kids sawing fingers off and stuff. And without exception there will come a time when that's the tool that does the best job. Sure you could rip a 2x4 in to a 2x2 with a ban saw or even a jig saw but the table saw is the saw intended for that task and it will do it in seconds, perfectly. OOP exists because we think it's easier to model programs in the ways that we think, rather than the ways that computers need them; there is nothing you can build with OOP that you couldn't build with functional or imparitive programming only you might find it easier to do with OOP. So what happens when I can describe something with 2 concrete abstractions? You're saying I should use an abstract abstraction as an inermediate? Take a book, it is a phyiscal collection of bound and printed pages, it is also the collection of words on those pages and in programming land those are both concrete (the specific words are what make the book.) So what if I had a "CollectionOfOrderedWords" object and a "CollectionOfBoundPages" object, my book could be a child of both, specifically myBook might be the mapping between the words and the specific pages. As such I also want to treat it as both. The interface world requires that I actually treat it differently because I want to look at the words rather than the pages. What if I think that abstraction is easier to think about?

MI has it's problems. It's not the safest thing to use but it makes some things very easy. Particularly when you're building complex things rather than decomposing complex things, which seems to be the tendency among a lot of OOP programmers. If you're building a "final" object that won't be a component of anything else, MI is awesome.

Re:I've always thought Meyers was wrong about MI..

[swillden]

I've seen this in the Java world too - people working on top of open source server products are amazingly empowered, compared to those stuck with closed source application servers and tools. I think open source at various levels is a big reason behind the corporate success of Java, but one that's often not recognized.

And one of the nice things about Java, from my point of view, is that it's pretty hard to every *really* hide the source. There's so much information in Java bytecodes that decompilers are highly effective. I've even made custom modifications to supposedly "closed" code -- decompile, hack, recompile. It can also be very interesting to hack a class and rename it, then write your own class with the original class's name and interface that just wraps the original, giving you a chance to inspect and modify everything flowing into or out of objects of the original class. In fact, it occurs to me that you could probably write a little program to automate that -- use introspection to examine the original class and then automatically generate an instrumented wrapper that logs everything... hmmm....

Heck even just using javap to poke around the interfaces of classes that are not intended to be public can often tell you a whole lot about how the software works underneath.

You can do a lot of this stuff with object code, too, but you're disassembling, not decompiling and the difference is huge.

Re:I've always thought Meyers was wrong about MI..

[swillden]

The first C++ project (and most after) have involved designing extensibility by using a base class in an executable, and derived classes created in dynamically linked libraries. The point being the executable loads the library, links to a constructor function, calls it and is returned and object B which can be upcast to the base class A. This cannot be done if B is multiply inherited because the executable module does not know about that at compile time.

This has the potential to be a really, really interesting point, but I just don't think it's true. In fact, I'm fairly certain that I have done exactly what you say in the past. Even if my memory is faulty (it commonly is), I can't think of how the dynamic linking changes things. It seems like if this were a problem, it would be a problem with static linkage as well since the units are always compiled separately, and the linker doesn't rewrite the code.

Can you elaborate?

Re:I've always thought Meyers was wrong about MI..

[swillden]

I'm replying to myself because after a bit more thought, I can see how you structured things to make it problematic. The key is that you're doing the upcast from B to A in the executable which knows nothing about B (doesn't even know B's name), rather than in the shared library which would know how to perform the upcast properly.

I don't see that as a real limitation, for two reasons: First, there's a very simple fix -- just do the upcast in the library. Second, I'm pretty certain that what you did is not well-defined even with single inheritance. You're effectively doing something like:

A* a_ptr = reinterpret_cast<A*>(b_ptr);

... but in a more complex manner. Maybe writing it as:

void* tmp = b_ptr;
A* a_ptr = (A*)tmp;

... is closer to the actuality, but they're equivalent. Now while I think both of the above would "work", assuming single inheritance, in every C++ compiler I've used, I'm pretty certain that the language does not require that it work. That is, compiler writers are permitted to choose a class layout that requires a bit of work for an upcast even in the case of single inheritance, and unless the compiler can recognize the upcast and emit the appropriate code, the results will be... bad.

Regardless of the correctness issue, IMO it's cleaner to do the upcast in the library. I've always taken the additional step of writing a small wrapper that does the actual construction, and then placing that in the library with the class it instantiates. If you needed to be able to get a B as any of its bases (reasonable), you'd need a wrapper per base but, again, that doesn't seem like a terribly painful tradeoff for being able to (a) use MI and (b) be fairly certain that it will always work, even for SI.

If you wanted to be able to use placement new, you'd also need another version of each helper, plus a function to tell the caller how much space to allocate.

Please excuse me if I have completely misunderstood. If there's an issue I'm missing here, I'd very much like to understand it.

memory optimisation versus safe programming

[fingal]

And with 10,000 of those defined in your code, that's 10,000 instances of slightly-relabled Object to be constructed at startup and sit in RAM afterward, doing diddly-squat. A "public static final int CONST_FOO = 1" type definition meanwhile occupies precisely 4 bytes of space and takes no time to initialize.

Fair enough. Couple of points that I would bounce back at you though:-

• If you have 10,000 constants of any type inside a program design then I reckon that you are going to have larger problems than just your boot-up time.
• If you have to have these constants then compartmentalising them in some way into sections that can be loaded individually by the classloader (either on demand or in a background thread) will help the start-up time.
• Try running a decent java debugger / profiler like OptimizeIt and look at the number of "system" level Objects that are created. You may well find that the overhead of your 10,000 Objects is really not a major issue after all.
• The benefits in terms of enforced range checking that is provided with the private constructor / public final static instances in will generally pay dividends in the long run. I know that we are all good programmers and we always check the range of any integer constant, but what happens when this range changes in the future? Do you want to be responsible for checking through all the 3rd party code that utilises your constants to make sure that they handle the new values?

Re:I've always thought Meyers was wrong about MI..

[swillden]

Strictly speaking the compiler needs to know the parent and descended type to make this upcast (potentially, even without MI).

Absolutely, and this is the key. Unless you're doing something excessively clever, the compilation unit that performs the upcast will *always* know the derived typed, because, in general, it won't compile otherwise. With the COM example, you are essentially passing it through a cast to void* so that the executable can then convert it to a base* without having to know about the derived type at all.

And that cast via void* is not guaranteed to work, even with single inheritance. As you noticed 8 years ago, the authors of your compilers structured class memory layout in the obvious way and the cast worked. But if it hadn't, the compiler would not have been in error.

If you do this cast without knowing what the descended type really is, you are taking a pointer and just lying to the compiler what the memory print looks like.

Yep, and lying to the compiler is a dangerous business. It can be fun, though ;-)

The reason this isn't a problem, usually, with static libraries is merely that the compiler usually knows the descended type, and inserts code to do the conversion.

More precisely, the reason it isn't a problem with static libraries is that there's rarely, if ever, any good reason to pass a cast through a void*. In the case of dlopen/dlsym (or the Win32 equivalents, whose names I forget), you're constrained by this 3rd party API, and when you pass the pointer through that bottleneck, you lose knowledge of the derived type. Forgetting the derived type is cool, but you need to upcast before forgetting, not after.

I think in a multiparadigmed language it's inevitable that you will have to understand not only C++ but the C++ philosophy of a particular project.

This is absolutely true.

Playing games at the level of the binary layout of your strucutures is one of the things that makes people now say that C++ is too low level.

As you said, it's not the language's fault if you abuse it. The ability to do low-level work is important for a large class of programming problems, and the fact that you can (ab)use the same pointer manipulation tools that are needed for, say, device drivers, to subvert the higher-level type system is just an artifact of the language's breadth of applicability. It's up to the programmer to avoid doing silly things -- and the compiler will generally tell you if you are! I think it's adequate that C++ makes nasty, tricky code obviously nasty and tricky. It doesn't need to disallow it.

By way of comparison, I've been writing Javacard applets recently and it is a real pain in the neck. When you're writing code for an 8-bit microcontroller with 2K of RAM and 16K of storage, you *must* write code that is jealous of every byte. Doing this in Java is like trying to swordfight while hog-tied. I like Java well enough, but it really sucks for low-level work. C++ can do a wide range of jobs effectively; just don't blow your own leg off with it.