Your cut points between summaries and full articles often fall at awkward points. Most notably, don't put them right after a sentence that ends in a ':'; instead, write the summary to stand alone. For instance, your declspec summary ought to end with something like "Read on for examples of when you might want to use declspec instead of auto.", and your summary of the new random bits should end with something like "C++11 adds a new object-oriented random number generator with many enhancements over the C library version."
Your article tags seem rather redundant to be as prominent as they are; every article has the "C++", "C++11", and "Programming" tags.
In your shared_ptr example, you should talk about when you might need to actually take away the reference from the shared_ptr, so that it outlives the shared_ptr.
The shared_ptr article should at least mention std::make_shared and why it might be a good idea to use it.
The decltype article could mention std::declval.
The auto article could mention that auto can be combined with 'const' and '&' since auto on its own won't create a reference type. It could also be noted that auto is useful when you're writing generic code and might not know the types you're dealing with.
Thanks for the feedback. I considered adding std::make_shared and left it for subsequent articles. I will be revisiting shared_ptr. I did cover 'const' and '&' with auto and I didn't know about std::declval. I'll study it and consider adding it.
Also, I have covered the case of not knowing the type and yet being able to declare it by using 'auto' in the article on 'decltype'.
Is there any sense of ordering, or is each article self-contained? I wouldn't encourage shared_ptr as the smart pointer of first resort, unique_ptr is preferable where it's suitable.
I would also suggest going ahead and giving more guidance on when and when not to use various features, C++11 has a lot of redundant features. This is gonna start shading into matters of opinion, but somebody's got to do it, and for a novice any sane advice is better than nothing.
I've divided the features into "high priority", "medium priority" and "low priority" categories. I am covering the "high priority" ones first in what I felt was decreasing order of priority. Also, I am doing one article one core language feature, then one on the library and continue alternating in that fashion.
I like your idea on when we should use certain features and when it would be good to avoid them. I'll consider doing a few examples of that kind too. I think I'll do a few of those once I am done with a few samples form the "high priority" set that I mentioned in an earlier comment in this thread.
I like this a lot! Very nicely arranged, but the tags seem a bit repetitive (I.E. C++, C++11, Programming). Unless you're planning to add other languages and categories other than just programming (E.G. "Administration"?) I'd just skip those. The only other thing I'd add to this is a means to search for articles.
Thanks for the feedback. I'll add search. I'm very new to anything related to web. So, anything that is not "content", tends to get pushed aside but I'll add it soon.
That's a mistake. Good find. I intended to write auto only and must have typed int just out of muscle memory! Thanks for pointing it out. I'll fix it. It may compile and run as intended but it's not the code I intended to write.
shared_ptr: 1) It might be helpful to show an example with a bare pointer and then show the improved version with shared_ptr. 2) One good way to illustrate object lifetimes in RAII demos is to create a class that prints a message in the destructor. 3) In practice most people use a typedef for shared_ptr types. Instead of writing "shared_ptr<Class>" everywhere you would "typedef shared_ptr<class> ClassP" and then just use ClassP to declare shared_ptr variables.
auto: I think you can expand a bit on how auto interacts with reference and const qualifiers.
Three additional things I would add to the shared_ptr article:
1) Don't use shared_ptr for dynamic arrays (shared_ptr<T>(new T[n])).
2) Introduce use_count. That will explicitly show how shared_ptr does its magic.
3) It's almost always a good idea to treat shared_ptr<T> as a value type, not a reference type. There is very rarely a good reason to take a reference to a shared pointer since taking a reference, you know, actually creates a reference, but doesn't increase the reference count. As a corollary of this, arguments to a function should generally pass shared_ptr<T>, not shared_ptr<T>&.
The first two points you mention are already on my mind for another article on shared_ptr when I revisit it (after doing a simple introduction to unique_ptr and weak_ptr). The third one I never considered to mention since I never considered using a reference to a shared_ptr but I realise that folks might consider it and should be warned against it. I'll make sure I point that out in the next one on shared_ptr.
I have received this feedback regarding shared_ptr from multiple people - to show bare pointer version vs shared_ptr example. I'll add that soon.
Also, you are the second person to mention that there may need to be more content regarding auto with 'const' and '&'. I'll consider elaborating upon that too.
I am doing this to help myself learn and to have a single repository where there is sample code for every single C++11 feature.
The articles are going to be alternating between core language and library features.
Please send your criticism, corrections and hopefully some praise my way.
EDIT 0: minor typo fix
EDIT 1: I announce the articles on twitter with the username CacheLatency