Depends what's meant by "object". In the usual
language-independent meaning of "object" you're right.
However, the standard defines an object as a region of memory,
and goes to pains to specify "class type" whenever it talks
about objects of class type, so as not to confuse them with
objects of non-class type, and in that meaning malloc &
friends allocate objects (although I agree that's probably not
what OP means).
Yes, but even a POD is more than just raw memory, at least if it
has a readable value. Using calloc, you're guaranteed that any
subobjects of integral type have a value of 0, but that's about
it. You still have to initialize pointers and floating point
values before you can access them.
Now, C++ "new" combines two operations: allocation and
initialization, where initialization might involve internally
calling a constructor for each class type object created. You
get either both effects, or none. I.e., if initialization
fails, the allocated memory is deallocated again,
automatically.
Most importantly, initialization takes place. Conceptually (in
my mind, at least), there is a difference between raw memory,
and an object, even if that object is of type int. With
calloc/malloc (and the operator new function), you get raw
memory; with new, you get the object. If the constructor is a
no-op (a trivial constructor), of course, there is no real
difference physically, but I still find it cleaner to think of
it as two different things.
And it has one more useful property, namely that the
corresponding destruction+deallocation operation, C++
"delete", is the operation used by default by automatic
cleanup such as with boost::shared_ptr.
It's the only operation used by most automatic cleanup. (It's
what std::auto_ptr uses, for example.) Except
that which works at a much lower level (e.g. garbage
collection).
The important point, of course, is that if you use calloc, you
must use free (and not delete), and if you use new, you must use
delete. Unless you're using some lower level system which more
or less "pirates" them all.
Implementing all that yourself on top of e.g. malloc would be
very much work for no particular gain, since it's unlikely in
the extreme that you'd be able to achieve the same quality.
It's useful when you want to separate initialization and
allocation, e.g. when implementing something like vector.
Today, of course, unless you're implementing the standard
library, the probability of needing to do this is very, very
small, but back in the old days, when the "standard library" was
iostream, complex, and nothing else, it was standard practice
anytime you implemented your in house vector classes.
Even then, I would use the operator new function, rather than
malloc. I reserve malloc for the implementation of custom
operator new functions (e.g. for debugging---although now that
tools like valgrind are readily available for free, there's
practically no reason to write a debugging operator new anymore
either).
Hence the only reason for using malloc & the like in C++, is
where you need to interface to code that requires this, e.g.
by calling free.
In which case, you have no choice. When you have to, you have
to. Similarly, it's the easiest way (and the only portable way)
to get memory if you're implementing your own replacement global
operator new.