posted by Alex Krycek

Thank you for this lecture video.

posted by Spetum

posted by tomkirbygreen

posted by Marek

posted by yanshuai

posted by NotFredSafe

posted by rhalbersma

posted by Philhippus

posted by GlassKey

vsbrar> I hope C++11 have more support for weak memory models.

C++11's <atomic>, which we shipped in VC11 RTM, fully supports weak memory models like ARM's. The atomics wisely default to sequential consistency, but if you want relaxed/acquire/release/etc. semantics, they are available.

Marek> What surprised me most about virtual functions is that pure virtual function can have implementation/body

Correct. "Pure" means "must be overridden" (if you want to get a concrete class).

yanshuai> Seems like a long time since the 3rd part.

There'll be another gap between this and Part 5 - I'll be on vacation for a couple weeks.

NotFredSafe> I would still like to see that "parameter passing best practices" episode

That definitely counts as part of the Core Language - the only thing I am avoiding in this series is directly covering the Standard Library.

I basically do episodes when I feel inspired enough about a topic to talk about it for 45+ minutes in a single take. Now that I'm basically done with "how a function call works", I can turn my attention to other matters.

> But if it's gotta be core C++, how about "sequence points are dead, long live the sequenced-before relationship"?

That is exceedingly subtle, and has almost no effect for single-threaded code. I figure that anyone experienced enough to make sense of the topic doesn't need me to explain it to them.

rhalbersma> Too bad time ran out

I'll never have enough time to cover every area of a topic (I could probably talk about the integral types for 3 solid hours), so my goal is to cover the basics and sketch out the structure of things so people are prepared to learn more, especially as they encounter issues similar to what I've talked about.

Philhippus> Is there a transcript and/or write-up of the lectures for reference purposes? Failing that how about time tags on the video?

Every episode is an undiluted stream of consciousness (mine is filled with cats meowing), but maybe Charles has some resources here.

GlassKey> The only annoying part of this pattern is that you have to come up with a slightly different function name for the virtual function...

The Standard conventionally uses a "do_" prefix. If I saw an "Ex" suffix, I would expect that (like in the Windows API) it referred to an extended form of an ordinary function (in C++ this is properly achieved by overloading, but C doesn't have that mechanism).

posted by STL

posted by Vincent

posted by Ivan

That would warn about the whole world, at least at first.

Ivan> Cool lecture, though vector<shared_ptr<>> made me go :/ - because of the performance of shared_ptr, esp if there are many of them.

shared_ptr isn't free, but it isn't horribly inefficient.

> "an allocator- aware std::vector would be a marriage made in heaven"

Our std::vector and std::allocator (powered by new/malloc/HeapAlloc) don't conspire together. That could improve performance, but I wouldn't expect it to lead to dramatic gains.

> is it possible using TMP to determine if a user class is memcypable

std::is_trivially_copyable does this.

> class X{vector<string> vs; int y; } is memcpyable

It is not - vector has a nontrivial copy constructor.

> Again great lecture, one cool thing would be auto.

That's a good idea, thanks. I'll think about it.

posted by STL

posted by Vincent

posted by Ivan

One question about slicing: You suggest forbidding any assignment operator and copy constructor in the polymorphic base class. However, how would you in that situation implement the derived class's copy constructor and assignment operator?

I was always under the impression that slicing was precisely required to say Base(rhs) and Base::operator=(rhs); in the derived implementations.

posted by KerrekSB

C++11's rvalue references v3 (not implemented in VC11 RTM) will automatically generate move ctors/assigns for X. Then swap() and sort() will automatically take advantage of them.

KerrekSB> However, how would you in that situation implement the derived class's copy constructor and assignment operator?

You don't; they remain disabled.

The solution here is a virtual clone() function, which you can invoke on a Base * and get a properly-cloned Derived.

posted by STL

Regarding the NVI -- what are some good examples where we'd prefer "protected" access over "private" (and vice versa)?

I guess it boils down to choosing between protected-virtuals [23.3] and private-virtuals [23.4] in the C++ FAQ, but unfortunately there's no direct comparison in there:
http://www.parashift.com/c++-faq-lite/protected-virtuals.html

Another question -- is NVI the same as or different from the Template Method pattern?

This source calls TM pattern "more generic" (without specifying what's more generic about it):
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtual_Interface

While this one seems to show TM as exactly the same thing:
http://www.parashift.com/c++-faq-lite/private-virtuals.html

posted by Matt_PD

posted by Ivan

posted by Chewie

posted by gh0st0nride

You'd want "protected" when you'd want the base class to provide an implementation that derived classes can invoke as a helper. (The base implementation can be marked pure if you want to require derived classes to override it. Of course, if the base implementation is protected, pure, and implemented, a derived class can override it and just call the base implementation.)

> Another question -- is NVI the same as or different from the Template Method pattern?

I don't really pay attention to design patterns as I don't find them to be especially useful. I've heard that the NVI is one way to implement the "Template Method" pattern, which sounds right to me.

Ivan> I had a really weird experience playing around with poor mans's v3 RVRs(memcpy)

That's incorrect and dangerous. In the absence of rvalue references v3, you should write memberwise moves (with std::move).

In C++98/03/11 (the terminology has changed, but the principles have remained the same), only PODs (Plain Old Data) can be bit-blasted with memcpy(). Classes with copy constructors/etc. are "non-POD" and attempting to memcpy them triggers undefined behavior. std::vector is definitely non-POD and therefore you cannot memcpy it.

Chewie> I find it hard to find C++ resources that don't advocate this "inheritance based programming", and I'd love to hear your best practices about that.

See Effective C++, Third Edition by Scott Meyers. It has a whole chapter on inheritance, and an item (38, looking at the table of contents - my copy is at home) dedicated to when you should use composition instead of inheritance.

In general, I use inheritance when I need the one thing it does uniquely and well: runtime polymorphism. Otherwise, I'll reach for other C++ mechanisms first. For example, templates are better at compile-time polymorphism. What "compile-time polymorphism" means is when I want to write something that can work with many different types, but those types are all known at compile-time. The STL is the most obvious and famous example of this. vector<T> is a container of an arbitrary type T, but that type can be specified at compile-time. Making it a template allows it to handle these arbitrary types, without incurring any runtime overhead (everything is stamped out by the compiler and then inlined away, ideally).

gh0st0nride> These core c++ video aren't being posted on visual c++ blog now?

I write those link-posts when I have time (I just got back from 2 weeks of vacation). I'll try to remember to write them for videos in the future.

posted by STL

posted by rhalbersma

posted by Alexander

class X{
public:
X& operator% (const X&) {
std::cout << "member fun\n";
return *this;
}
void f();
};

X& operator%( X& a, int)
{
std::cout << "global fun\n";
return a;
}

void X::f()
{
X& a = *this;
a % 1; // calls non-member function
operator%(a, 1);//compiler error
}

thanks in advance

posted by gaya

rhalbersma> How about showing us your development setup and routine?

You'll see some of this in Part 6. My environment is very austere - I use a plain text editor and I drive the compiler from the command line. (When building test cases, I manually invoke "cl /EHsc /nologo /W4". When building the compiler and libraries, I use our internal build system on the command line. At home, I use makefiles on the command line.)

Alexander> Are your core compiler collegues finally working on C++, or do they still have "other assignments"?

The compiler team is working on C++11 Core Language features right now. In Part 6, I'll show off an internal build of the compiler (driven from the command line, since IDE integration is a separate chunk of work). I'd love to say which features are being implemented, but I'm not allowed to do that yet.

> Can you make a guesstimation of when the "in-between-release" of the compiler that Herb Sutter mentioned in GoingNative will arrive?

We can't ever talk about release dates before they're publicly announced, sorry.

> How do you find this situation? I could imagine you'd quite love to see more features to play with (variadic templates maybe?).

I've often mentioned that as an STL maintainer, my work is greatly complicated by the lack of variadic templates. We've been imitating them with clever-but-horrible macro schemes since the VC9 Feature Pack.

gaya> if overloaded operators are just syntactic sugar

They are syntactic sugar for ordinary function calls, but they obey various special rules, especially for overload resolution.

rhalbersma is correct, but to explain further:

Given "a % 1", N3376 13.3.1.2 [over.match.oper]/3 explains that "For a unary operator @ with an operand of a type whose cv-unqualified version is T1, and for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2, three sets of candidate functions, designated member candidates, nonmember candidates and built-in candidates, are constructed as follows:". That's why both the member and non-member functions are considered by overload resolution (as a programmer would naturally expect).

Given "operator%(a, 1)" which is written as an ordinary function call, 3.4.1 [basic.lookup.unqual]/8 notices that you're in a member function body, so as soon as it finds X::operator% it stops. In general, C++ really likes calling member functions, which is why the unqualified name lookup rules are written like this. The Argument-Dependent Lookup rules also follow this preference - both unqualified lookup and ADL are performed, and both sets of declarations found are tossed into the overload resolution arena, *except* that if unqualified lookup finds a class member, the ADL set is emptied out (3.4.2 [basic.lookup.argdep]/3 has the full story and lists a couple of other conditions).

This is actually relevant in your scenario. Given the arguments (a, 1) the argument a is of type X which activates ADL. X lives in the global namespace, so ADL would search the global namespace and find operator%(X&, int) there - except that ADL has been disabled because unqualified lookup found a class member.

posted by STL

posted by gaya

posted by Tominator2005

Note sure if this is the best place but I wanted to suggest std::function and related topics for a show. I have just started replacing a bunch of old style functor stuff with this and have run into a lack of documentation, for instance answering a question like "what does a std::function actually store and how does that relate to copying/assignment of std::function objects" seems hard to find out without reading C++ library code which is not the easiest code to read!

posted by davidhunter22

I'm programming a directory iterator and I'm getting a error message, but not from my program, from the filesystem header; saying " '_Ptr' : is not a member of 'std::tr2::sys::basic_directory_entry<_Path>'.

my call to path is

sys::path fullpath = 
        sys::system_complete(sys::path(argv[1]));

Tom

posted by Tominator2005

I'll try to remember that for when I start doing videos on the STL again. If I forget, remind me. :->

> I have just started replacing a bunch of old style functor stuff with this

std::function is extremely useful, but it shouldn't be overused. For example, if you can template an algorithm on functor type, that is more efficient than having it take a std::function (which has inherent overheads).

> "what does a std::function actually store

Magic. But really, it just stores a copy of the functor you've given it.

> and how does that relate to copying/assignment of std::function objects"

The stored functor, including any state within, will be copied/assigned.

> seems hard to find out without reading C++ library code which is not the easiest code to read!

You shouldn't look at the guts of our implementation. If MSDN seems insufficient, you can look at the Working Paper for maximum accuracy.

Tominator2005: This compiles for me with VC11 RTM:

C:\Temp>type meow.cpp
#include <filesystem>
using namespace std;
using namespace std::tr2::sys;

int main(int argc, char * argv[]) {
    (void) argc;
    path fullpath = system_complete(path(argv[1]));
}

C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp
meow.cpp

C:\Temp>

Send me a self-contained repro (like this) at stl@microsoft.com and I'll take a look.

posted by STL

Best Regards,

Russell

posted by Gob00st

posted by STL