It depends on the platform and implementation.

C++ guarantees that the size of char is exactly one byte and at least 8 bits wide. Then, size of a short int is at least 16 bits and not smaller than char. Size of an int is at least as big as size of short int. Size of long int is at least 32 bits and not smaller than int.

sizeof(char) == 1; sizeof(long int) >= sizeof(int) >= sizeof(short int) >= sizeof(bool) >= sizeof(char).

The actual memory model of C++ is very compact and predictable though. For example there is no metadata in objects, arrays or pointers. Structures and classes are contiguous just like arrays are, but padding may be placed where necessary and needed.

Frankly though, such comparison is silly at best as the Java memory usage depends more on the Java implementation than on the code it runs.

Most the answers seem to be ignoring a couple of fairly major points.

First, in an awful lot of Java, you virtually never see a raw int — nearly all use is of Integer, so the fact that an int could be (about) the same size as an int in C or C++ is almost irrelevant, except for that (in my experience, small) percentage of code that only uses int instead of Integer.

Second, the sizes of individual objects has almost nothing to do with the memory footprint of a program as a whole. In Java, the memory footprint of the program relates primarily to how the garbage collector has been tuned. In most cases, the GC is tuned to maximize speed, which (largely) means running the GC as infrequently as possible.

I don’t have a link handy at the moment, but there have been some tests showing that Java can run around the same speed as C, but to do so you have to run the GC rarely enough that it uses around 7 times as much memory. That’s not because individual objects are 7 times as big, but because GC can get pretty expensive if you do it too often. Worse, GC can only release memory when it can “prove” that there’s no longer any way to access an object, rather than simply when you know you’re done using it. This means that even if you run the GC a lot more often to minimize memory usage, you can probably still plan on a typical program have a memory footprint that’s larger. In a case like this, you might reduce the factor to 2 or 3 instead of 7. Even if you go drastically overboard, however, don’t expect the two to be within, say, 10 or 20% of the same memory usage, even if the number and size of objects you’ve allocated are both identical¹.

Depending on the situation, there’s another factor that may or may not be significant: the memory occupied by the JVM itself. This is more or less fixed, so as a percentage it may be huge if the app doesn’t need much storage of its own, or it may be minuscule if the app needs to store a lot. At least on my machine, even the most trivial Java app seems to occupy something like 20-25 megabytes (could be over 1000x for trivlal programs, or almost immeasurably tiny for big ones).

¹ That’s not to say that nobody could possibly manage to write Java with a footprint that close to what you’d get with C++. It’s only to say that just having the same number/size of objects, and running the GC really frequently won’t get you there as a rule.

I hope you realize that all of this is deeply implementation-defined, both for Java and C++. That being said, Java’s object model requires quite a bit of space.

C++ objects do not (generally) need any storage except what the members need. Note that (unlike Java, where everything user-defined is a reference type), client code can use an objects both as value type or as reference types, i.e. an object could store a pointer/reference to another object, or store the object directly without indirection. One additional pointer per object is necessary if there are any virtual methods, but quite a few useful classes are designed to get along without polymorphism and don’t need this. There is no GC metadata and no per-object lock. Thus class IntWrapper { int x; public: IntWrapper(int); ... }; objects need no more space than plain ints, and can be placed directly (i.e. without indirection) in collections and other objects.

Arrays are tricky simply because there is no pre-made, common equivalent to a Java Array in C++. You could simply allocate a bunch of objects with new[] (with absolutely no overhead/metadata) but there’s no length field — the implementation probably stores one but you can’t access it. std::vector is a dynamic array and thus has additional overhead and a larger interface. std::array and C-style arrays (int arr[N];), need a compile-time constant. In theory, it should be just the object’s storage plus a single integer for the length — but since you can get dynamic resizing and a fully-featured interface with very little extra space, you just go for that in practice. Note that all these, as well as all other collections, default to storing the objects by value, thus saving you indirection and the space for references, and improving cache behavior. You must explicitly store pointers (smart ones, please) to get indirection.

The above comparisons is not entirely fair, because some of these savings are afforded by not including features Java includes, and their C++ equivalent is often less optimized than the Java equivalent (*). The common way to implement virtual in C++ imposes exactly as much overhead as the common way to implement virtual in Java. To get a lock, you need a fully-features mutex object, which is most likely larger than a few bits. To get reference counting (not equivalent to GC, and shouldn’t be used as such, but sometimes useful), you need a smart pointer which adds a reference count field. Unless the object is constructed carefully, reference count, smart pointer object, and referenced object are in completely separate locations, and even when you construct it right, the shared pointer may (must?) still be two pointers instead of one. Then again, good C++ style does not use these features enough for it to matter — in practice, a well-written C++ library’s objects use less. That does not necessarily mean less memory usage overall, but it does mean C++ has a good head start in this regard.

(*) For instance, you can get virtual calls, identity hash codes and locking with only one word for some objects (and two words for many other objects) by merging the type information with various flags, and removing lock bits for objects that are unlikely to need locks. See Space- and Time-Efficient Implementation of the Java Object Model (PDF) by David F. Bacon, Stephen J. Fink, and David Grove for a detailed explanation of this and other optimizations.

A plain int, in java, takes exactly as much space as an int in C++, provided that both implementations use the same integer size and memory alignment.

An int ‘object’ (a boxed integer, that is, an instance of class Integer), carries all the overhead of a class instance in Java, so it is significantly larger than an int in C++. However, if you were to equip an object in C++ with the same features that Java objects come with out-of-the-box (polymorphism, boxing, garbage collection, RTTI), then you’d probably end up with an object of equal size.

And then there are optimization considerations; since the execution models and programming paradigms differ, it is unlikely that any non-trivial problem would be solved the same in both languages, so comparing storage size on this level doesn’t make an incredible lot of sense.

Yes, Java objects carry more overhead by default than C++ classes, but they come with more features, and this leads to a different programming style – a good programmer can leverage the up- and downsides of either language.