> While it is possible to create and use interfaces in C++,
> it is also possible to program in C++ for many years
> without ever being keenly aware of the interface concept.

Quite true. It is also possible to program in C++ for many years without ever being keenly aware of the RAII concept.

That doesn't seem to address whether or not it is a good idea. I certainly wouldn't object to having an "interface" concept in C++ that embodied the same concepts as an ABC. But the idea that it would be more accessible to novices does not, by itself, seem like sufficient justification.

I'm not pretending to know the answer, but I do think this is an interesting question:
Did people learn about interfaces because Java made interfaces a first-class language construct?
OR
Did Java make interfaces a first-class language construct because people learned about interfaces using ABC in C++?

> >... but if you believe in allowing
> > fuller multiple inheritance to be used then what value
> is
> > there in having a language feature that duplicates what
> is
> > possible through using another language feature?
>
> Is absolute minimalism the main driving force behind good
> language design? If that were the case, then why have
> while, do-while and for, among other
> things?

Absolute minimalism the main driving force? No.
Minimalisim a driving force? I think it should be.

If an explicit "interface" feature had real advantages (bearing in mind that we already have MI), then maybe it should be added. What are those real advantages?

> > The only possible advantage would be if the use of
> > multiple inheritance to do what Java interfaces do was
> so
> > convoluted as to be non-idiomatic. That simply isn't
> > true.
>
> Doing interfaces in C++ via ABCs seems very clunky
> compared to the Java interface. It is also more
> of a convention than a language construct; it is pretty
> easy to create almost-ABCs, either intentionally or
> accidentally.

Yes it's more of a convention than a language construct. What's wrong with that? I disagree that's it's clunky though.

I'd defend the ability to give an "interface" class a static member or static member function, or a convenience function defined in terms of the virtual functions:

class someInterface{
  //it's inherent in our concept of what "someInterface"
  //means that they can be compared and sorted.
  //hence we provide for this:

  virtual int cmp(const someInterface& rhs) = 0;

  //these need not be virtual:

  bool operator==(const someInterface& rhs)const
  {
    return cmp(rhs) == 0;
  }
  bool operator<(const someInterface& rhs)const
  {
    return cmp(rhs) < 0;
  }

  //all "someInterface"s can "process" an array of chars;
  //This isn't far removed from the characters method
  //on a SAX ContentHandler.

  virtual void process(const char* start, const char* end) const = 0;

  //often the user of someInterface has a string (indeed
  //that would be safer. Also, we define process in terms
  //of a sequence (first, last] but many people think of
  //arrays as defined in terms of an initial pointer and a
  //size (especially those who moved from C to C++:

  void process(const char* start, size_t size) const{
    process(start, start + size);
  }

  void process(const std::string& str) const{
    process(str.data(), str.length());
  }

  /*other functions yadda yadda*/
};

This isn't to say that you should always do this, and in my example the == and < operators seem a bit doubtful to me.

However if we wanted to overload process() in a similar manner using virtual functions then we force the simple implementation to be repeated in every class that implements this interface, we gain nothing except for more typing practice and a greater potential for bugs (it's also possible that we'll make things less efficient - my concern here wouldn't be so much efficiency as much as what some developers might do to try to avoid inefficiency).

> > Arguably Java's interfaces have taught some C++
> > programmers about this way of using MI...
>
> I don't really even think of the interface in Java
> as being multiple inheritance. It seems more like a
> language construct for objects to advertise what
> behaviors they support.

Inheritance advertises what behaviours a class supports! I think this is a much more important aspect of inheritance, particularly in design stages, than the fact that you can also inherit implementation (and hence program by difference).

> > ...but then so has
> > COM (which is defined almost entirely in terms of
> > interfaces which is most naturally implemented in C++
> > using MI - though there are other ways, but then there
> are
> > always "other ways").
>
> COM is even clunkier than pure C++! The salient point
> is that the interface in Java is a very clean and
> simple thing. Yes, COM is built up around interfaces,
> but COM itself is such a huge complicated, crufty mess,
> that it is nearly impossible to see the proverbial
> forest.

Of course COM is clunkier than pure C++, it was an API designed to share objects between a variety of languages - including some with no concept of OO at all - on a variety of operating systems. That's an inherently clunky problem.

> > Even so a language feature shouldn't exist to teach
> you
> > how to use another language feature.
>
>
> Why not?!? What's wrong with language features that
> help you learn how to be a better programmer? A language
> feature that does this will probably be more effective at
> improving programmers than any number of books, articles,
> mentors or courses.

Oh, every language feature should teach you how to be a better programmer - it should encourage good programming and discourage bad programming (I love how awkward the new C++ casts are, a little rap across the knuckles every time you cast something). But it should also stand on it's own, otherwise it stops being a good way to learn and becomes "another thing to learn".
In Java Interface both teaches the technique and stands on it's own. If added to C++ it would only do the former.

Looking at it another way, do we need a language feature for everything a programmer should learn?

> The presence of the interface keyword in Java has
> taught more programmers this concept than anything else,
> probably. While it is possible to create and use
> interfaces in C++, it is also possible to program in C++
> for many years without ever being keenly aware of the
> interface concept.

It's possible to program in C++ without being keenly aware of the class concept (every example of C in K&R is valid C++).

This cuts both ways, C++ adapts to new paradigms well (I think C++ deserves a lot of credit from the way OO has progressed from the earlier definitions - as mentioned by Dave above) and this is partly because it doesn't force much upon the user, but as well as working well with good paradigms and design strategies it will give results to people using dain bramaged paradigms and poor design strategies (not great results, but good enough results that the programmer may continue with a poor methodology for longer than otherwise).

This isn't a feature that is a requirement of a language, but I'm glad there is a major language that has it to such a large extent.

I expect you're quite right that there's nothing you can do in Java to improve the situation.

But here is an interesting trick that C# uses to allow limited RAII. It's far from automatic, but it's certainly better than the situation in Java & other .NET languages.

using( MyObject o = new MyObject() )
{
... do stuff with o
}

The "using" keyword only works if MyObject implements the IDisposable interface. The IDisposable.Dispose method implementation can do the cleanup for MyObject.

Dispose will be called at the end of the "using" block, whether it leaves by exception or any other mechanism.

I prefer deterministic destruction like C++ has, but this is a nice attempt to bring RAII to garbage-collected languages.

>Providing "the most useful special case (only)" can stiffle programmers after the initial advantage.

I agree with this and I really enjoy solving problems with c++ compared to other languages.

The one possible downside that I see is that when you set your programmers free, they run in different directions. C++ code varies, I find, more than Java and C# code. This is partly because they are young languages but there seems to be more consensus of what the notation should be etc.
With C++, the way you use libraries varies much more, creating a (less steep) learning curve every time you're introduced to a new library. Take the Spirit library (which I think is absolutely fabulous, by the way. See http://www.boost.org/libs/spirit/). It effectively defines its own syntax and nobody would be able to use it out-of-the-box.
You could argue that nobody would be able to even if it was defined using conventional function calls and this is true. But in general, I think that learning new libraries is more difficult due to the potential complexity of c++.