Sherlock, if we were going to allocate an object on the heap, what would that look like?

Gasp! That looks like Java!

Sure does!! I'd say

Cow buttercup = new Cow(5, 3);

No! Tell me! Telll mmeeeeeee!

I know!! Because in Java, every object is allocated on the heap and every variable that refers to an object is a pointer variable!!!

Whoa…

A NullPointerException? Oh. My. Dog.

I'm so embarrased about that exception name. We'd been so good about pretending there weren't any pointers by just calling them “references” everywhere instead to help everyone be chill with so many pointers, uh, indirections, and then we had to go and name an exception after a pointer. We forgot just one time and it's been haunting us ever since. I blame a late night and too much… uh… cake, yeah, that's it.

Java default-initializes all pointers to be null precisely so it can know to raise this exception if you haven't assigned a valid address.

Sure, it just gives you some gobbledygook.

Yeah, exactly. The part before the @ is the class name, but after that it's just some garbage.

That can't be a number! It has letters in it!!

So that number (0x458ad742) is actually (2 × 1) + (4 × 16) + (7 × 16²) + (13 × 16³) + (10 × 16⁴) + (8 × 16⁵) + (5 × 16⁶) + (4 × 16⁷).

It's 1,166,726,978!

No, no. It can't be!

I'm dead. I'm literally dead. This killed me.

Maybe a jolt of caffeine will help bring you back to life? And like, pointers are cool, even if I'm a bit ashamed of them and try to hide them sometimes.

In Java, every object is on the heap!! And you always interact with objects through a pointer!!!

Which can explain a lot!

Because that C++ code declares an object on the stack and Java doesn't let you do that!

Because one is for objects and one is for pointers to objects.

Java only has pointers to objects, so Java only needs one member-access operator (we chose the dot operator).

This is incredible! (I'm okay!)

But all that choice makes C++ more complicated. In Java, we like to have some mental space to think about things like factory factories and abstract factories and factories that make factories that make factories, and so on. But in C++, you can just put a Cow in a Barn and be done with it!

Talking about being needlessly complicated, what's up with initializer lists?

Remember from the data lifecycle lesson: We can't use a variable until it has been initialized!

In C++ it's possible for an object to “contain” an object; like a Barn containing a Cow (rather than containing a pointer to a Cow).

All of that happens before we start running the code (inside the braces) in Barn's constructor! Otherwise, we'd start the body with some garbage memory where the Cow object is supposed to be and we couldn't expect any of the Cow methods (including assignment!) to work properly in that scenario.

We need to give parameters to the Cow constructor before we enter the constructor for Barn.

I kind of, sort of get it. I think.

You can really see the design philosophies of these languages in play here. C++ focuses on programmer choice and minimal overhead: put objects wherever you want them and only use pointers when you need to.

Both philosophies are important and valid! There are lots of programming languages because there are lots of different problems and lots of different programmers!

In reality, whenever language designers try to make a language “simpler” to be easier to use, programmers themselves just make it all more complicated again by building more and more complex libraries or coding idioms on top of it. So real-world coding in just about any language is going to get complicated somewhere along the way. Each language ends up with its own internal culture that is a reflection of the language's design philosophy and the kinds of problems it's used to solve, but may be tricky to learn for newcomers.