Interactive Panel: Ask Us Anything!

Is it possible to send questions in advance from those not attedning?

To analyzing C++ code is very hard work. So I think the Standard must consider these kind features for who providing automation tool. What you think?
As you know, there are lots of automation tools in Java development env. But C++ didn't have anything perfectly supported.

Look at CLang, it provides advanced tools integration. In summary, you can access the AST of your code for code completion and probably also refactoring or whatsoever... This has not much to do with the standard I guess.

But you can see their website, it's not enoght to applying real environment.
Implementing 80% is easy but 20% ... I think it can't be.

@Ruffin:take a look at this: http://www.youtube.com/watch?v=mVbDzTM21BQ

So what was the question "for anybody but Herb"???

@0:31:00: Wow, is there really a debate on what a module is? Just combine the outdated concept of header / source into one file -- that's a module. Now solve all the language problems that crop up. I agree it's a huge change, modules will have to exist side-by-side with the old system for backwards compatibility.

"#include file" is similar to "from file import *", always a bad idea.  C++ will need fine-grained symbol import/export control for macros, namespaces, templates, classes, functions and variables.  Look at Python for inspiration: "from module import symbol as local_symbol"

Of course "#include" does more than just import symbols, but the idea is to develop new language to divide its power until it's no longer needed; it's a sledgehammer of a directive and should be deprecated.

@ryanb: unsurprisingly, it was the question about thoughts on C++/CX. It's a pity it didn't get answered, although I can imagine it would feel uncomfortable for the speakers to criticise C++/CX in this particular situation...

I was the one who raised the issue of build/compile iteration times in the Q&A. I apologize if I came across as critical of the work the committee has done on C++11 -- I think all the new language features are important and useful, and I'm very glad for the work everyone has done (thank you especially for lambdas!)

The point I was trying to (poorly) raise, was that I would like to see language features on the agenda that that improve the ability of programmers to iterate quickly on code. C++ suffers from high levels of inter-dependency between compilation units, and if this were not a language problem it would be solvable by compiler/linker developers. It is true that developers can improve build efficiency with techniques such as unity builds, pimpl firewalls, better forward declarations, and distributed parallel build systems, but all these are work that developers must do outside of their fundamental goals of implementing algorithms.

I don't know whether this concern is best addressed with modules, partial classes, or something else, but I think it is an important one for the future, especially since the language allows us to create larger and more complex projects.

I really enjoyed the talk...
STL is so cool ,and Andrei House and Herb Wilson :P are awesome...
too bad I hate twitter and that I wasnt there, I always wanted to ask a compiler programmer why move was necessary as a lang feature, aka why compilers cant optimize everything that programmers optimize manually with &&.

One of the questions asked had to do with using raw pointers, particular void*. Chandler Carruth said it is easy to demonstrate the compiler will generate less/faster code by avoiding the use of raw pointers, and I would like to get some code sample that illustrates this point. Thanks in advance!

@Kometes: "Wow, is there really a debate on what a module is?"

Yes. Sort of.

The standard's committee has been looking at modules for a long time. Like concepts, the earliest modules proposals fell due to trying to solve every problem. They included stuff with a standardized C++ ABI, DLL/SO interfaces, etc. All kinds of stuff that are interesting certainly, but really muddied the waters as to the purpose of the feature.

The current module proposal is much more focused. But the stuff from earlier modules proposals still lingers in their minds. What is needed is for someone big and important to step up and make a presentation that says, "THIS IS WHAT MODULES ARE FOR!"

Stroustrup is doing something similar with concepts, taking the whole thing to a minimalist, first-principles approach. That really needs to be the new push with modules as well. They exist for compilation reasons, nothing more, nothing less.

ok, so when do we get a clang frontend for MSVC? no joke.

-Charles and Microsoft, sincerely THANK-YOU , you brought all my heroes at one talk in one room this GoingNative is the best thing that happened to c++ in a long time.

-Also open-source c++ code analyzer, best tech-news on this year.

Not sure if this is the right place to dive in, but here goes:

The discussion of pass-by-value or pass-by-const-reference troubles me because of the possibility of multiple threads. It seems the desire to avoid the interlocked ref count operations assumes you don't need or want the protection they provide. If your function takes a shared_ptr (or any other type) by const reference, you only guarantee that particular function won't modify the value; in another thread, the very same shared_ptr could be reset(). If your function instead took the shared_ptr by value, the reference counting mechanism assures the shared_ptr points to a valid object for the lifetime of the function call. I don't see how it's safe to blanket suggest that pure observation (of shared_ptr in particular) should always use pass-by-const-reference.

I suppose you have to treat the use of a shared_ptr-controlled object in another thread as shared ownership, but since threads are created from functions you'd better make sure to, say, wrap the function (that takes the shared_ptr by const reference) in a lambda that takes the shared_ptr by value.