It really looked like a JEDI masters council, with the padawans in the room and online :o)
With Bjarne as Yoda, of course !

Thank you !

The range stuff I can understand. But I have no idea what “array_ref” and such are for.

Furthermore, when it comes to “getting something done”, range-based algorithms aren’t something I see as an impediment to my work. They’re a nicety, some good quality-of-life stuff, but nothing more than that.

If the argument is that people want to use other languages because they have a larger, more feature-rich standard library, they’re *not* talking about range stuff or shared_arrays. Those are minor trivialities compared to networking and such.

Isn’t a large part of the standard library just portable C++?

> Porting for example, Python to another platform is an arduous task.

Is it? I’d expect most of it to be written in a portable language.

I do find it kinda strange that Herb seems to focus on higher level libs. IMO lower level libs are more important to get standardized first. Standard binary (a)sync file/network IO for example would be great.
Having standard compression and crypto would be welcome too.
But even simpler things like array_ref/data_ref/str_ref, shared_array, a range interface for all algorithms are even more important.
You can’t do high level stuff without getting the low level stuff right first.

I did have one question. In your Day 2 keynote, you really pushed hard for a much, *much* larger standard library. And I find this disconcerting, for one very important reason.

The first language ported to *any* platform is C. No question about that. The reason being? It’s vital to compiling the OS, but also because it’s tiny. C compilers are small and simple; they can easily be bootstrapped. The C-standard library is similarly microscopic.

What is the second language ported to any platform? C++. Why? For similar reasons to C. Important software is written using it. But also, its standard library is fairly small. You don’t have to port much more than some basic file IO. `std::vector` is pretty cross-platform. You need to port `std::streambuf`, and a few OS and locale-related functions. But that’s it.

This stops being possible when C++ has a gigantic standard library. Porting for example, Python to another platform is an arduous task.

The reason languages like C#, Java, and Python can have immense standard libraries is that there is only *one* implementation of them. OK, there are a couple of Java implementations, and .NET has one in the form of Mono. But these are generally also-rans as far as implementations go. There is one .NET implementation: Microsoft’s. That’s the standard. There is one Java implementation: Sun/Oracle’s. That’s the standard. There is one Python implementation.

C++ has 3 major implementations: GCC+libstdc++, Visual Studio, and Clang&libc++, as well as a plethora of minor ones (ICC, etc). You are asking all of these developers to implement some pretty heavyweight code. XML parsers (that’s pretty substantial for real XML, which means XML IDs, DTDs, XInclude, etc), JSON parsers, sockets, and other stuff. That’s a *lot* of work. And that means a **lot** of bugs.

To make this even remotely feasible, you would need the various C++ interests to create an open-source repository for most of these libraries so that they can share implementations. At which point… all you have is Boost that just happens to be shipped with your compiler.

I just don’t see this as a good idea.

Plus, there’s the very real possibility of the standards committee screwing them up. Take an XML parser. Is that going to be properly C++ized, so that it meshes well with standard algorithms? Will it’s DOM-style interface be an iterator-compatible interface? How does that affect parsing performance? Will the parser be able to be in-situ like RapidXML for that added bit of performance, or will it have to do something else? What parts of XML will it include? Will XSD be included as well (I hope not, because that makes it much more complex)? Will it offer several different styles of parser (reader/writer, SAX-style push parser, and DOM-style tree), or will it just force one on you? How do you deal with Unicode in XML? Does the parser provide a small set of Unicode encodings that it supports, and if you don’t use them, you’re out of luck? Or is it extensible in some way? What’s the interface for extending it, and does it differ between the three parser styles?

The thing about XML parsing today is that you can pick up what you want off the shelf. If I need serious XML processing, I go to LibXML2. It is a full, proper XML parser that has many styles of parsing files. It

C#, Java, and Python were all defined by *fiat*. For better or worse, their APIs were developed by one tiny group/person, who said, “Our API will look like this!” The committee could easily get bogged down in minutiae over these libraries.

And if they don’t, if the committee basically just rubber-stamps proposals, then we could very easily get a big problem: one thing in the standard doesn’t really work well with other things in the same standard. One of the points of a standard is interoperability: all the pieces work together. With C++, this is mostly true, but there are… odd places. `iostream` really looks out of place next to the STL-derived containers and algorithms. A bit of glue was added with the streambuf iterators, but then… do we really need the iostreams if we can just create a streambuf and input/output iterate over them with algorithms?

Big libraries are not something that committee-based standards are really capable of doing. C# may be an ECMA standard, but that’s because Microsoft did most of the work internally and just said, “Hey, review this and make sure it’s not stupid.” If we’re going to have dozens of contributors for library components running in and dropping code, basically saying, “standardize this pretty much as is,” that’s going to be a real problem.

I get the problem, I really do. Standard libraries are the first stop for people looking for a way to solve problems. And XML, JSON, etc, are problems that a lot of applications need solving. But I don’t think direct standardization is the way to go for these things. It could very easily do more harm in the long-run, creating buggy standard libraries with esoteric, poorly-constructed interfaces that nobody uses anyway.

Personally, I’ve always felt that C++, like C, should have standard libraries that are very general. They should provide common utilities that could be used in pretty much any program. They shouldn’t be providing specific functionality that would be called for directly by design.

Use shared_ptr to allow for multiple isochronal owners, none of which shall have exclusive right to delete.

Use unique_ptr to allow for exactly one isochronal owner.

I’ll be glued to the stream as much as possible, and VoD the rest. Herb, thanks go to you and all the C++ guys at MS who keep waving the “C++ is more relevant than ever”-flag. Much appreciated!

Not sure what to say about any and all versions of Linux. Try Moonlight out. “Should” work.

We have an SL dependency because:

1) We want to Smooth Stream the media (very effective approach) and our media partner employs IIS7 SS
2) Smooth streaming technology does not exist for HTML5 video…
3) Flash is not an option…

Charles

“Which platforms does Moonlight support?

Moonlight should work on any modern 32bit and 64bit Linux distributions under Firefox versions 3.0 through 4.x, as well as Google Chrome, from both stable and dev channels
We make sure that the plug-in available from this site works on the following platforms: SUSE Linux Enterprise Desktop 11, openSUSE 11.x, Ubuntu 9.10, and Fedora 12.
Older distributions will run Moonlight, but may require that you build Moonlight from source code.”

Well, Firefox 3 and 4 are quite old by now, and I’m using Firefox 9. So I guees most “modern desktop browsers” doesn’t support it, since it doesn’t actually support modern browsers. And that is a shame.

I guess I’ll have to watch it on Channel 9 afterwards. I’m still looking forward to this a lot!

To develop Metro style apps, the Windows team’s guidance is that they equally (really) support C++, .NET, and Javascript, and to use whichever you’re most comfortable with and meets your needs. If you’re most familiar already with C# and are happy with its performance and environment, use it. If you’re most familiar with C++ or want its extra efficiency and determinism (e.g., cleaning up WinRT stream objects efficiently and promptly by default), use it. Or write different parts of your app in all three; it works.

BTW also note that “Metro style apps” != “Win8 tablet apps” because the latter is a superset that also includes DirectX, for which you’d want to use C++.

Also, I’ve updated http://channel9.msdn.com/Events/GoingNative/GoingNative-2012 to make this distinction very clear.

Charles

Cheers,

- Alf

Relying on the user realzing and remembering that make_unique should be used, is to rely on convention.

That’s always risky, and to be avoided when the convention can very easily be expressed and enforced within the language (in this case, by replacing the free function with a constructor, andly changing the function signature accordingly).

Cheers & hth.,

- Alf

PS: Again, thanks for keeping up this eris,

Consider an expression

f( !expr1, -expr2 );

If I read Herb correctly, the execution of operator!() and operator-() is unsequenced and allowed to overlap if the operators are built-in (e.g. if expr1 and exp2 are int), but is indeterminately sequenced and not allowed to overlap if the operators are user-defined. This looks counter-intuitive so I want to make sure my understanding is correct.

That means expr1 and expr2 can still be executed in whatever order.
Case 1: expr1, expr2, g, h, f
Case 2: expr2, expr1, g, h, f
Either way still meets the guarantee that the expressions will have been fully evaluated before the functions are called. (This is opposed to, say, assuming arguments will be evaluated left-to-right.)

In case 1 for example, you could have: new T2, new T1 (throws)(cleans up this T1 instance), T2 was not cleaned. Plus what Herb mentioned about the new actually breaking into allocate and constructor pieces.

Thanks for the great insight, Herb!

In VC8 the statement: auto_ptr(T) = new T(); // will compile and crash at runtime. Note that I’ve replaced the angle brackets for posting purposes.

Thanks Herb :-)

On the other hand in my work I’ve recognized two problems with make_shared:
1. You cannot use make_shared with classes that have protected constructor. It is essential when the class have it’s own “create” factory performing some additional work and we want to disallow the means for creating the object outside of the factory. Standard does not specify with who to be befriended (and even if, it would create a loophole) and there is no base class to inherit from that would do the work effectively.
2. When weak_ptr outlives shared_ptr the memory that have been occupied by the object can’t be freed until all weak pointers will be destroyed.

Here is test code, if anyone wants to trcheck:

#include
#include
#include
#include

using namespace std;

struct A
{
int m;
A(int i) : m(i) { printf(“ctor(%d)\n”, i); }
A(A const& o) : m(o.m) { printf(“cctor(%d)\n”, o.m); }
A const& operator=(A const& o){ m = o.m; printf(“op=(%d)\n”, o.m); }
~A() { printf(“dtor\n”); }
};

A foo() { return A( rand() ); }
auto_ptr make_unique(A&& a) { return auto_ptr(new A(forward(a))); }
//unique_ptr make_unique(A&& a) { return unique_ptr(new A(forward(a))); }

int main()
{
srand(time(NULL));
auto_ptr p( new A(foo()) );
// auto_ptr p( make_unique(foo()) );
// unique_ptr p( make_unique(foo()) );
return 1;
}

One further situation in which you don’t use `make_shared` is when constructing a shared pointer *from* an existing unique pointer, possibly with a non-default deleter. The resulting shared pointer will have to be one of the type with separate refcontrol block (including the deleter information) and distinct dynamic resource (which already comes fully furnished from the unique pointer).

Interestingly enough, the construction-from-unique&& doesn’t appear to allow you to specify an allocator.

It is still not just possible, but most natural, to call f in an unsafe way.

And one solution is to replace the make_unique function with a Unique class whose constructor does the same as make_unique (namely forwarding arguments and doing the new‘ing), and use this class for the formal arguments of f.

Cheers & hth., & thanks for keeping up the GOTW series!, :-)

- Alf

It is still not just possible, but most natural, to call f in an unsafe way.

- Alf

logic suggest that it should not work (foo() call should complete before we allocate any memory and therefore we are doomed to have a copy), but it seems that major compilers (GCC/MSVC) recognize this situation and (unless you overload operator new) go extra mile and allow RVO to work here (or may be there is an obscure clause in C++ standard that allows that).

- unfortunately ‘make_unique’ facility will break it and this will leave you with unnecessary copy constructor call:

auto p = make_unique(foo());

Disclaimer: I reserve my right to be wrong. :-)

When using unique_ptr, there is only one owner of the resource at a time. However, unique_ptr may grant non-owning access to its resource. This is very important when, e.g., you want to call a library function that takes a pointer to your resource:

libFun(Foo *);
unique_ptr foo(new Foo);
libFun(foo.get());

By “library” I mean any reusable code. It makes very little sense to have a library function that operates of Foo, but has no interest in the ownership of Foo, to have this signature:

libFun(unique_ptr & foo);

The pointer passed to libFun(Foo*) is a transient alias, or a “weak pointer” to the resource. It’s a bad idea to let the function or a data structure store such a transient alias for two reasons: (1) The alias might become invalid when the owner is destroyed, (2) such aliases might appear in a different thread than the owner’s. In the latter case, thread safety of a unique_ptr is compromised. A unique_ptr is thread-safe only if there are no aliases to it or to its contents (transitively), and there are no aliases inside its contents to data that’s accessible from the outside. In general, a unique_ptr defines its own cluster of interlinked objects that have no connection to the outside (incoming or outgoing references).

When using shared_ptr, many copies of it might coexist in the program at the same time. It’s still not a good idea to store aliases to the resource it’s protecting or to its transitive contents.

shared_ptr implements a simple form of garbage collection — reference counting. The problem with reference counting is that it doesn’t deal well with cycles. If you have a graph data structure that contains back pointers, you can’t turn them into shared_ptrs without risking cycles. The semi-safe way to implement back pointers in a shared_ptr-based data structure is to use weak_ptr. A weak_ptr doesn’t take part in reference counting, so it doesn’t create non-collectible cycles, but it can be (temporarily) converted into a shared_ptr to gain access to the resource. (Of course, if the resource has already been collected, this conversion will not work and it will result in an exception.) weak_ptrs are used, for instance, in shareable doubly-linked lists or trees with parent pointers.

unique_ptr should be used for situations where a function or object needs to allocate something, but does not need to share ownership of that allocated object with some other object or function. The object/function will directly control the lifetime of the object.

unique_ptr should be used in situations where ownership can be *given* to another object/function. That is, after the function call, the current owner no longer has access to it anymore.

shared_ptr should be used in situations where multiple functions/objects can *simultaneously* claim ownership to the same allocated resource.

shared_ptr should also be used in situations where other functions/objects may want to weakly reference an object. This is useful for objects that need to monitor other objects, but don’t fully claim ownership over the lifetime of that object. The object with the weak reference can check to see if the object still exists, but it does not prevent it from being destroyed.

2: Why should you always use make_shared to allocate objects whose lifetimes will be managed by shared_ptr? Explain.

shared_ptr offers a number of features. The main one is the ability for multiple copies of the shared_ptr to all claim ownership of the same object. In order to do this, shared_ptr requires a special control block of memory that stores a count of references to the managed pointer. This block is separate from the actual pointer being owned.

Consider the following.

auto variable = shared_ptr(new Typename);

Two memory allocations happen. `new Typename` allocates the object that will be owned. But the constructor of the shared_ptr also allocates the control block which contains the reference count. That is two separate allocations.

Since memory allocation is not exactly a lightweight activity, it is best to minimize it. Because make_shared does the construction of the type, it has the ability to combine the memory for the object and the control block into one allocation.

Therefore, where *possible*, it is best to use make_shared. However, it is not always possible. It cannot be used for managing memory from a source that is not a C++ object, such as an opaque pointer returned from a C-style API.

allocate_shared should be used in circumstances where a special memory allocator is needed.

So the question itself presupposes a conclusion that is incorrect, since make_shared cannot replace *all* uses of shared_ptr creation.

3: What’s the deal with auto_ptr?

auto_ptr was an attempt to replicate the effective functionality of unique_ptr using a language that couldn’t express true move semantics. Its copy constructor actually *moved* the ownership rather than copying it.

One can make reasonably safe use of auto_ptr if one is careful. However, it cannot be used in a standard libary container due to its “copying” semantics. Standard containers that copy their elements at any time could easily break any stored auto_ptr. Something similar can happen for storing auto_ptr in an object without a specialized copy constructor/assignment operator.

Since unique_ptr uses C++11 features to explicitly disallow copying, and C++11 standard containers can store non-copyable objects via use of move constructors, auto_ptr is effectiveless useless. It was therefore deprecated in C++11.

Only if you can’t clearly assign the owner to the resource should you use shared_ptr. This happens when access to a resource is shared between objects whose lifetimes cannot be predicted. shared_ptr implements the policy of “last to leave the room turns off the lights” (releases the resource).

In a multithreaded context, unique_ptr is the fastest and safest way of moving data between threads, as long as there are no stray aliases left behind. Uniqueness means that only one thread at a time has access to the resource and no additional synchronization is required. This is not true with shared_ptr, which facilitates sharing of resources between threads. The object in shared_ptr must implement its own synchronization. What shared_ptr provides is thread-safe reference counting, but at a non-trivial cost.

2. make_shared is a substantial optimization. Normally a shared_ptr needs a separate heap object for storing the reference count. When shared_ptr is created using make_shared, the memory for the object and the reference count are allocated together. Besides saving one allocation, this also improves locality.

3. auto_ptr was a hack that is now deprecated. Move semantics and rvalue references allow clean and efficient implementation of unique_ptr. The major danger with auto_ptr is that it could be quietly passed using its copy constructor, which would invalidate the source auto_ptr. If that source auto_ptr was subsequently accessed, it would result in a fault. unique_ptr, on the other hand, cannot be passed quietly, unless it’s an rvalue. The programmer has to explicitly call std::move to pass an lvalue unique_ptr. That makes for a safer code.

The `shared_ptr`:
- Shared ownership. I usually prefer single ownership though.
- Safely store pointers in a container. More flexible than `unique_ptr` in this regard.
- parent-child relations can be modeled using `shared_ptr` and `weak_ptr`.
- Accepts a `free`-function as a second constructor argument.
- It generates a ‘free’-function based on the type provided in the constructor. So `shared_ptr ptr(new SubClass());` is safe even if `Base` does not have a virtual destructor.

Concerning `make_shared`:
- Safe alternative to unnamed `shared_ptr` temporaries (see [documentation of boost::shared_ptr](http://www.boost.org/doc/libs/1_48_0/libs/smart_ptr/shared_ptr.htm#BestPractices) ).
- It’s a nicer and compacter syntax.

Concerning `auto_ptr`:
- Has similar use as `unique_ptr` (ownership transfer, passing between threads) or `boost::scoped_ptr`.
- Not safe to use in containers.
- Dangerous to use for member variables in classes do not have a user-defined copy constructor and assignment operator. Even though the class obeys the rule-of-three, it is not safe to copy because it leaves the original invalidated.

With `auto_ptr` it’s easy to shoot yourself in the foot by passing it to a function and then still try to use it:

std::auto_ptr r = foo();
bar(r); // This looks like a regular function call.
std::cout <value(); // Ouch! I forgot the object is no longer accessible!

With `unique_ptr` you must explicitly move the pointer by calling `std::move`. This makes me less likely to forget that I can no longer access it:

std::unique_ptr ptr = foo();
bar(std::move(ptr)); // alerts me that the object is no longer accessible

2) Not always. make_shared doesn’t allow to specify your own deleter. However, if there is no need for one, then there are indeed good reasons to use it. For one, make_shared compresses the allocations into a single one, where a shared_ptr<X&rt; p(new X); would need two allocations: one for the X object, one for the reference-count block used by the shared_ptr.

3) auto_ptr has broken copy semantics. The copies actually moves the auto_ptr, meaning it transfers the ownership on copy. As such, it’s unusable in standard containers and even deprecated by the C++11 standard.

I would like to ask you the same question that Nikhil has asked but I will put it in a different way. The question is being Microsoft being so aggressive in

1. Making the un-managed code perform faster on their platforms.
2. Making the performance of managed code better day by day.

Why should the developers use C++ instead of C#. Don’t get me wrong as I am a big fan of C++ and worked with C++ for almost 6 years (recently shifted to C#). I also like what Microsoft is doing with performance optimization for managed code and the new platforms being able to run them in a better way. I am just curious because shifting from C++ to C# felt like “Man, things became so easy now, i can finish up early and efficiently without worrying about dormant leaks and bugs in my code.” and I presume many guys would have felt the same (Nikhil could confirm). so now I should pick up C++ for development on future versions of windows.

I am saying this with no means of offending anyone (I see 2 rate downs in Nikhil’s post), I am just curious whether I should ever be going back to the world of C++ or not.

Rahul

I am a developer and have coded in C++, VC++ MFC, Delphi, C#, ASP .NET MVC2. I have a question regarding C++ in Windows 8.

Why should developers or companies consider using C++ instead of C# or Html5, Javascript to develop Metro applications? It seems that it is quicker to develop in these languages than writing code in C++. The impression that I have gotten from the videos of the build conference is that the performance hit is not significant in case of C# in Windows 8 as the .NET framework is not there or when using Html5, Javascript. It would be significant to use C++ only when one is writing games or high performance software. It seems like C++ has been killed in Windows 8!

Nikhil