Simple question
Tips on how to memorize the c++ language?
I want to memorize it like fluently as talking in English.
I want to memorize it like fluently as talking in English.
Read code, write code = memorize code...
When you first look at code, it looks frustrating. It gets easier as you write it & study it.
When you first look at code, it looks frustrating. It gets easier as you write it & study it.
As they said, practice with it. Make sure you're solid in the basics before moving to bigger and scarier things, because the basics can really come and bite you in the bum later on.
As well, it's "I want to memorize it as fluently as talking in English."
Oh, the irony.
As well, it's "I want to memorize it as fluently as talking in English."
Oh, the irony.
Just keep programming. The more you program the more natural the code will come until you'll recognize the syntax on your own.
To continue the metaphor,
There are two parts to learning a spoken language: the syntax and the words.
You can know every English word in the dictionary, but if you don't know how
to make a sentence, you still can't speak English (and vice versa of course).
In programming, things like "how to sort an array of X using <insert-favorite-sort-here>" and
"how to dynamically allocate a 2-D array of Y" are simply words. Syntax in programming has
two forms: the first is the proper definition of syntax. For example, to declare a free function,
it is: return-type function-name ( parameter-list ) Beginners should focus first on this form.
The second form is more design patterns and higher-level techniques. For example, what is
CRTP, and how/when can I use it? How can I write code that is more maintainable? What
are initializer lists, and why should I use them? What are value semantics, why do people
think they're so good, and how can I design my software to use it? These and many, many
other concepts are much higher level and more abstract and should be focused on after you
are comfortable with the basic syntax. You'll find as you are programming things that you don't
like about the design. Maybe you are duplicating code and don't know how to eliminate it.
Maybe you are making endless expensive copies of objects and don't know how to reduce
the number of copies. Something about the design will stick out. This is where the second
form comes in. Now you research the problem -- see if someone else had a similar problem
and how they fixed it. (Your typical programmer approaches learning like this: I want to
learn X, Y, and Z, so I'm going to write this here program to help me learn these concepts.
It doesn't really work that way. Maybe the concepts are a good fit; maybe they aren't.
Rather, I like to start a project that I want to do and discover what it teaches me later).
Remember: a good programmer never stops learning, particularly the second form above.
There is always something you could do differently, something you could do to make the design
better or the code more maintainable or more efficient.
There are two parts to learning a spoken language: the syntax and the words.
You can know every English word in the dictionary, but if you don't know how
to make a sentence, you still can't speak English (and vice versa of course).
In programming, things like "how to sort an array of X using <insert-favorite-sort-here>" and
"how to dynamically allocate a 2-D array of Y" are simply words. Syntax in programming has
two forms: the first is the proper definition of syntax. For example, to declare a free function,
it is: return-type function-name ( parameter-list ) Beginners should focus first on this form.
The second form is more design patterns and higher-level techniques. For example, what is
CRTP, and how/when can I use it? How can I write code that is more maintainable? What
are initializer lists, and why should I use them? What are value semantics, why do people
think they're so good, and how can I design my software to use it? These and many, many
other concepts are much higher level and more abstract and should be focused on after you
are comfortable with the basic syntax. You'll find as you are programming things that you don't
like about the design. Maybe you are duplicating code and don't know how to eliminate it.
Maybe you are making endless expensive copies of objects and don't know how to reduce
the number of copies. Something about the design will stick out. This is where the second
form comes in. Now you research the problem -- see if someone else had a similar problem
and how they fixed it. (Your typical programmer approaches learning like this: I want to
learn X, Y, and Z, so I'm going to write this here program to help me learn these concepts.
It doesn't really work that way. Maybe the concepts are a good fit; maybe they aren't.
Rather, I like to start a project that I want to do and discover what it teaches me later).
Remember: a good programmer never stops learning, particularly the second form above.
There is always something you could do differently, something you could do to make the design
better or the code more maintainable or more efficient.
I recommend reading on the subject, as well. Years and years of insightful findings and realizations can be summarized and practically handed to you--all you have to do is read it.
| Oh, the irony. |
It's not ironic because he only wrote it. It would only be ironic if he had said it out loud.
closed account (jy8CpfjN)
just like time table chart recite, and make sure to keep around with ur books.
| It's not ironic because he only wrote it. It would only be ironic if he had said it out loud. |
Touché.
Topic archived. No new replies allowed.