Namespaces
Variants
Actions

Talk:intro/variables

From cppreference.com

Give good example first, then separate declaration/initialization?

My preference when teaching a new concept in a book is to just dump the "correct" way on the reader first, and break it down later, rather than building up to the correct way through dangerous half-steps. In other words, maybe it would be better to start the section with "here is how you create a variable in C++: int x = 10;" (or maybe even better in C++11, "int x = {};"), then perhaps much later (after talking about int and what's happening re allocation) say "by the way, you can declare without initializing", and say it's dangerous and you shouldn't usually do it but it is a handy optimization in certain cases.--Indi (talk) 09:07, 14 September 2013 (PDT)

I agree, this is a better approach. --P12 11:12, 15 September 2013 (PDT)


Sorry guys, this page is wrong from the beginning. The given example (int x;) is BOTH a definition AND a declaration.
extern int i; is a declaration (compiler, somewhere there exists an 'i' that happens to be int)
int i; is a definition (compiler, that 'i' is here)
declaration = inform the compiler something exists somewhere (details come later)
definition = tell the compiler all the nitty gritty details (which by implication also declares something)
Most of the things mentioned on http://en.cppreference.com/book/intro/variables are *definitions* rather than just *declarations*. Simple rule, if the compiler has to *do* something, e.g. reserve space, than it is a definition. If the compiler only has to remember it, it is a declaration. --Akkersdi 26 sept 2013

I'm not sure if the page was originally written this way as to avoid the declaration/definition confusion for beginners or what, but nearly every use of declare is incorrect, and should be corrected. Perhaps the beginner section is not the right place to describe the difference (though the difference is very intuitive once someone understands what a variable is), but the article might as well use the terminology. Seems the attitude at the moment is to just change anything you find wrong/bad, so go for it. Or, if no one has edited it in a day or two to correct, I'll do it. -- Corbin (talk) 17:32, 25 September 2013 (PDT)
I agree that it might not be worth getting into the difference between declarations and definitions here. As long as the correct terms are clear, we might as well use them. --Nate (talk) 08:57, 27 September 2013 (PDT)
I concede I didn't focus on the accuracy on the initial version. For now, it's best to collect as much material as possible, since any silly errors will be quickly noticed. I'll carefully review the wiki before we move it out of alpha/beta status anyway. In any case, don't discuss, be bold. --P12 11:26, 27 September 2013 (PDT)


I needed a brief introduction to the auto keyword for variable typing so that I could use it in the section on polymorphism. I've added a short section on auto, along with an example. I did not modify the 'overview' section to include an 'auto' example. --Draymer (talk) 11:10, 14 October 2013 (PDT)

Complete rewrite

I've done a complete rewrite, incorporating all of the ideas suggested above. Some notes:

  • We should probably have a separate page, before this one, explaining identifiers. It doesn't need to be in depth - just something like "identifiers are used to label things in C++ - variables, classes, namespaces, etc. - and here are the rules for legal identifiers..." Identifers are used for tons of stuff and the rules are universal - introducing them right after hello world but before variables would make the variables thing shorter, and other stuff could refer back.
  • It might make sense to do type deduction first... then start covering specific types. That seems a more C++11+ way of doing it - do we want to do it more "future minded" or more "what you'll probably see in practice"? We could teach Sutter's AAA style right up front - which is consistent and safe - then talk about the actual types and how to specify. This would make even more sense if we use C++14 literals (like ""s for strings).
  • Maybe we could ditch the whole section on uninitialized variables? Save it for the advanced course?

What do you think?--Indi (talk) 22:00, 4 November 2013 (PST)

Your rewrite is great :)
I think we could move the rules for the identifier names to the advanced section and then link to that page from here. Something like
In general, the name of an identifier must consist of the characters a-z, A-Z, 0-9 and _, not begin with a digit or _ and not be a keyword. There are more rules that must be followed. You can read about them here.
The beginner does not need to know all the rules from the start, they can be learned later as needed.
As for types, I agree. Though perhaps it's more appropriate to cover the type-related stuff at intro/types and leave just a short introduction here.
As for unitialized variables, I agre tooe. We already have a note teaching that not assigning an initial value is wrong. Moving the expanded description would allow us to mention some more advanced things such as the fact that global and static variables are implicitly initialized to zero.
--P12 06:34, 5 November 2013 (PST)
That's a clean summary of identifier rules. I'll work that in, and cut the uninitialized variables section, and leave that to simmer for a while. Meanwhile I'll maybe start another complete reworking (starting with type deduction and mentioning types only later) in a sandbox in my user space and see how that shapes up. --Indi (talk) 17:17, 5 November 2013 (PST)