<p>for every C/C++ Beginner</p>
<p>Step 1 - add *</p>
<p>Step 2 - add &</p>
<p>Step 3 - switch place for & and *</p>
<p>Step 4 - Add in a second *</p>
<p>Step 5 - look up pointers online</p>
<p>Step 6 - delete all the pointers</p>
<p>Step 7 - go look at that code that worked right once</p>
<p>Step 8 - look up videos to explain pointers</p>
<p>Step 9 - delete all the *'s and &'s</p>
<p>Step 10 - add *</p>
<p>original post link: <a href="https://www.reddit.com/r/ProgrammerHumor/comments/7k9ft4/every_cc_beginner/" rel="nofollow">https://www.reddit.com/r/ProgrammerHumor/comments/7k9ft4/every_cc_beginner/</a></p>
<hr/>**评论：**<br/><br/>Sythe2o0: <pre><p>The joke doesn't really work as well in my experience, as focus on good error messages has improved since C/C++.</p></pre>twizmwazin: <pre><p>I disliked the <a href="/r/ProgrammerHumor" rel="nofollow">r/ProgrammerHumor</a> post. Honestly, understanding pointers only takes a couple of minutes, and anyone who is a career programmer should be able to explain them, along with other memory-management basics easily.</p>
<p>With that said, newer languages like Go tend to look at what struggles programmers have had with past languages, and try to remedy those issues.</p></pre>jerf: <pre><p>Language communities form their own terminology, so Go has "pointers", because that's what the Go standard says. I don't fight community's terminology because that's an uphill battle.</p>
<p>But as I know quite a few languages, I also have a sort of generalized terminology I use. Nobody else uses it, because the vast majority of programmers seem to find one community they like and then mistake their chosen community's vocabulary as the One True Computer Science Vocabulary. But in my personal terminology that I use in my head, the difference between a Pointer and a Reference is that you can do arithmetic on a pointer. That is the key attribute that makes them so hard to understand, and such a security and quality catastrophe.</p>
<p>In my terminology, what Go has are only <em>references</em>. You can pass a "reference" to a function, but it isn't allowed (modulo <code>unsafe</code>) to then start rooting around in memory with that pointer; it can only get at the referenced object. This is much easier to deal with. You'll also find that because of this, it is fairly rare in Go to have a double-pointer, since in C/C++ the double pointer is usually so a function can perform pointer arithmetic on the referenced pointer, and I've never seen or written a triple pointer in Go, whereas you will definitely encounter them in C. (C++, it depends on how "idiomatic" it is; idiomatic modern C++ has little use for a triple pointer (at least, one that is user-visible as a literal <code>***</code> in the type system), but older code may have it, and you may always have some crazy guy doing crazy things in the system "because it's faster than STL" or something.)</p>
<p>Consequently, no, there really isn't an equivalent in Go, because Go pointers lack the essential elements of complexity that confuse people in C/C++.</p>
<p>(You don't have to use my personal terminology, or even think it's got a hold of the correct/best distinction... but you <em>should</em> understand that "C pointers" and "Go pointers" are very different beasts.)</p></pre>vorg: <pre><p>Go pointer syntax is more confusing than in C/C++ because of Go's decision to adopt "C statements but Pascal declarations" without changing the unary symbols used. When we read</p>
<pre><code>*A //pointer to type A
*a //that pointed to by variable a
&a //pointer to variable a
</code></pre>
<p>whenever we see a unary <code>*</code>, we must ask ourselves whether what follows is a variable or type. If it's a type, <code>*</code> means "pointer to", otherwise it means the opposite, i.e. "that pointed to by".</p>
<p>Perhaps Go should have used <code>&</code> instead of <code>*</code> in type declarations, i.e.</p>
<pre><code>&A //pointer to type A
</code></pre>
<p>to be more consistent and thus readable for newcomers. But it's too late to change it now.</p></pre>
