Because what would that object have for functionality? In java all the Base class has is a toString, a hashCode & equality and a monitor+condition variable.

• ToString is only useful for debugging.

• hashCode is only useful if you want to store it in a hash-based collection (the preference in C++ is to pass a hashing function to the container as template param or to avoid std::unordered_* altogether and instead use std::vector and plain unordered lists).

• equality without a base object can be helped at compile time, if they don’t have the same type then they cannot be equal. In C++ this is a compile time error.

• the monitor and condition variable is better included explicitly in a case by case basis.

However when there is more that it needs to do then there is a use-case.

For example in QT there is the root QObject class which forms the basis of thread affinity, parent-child ownership hierarchy and signal slots mechanism. It also forces use by pointer for QObjects, However many Classes in Qt don’t inherit QObject because they have no need for the signal-slot (particularly the value types of some description).

Because there are no functions shared by all objects. There’s nothing to put in this interface that would make sense for all classes.

Whenever you build tall inheritance hierarchies of objects you tend to run into the problem of the Fragile Base Class (Wikipedia.).

Having many small separate (distinct, isolated) inheritance hierarchies reduces the chances of running into this problem.

Making all of your objects part of a single humongous inheritance hierarchy practically guarantees that you are going to run into this problem.

Because:

1. You shouldn’t pay for what you don’t use.
2. These functions make less sense in a value-based type system than in a reference-based type system.

Implementing any sort of virtual function introduces a virtual-table, which requires per-object space overhead that is neither necessary nor desired in many (most?) situations.

Implementing toString nonvirtually would be pretty useless, because the only thing it could return is the object’s address, which is very user-unfriendly, and which the caller already has access to, unlike in Java.
Similarly, a nonvirtual equals or hashCode could only use addresses to compare objects, which is again pretty useless and often even outright wrong — unlike in Java, objects are copied frequently in C++, and hence distinguishing the “identity” of an object isn’t even always meaningful or useful. (e.g. an int really should not have an identity other than its value… two integers of the same value should be equal.)

Having one root object limits what you can do and what the compiler can do, without much payoff.

A common root class makes it possible to create containers-of-anything and extract what they are with a dynamic_cast, but if you need containers-of-anything then something akin to boost::any can do it without a common root class. And boost::any also supports primitives — it can even support the small buffer optimization and leave them almost “unboxed” in Java parlance.

C++ supports and thrives on value types. Both literals, and programmer written value types. C++ containers efficiently store, sort, hash, consume and produce value types.

Inheritance, especially the kind of monolithic inheritance Java style base classes imply, requires free-store based “pointer” or “reference” types. Your handle/pointer/reference to data holds a pointer to the interface of the class, and polymorphically could represent something else.

While this is useful in some situations, once you have married yourself to the pattern with a “common base class”, you have locked your entire code base into the cost and baggage of this pattern, even when it isn’t useful.

Almost always you know more about a type than “it is an object” at either the calling site, or in the code that uses it.

If the function is simple, writing the function as a template gives you duck-type compile time based polymorphism where information at the calling site is not thrown away. If the function is more complex, type erasure can be done whereby the uniform operations on the type you want to perform (say, serialization and deserialization) can be built and stored (at compile time) to be consumed (at run time) by the code in a different translation unit.

Suppose you have some library where you want everything to be serializable. One approach is to have a base class:

struct serialization_friendly {
  virtual void write_to( my_buffer* ) const = 0;
  virtual void read_from( my_buffer const* ) = 0;
  virtual ~serialization_friendly() {}
};

Now every bit of code you write can be serialization_friendly.

void serialize( my_buffer* b, serialization_friendly const* x ) {
  if (x) x->write_to(b);
}

Except not a std::vector, so now you need to write every container. And not those integers you got from that bignum library. And not that type you wrote that you didn’t think needed serialization. And not a tuple, or an int or a double, or a std::ptrdiff_t.

We take another approach:

void write_to( my_buffer* b, int x ) {
  b->write_integer(x);
}    
template<class T,
  class=std::enable_if_t< void_t<
    std::declval<T const*>()->write_to( std::declval<my_buffer*>()
  > >
>
void write_to( my_buffer* b, T const* x ) {
  if (x) x->write_to(b);
}
template<class T>
void serialize( my_buffer* b, T const& t ) {
  write_to( b, t );
}

which consists of, well, doing nothing, seemingly. Except now we can extend write_to by overriding write_to as a free function in the namespace of a type or a method in the type.

We can even write a bit of type erasure code:

namespace details {
  struct can_serialize_pimpl {
    virtual void write_to( my_buffer* ) const = 0;
    virtual void read_from( my_buffer const* ) = 0;
    virtual ~can_serialize_pimpl() {}
  };
}
struct can_serialize {
  void write_to( my_buffer* b ) const { pImpl->write_to(b); }
  void read_from( my_buffer const* b ) { pImpl->read_from(b); }
  std::unique_ptr<details::can_serialize_pimpl> pImpl;
  template<class T> can_serialize(T&&);
};
namespace details { 
  template<class T>
  struct can_serialize : can_serialize_pimpl {
    std::decay_t<T>* t;
    void write_to( my_buffer*b ) const final override {
      serialize( b, std::forward<T>(*t) );
    }
    void read_from( my_buffer const* ) final override {
      deserialize( b, std::forward<T>(*t) );
    }
    can_serialize(T&& in):t(&in) {}
  };
}
template<class T> can_serialize::can_serialize<T>(T&&t):pImpl(
  std::make_unique<details::can_serialize<T>>( std::forward<T>(t) );
) {}

and now we can take an arbitrary type and auto-box it into a can_serialize interface that lets you invoke serialize at a later point through a virtual interface.

So:

void writer_thingy( can_serialize s );

is a function that takes anything that can serialize, instead of

void writer_thingy( serialization_friendly const* s );

and the first, unlike the second, it can handle int, std::vector<std::vector<Bob>> automatically.

It didn’t take much to write it, especially because this kind of thing is something you only rarely want to do, but we gained the ability to treat anything as serializable without requiring a base type.

What more, we can now make std::vector<T> serializable as a first-class citizen by simply overriding write_to( my_buffer*, std::vector<T> const& ) — with that overload, it can be passed to a can_serialize and the serializabilty of the std::vector gets stored in a vtable and accessed by .write_to.

In short, C++ is powerful enough that you can implement the advantages of a single base class on-the-fly when required, without having to pay the price of a forced inheritance hierarchy when not required. And the times when the single base (faked or not) is required is reasonably rare.

When types are actually their identity, and you know what they are, optimization opportunities abound. Data is stored locally and contiguously (which is highly important for cache friendliness on modern processors), compilers can easily understand what a given operation does (instead of having an opaque virtual method pointer it has to jump over, on leading to unknown code on the other side) which lets instructions be optimally reordered, and fewer round pegs are hammered into round holes.

There are many good answers above, and the clear fact that anything you would do with a base-class-of-all-objects can be done better in other ways as shown by @ratchetfreak’s answer and the comments on it is very important, but there is another reason, which is to avoid creating inheritance diamonds when multiple inheritance is used. If you had any functionality in a universal base class, as soon as you started using multiple inheritance you’d have to start specifying which variant of it you wanted to access, because it could be overloaded differently in different paths of the inheritance chain. And the base can’t be virtual, because this would be very inefficient (requiring all objects to have a virtual table at a potentially enormous cost in memory usage and locality). This would become a logistical nightmare very quickly.

In fact Microsofts early C++ compilers and libraries (I know about Visual C++, 16 bit) had such a class named CObject.

However you have to know that at that time “templates” were not supported by this simple C++ compiler so classes like std::vector<class T> were not possible. Instead a “vector” implementation could only handle one type of class so there was a class that is comparable to std::vector<CObject> today. Because CObject was the base class of nearly all classes (unfortunately not of CString – the equivalent of string in modern compilers) you could use this class for storing nearly all kinds of objects.

Because modern compilers support templates this use case of a “generic base class” is no longer given.

You have to think about the fact that using such a generic base class will cost (a little) memory and runtime – for example in the call to the constructor. So there are drawbacks when using such a class but at least when using modern C++ compilers there is nearly no use case for such a class.

I’m going to suggest another reason that comes from Java.

Because you can’t create a base-class for everything at least not without a
bunch of boiler-plate.

You may be able get away with it for your own classes – but you’ll probably find that you end up duplicating a lot of code. E.g. “I can’t use std::vector here since it doesn’t implement IObject – I’d better create a new derived IVectorObject that does the right thing…”.

This will be the case whenever you’re dealing with built-ins or standard library classes or classes from other libraries.

Now if it was built into the language you’d end up with things like the Integer and int confusion that is in java, or a large change to the language syntax. (Mind you I think some other languages have done a nice job with building it into every type – ruby seems like a better example.)

Also note that if your base class is not run-time polymorphic (i.e. using virtual functions) you could get the same benefit from using a traits like framework.

e.g. instead of .toString() you could have the following:
(NOTE: I know you can do this neater using existing libraries etc, its just an illustrative example.)

template<typename T>
struct ToStringTrait;

template<typename T> 
std::string toString(const T & t) {
  return ToStringTrait<T>::toString(t);
}

template<>
struct ToStringTrait<int> {
  std::string toString(int v) {
    return itoa(v);
  }
}

template<typename T>
struct ToStringTrait<std::vector<T>> {
  std::string toString(const std::vector<T> &v) {
    std::stringstream ss;
    ss<<"{";
    for(int i=0; i<v.size(); ++i) {
      ss<<toString(v[i]);
    }
    ss<<"}";
    return ss.str();
  }
}

Arguably “void” fulfils a lot of the roles of a universal base class. You can cast any pointer to a void*. You can then compare those pointers. You can static_cast back to the original class.

However what you can’t do with void which you can do with Object is use RTTI to figure out what type of object you really have. This is ultimately down to how not all objects in C++ have RTTI, and indeed it’s possible to have zero-width objects.

Java takes the design philosophy that Undefined Behavior should not exist. Code such as:

Cat felix = GetCat();
Woofer Rover = (Woofer)felix;
Rover.woof();

will test whether felix holds a subtype of Cat that implements interface Woofer; if it does, it will perform the cast and invoke woof() and if it doesn’t, it will throw an exception. The behavior of the code is fully defined whether felix implements Woofer or not.

C++ takes the philosophy that if a program shouldn’t attempt some operation, it shouldn’t matter what the generated code would do if that operation were attempted, and the computer shouldn’t waste time trying to constrain behavior in cases that “should” never arise. In C++, adding the appropriate indirection operators so as to cast a *Cat to a *Woofer, the code would yield defined behavior when the cast is legitimate, but Undefined Behavior when it is not.

Having a common base type for things makes it possible to validate casts among derivatives of that base type, and also to do try-cast operations, but validating casts is more expensive than simply assuming that they’re legitimate and hoping nothing bad happens. The C++ philosophy would be that such validation requires “paying for something you [usually] don’t need”.

Another problem which relates to C++, but wouldn’t be a problem for a new language, is that if several programmers each create a common base, derive their own classes from that, and write code to work with things of that common base class, such code will be unable to work with objects developed by programmers who used a different base class. If a new language requires that all heap objects have a common header format, and has never allowed heap objects which didn’t, then a method which requires a reference to a heap object with such a header will accept a reference to any heap object anyone could ever create.

Personally, I think that having a common means of asking an object “are you convertible to type X” is a very important feature in a language/framework, but if such a feature isn’t built into a language from the start it’s difficult to add it later. Personally, I think such a base class should be added to a standard library at first opportunity, with a strong recommendation that all objects that will be used polymorphically should inherit from that base. Having programmers each implement their own “base types” would make passing objects between different people’s code more difficult, but having a common base type which many programmers inherited from would make it easier.

ADDENDUM

Using templates, it’s possible to define an “arbitrary object holder” and ask it about the type of the object contained therein; the Boost package contains such a thing called any. Thus, even though the C++ doesn’t have a standard “type-checkable reference to anything” type, it’s possible to create one. This doesn’t solve the aformentioned problem with not having something in the language standard, i.e. incompatibility between different programmers’ implementations, but it does explain how C++ gets by without having a base type from which everything is derived: by making it possible to create something that acts like one.

Symbian C++ did in fact have a universal base class, CBase, for all objects that behaved in a particular way (mainly if they alloc’d heap). It provided a virtual destructor, zeroed the memory of the class on construction, and hid the copy constructor.

The rationale behind was it was a language for embedded systems and C++ compilers and specs were really really shit 10 years ago.

Not all classes inherited from this, only some.