File size

File size

File size

File size

File size

2.2 GB

Channel 9 was invited to this year's C++ and Beyond to film some sessions (that will appear on C9 over the coming months!) and have a chat with the "Big Three": Andrei Alexandrescu, Scott Meyers, and Herb Sutter. If you are a C++ programmer, then you know these names very well. If you've not heard of C++ and Beyond, well, put it down as a must-attend event (let's hope they do it again in 2013!). You can see material from last year's event here.

What about header files? Will they always be required? I suppose you could say the editor should just automatically generate the header, but then there is the requirement to include the header in the .cpp file. Anyway, having to duplicate the definition of a function in the .h and .cpp files really slows me down when coding C++. It also impacts code organization. VC++ 2012 allows filters to organize code, but that is not as good as using folders in C#. In C# I have each class in its own source file, where the name of the source file is the name of the class. Then the source files are organized in a hierarchy of folders and sub folders. I try to do roughly the same in c++ projects, but class declarations are still consolidated in a single .h files. Which results in a single .h file and multiple .cpp files, which requires more organizational thought to assign meaningful file names, and makes it harder to find the file in solution explorer that I need to edit.

Will the ^ syntax used in c++ WinRT apps be enabled for all windows apps? I assume the hat syntax encapsulates some sort of automatic implementation of smart pointers. It looks like a feature I would like to use.

Andrei: To be fair, part of the reason we got away without static foreach in D so far is that we _do_ have compile-time foreach – pretty much the only thing that's missing compared to a "full" implementation is availability outside functions:

Thanks for passing on the (admittedly long-winded) question, Charles!And, of course, thanks for the insightful answers from all!

In particular, Andrei's sentiments are quite compatible to mine here -- for instance, the fact that more metaprogramming facilities go hand in hand with the greater use of (and the need for) the supporting infrastructure (or "a web of supporting facilities in the language and in the std. lib.," as in CTFE in the tangent function values compile-time tabulation example). That's also why I'm looking into this area with a renewed interest now, given C++11's progress -- in fact, constexpr, also mentioned in the discussion, is one of the new C++11 features I'm most happy about in this context and I'm already thinking of it as being a part of this very supporting infrastructure

I think the point on making the language available for everyone ("language should be comphrehensible and usable for 100% of its users") is also a great point which I fully agree with. In fact, that's an important motivating factor -- ideally TMP should *not* be a feature just for the "select few" and I think we agree that it's more a result of a historical coincidence in the case of TMP rather than an inherent difficulty of TMP itself. Hence, Herb's and Scott's points (as in the worries about repelled-not-attracted or run-screaming reactions ;]) are fully and well taken (it's also true TMP is indeed just one area of C++ and not in quite as widespread use as the others). At the same time, simplifying the syntax / removing the awkwardness are directly meant to address this exact point In other words, this is how I view the role of extensions like "static_if" (instead of hand-crafted template specialization equivalent) or, say, "static_while" (instead of, say, hand-crafted recursive template instantiation equivalent) -- similarly to "constexpr", they allow to achieve what's already (at least theoretically / in some cases) possible, but do it in a natural fashion providing accessibility and ease of use to a wider base of developers.

Hence, Herb's and Scott's points (as in the worries about repelled-not-attracted or run-screaming reactions ;]) are fully and well taken (it's also true TMP is indeed just one area of C++ and not in quite as widespread use as the others). At the same time, simplifying the syntax / removing the awkwardness are directly meant to address this exact point

Exactly. I'd say people run screaming not because they fear metaprogramming, but because of the unbearable awkwardness of advanced C++ template metaprogramming.

That's the point: No, there isn't (well, if you ignore C macros, which are metaprograms). Herb is certainly right that currently the use of metaprogramming in C++ is limited to an Elite Priesthood™, but I do not believe that the sole reason is metaprogramming per se or its limited usefulness, but the fact that C++ does not yet have proper support for metaprogramming. And that's why a language extension like "static if" might be a valuable addition to the language: It could make metaprogramming in C++ more accessible, maybe even user-friendly.

@Novox: This. Putting aside claims of languages that they've supported metaprogramming for years, it seems to me that this is the next obvious step just like C++ was the next obvious step all those years ago.

I'm not remotely a big metaprogramming user, but I don't think even the experts would argue against the fact that it needs to be a lot easier.

Andrei is right that we need to make better usage of the hardware we already have. Sure, C++11 features will help, rvalue references, constexpr etc. but times have moved on. "Modern C++ Design" was published in 2001! It is not unreasonable to at least be planning to radically move the state of the art forward. Who genuinely wants to be stuck forever in the 1970s?

Herb was talking about doing "significantly better than precompiled headers".He talked in the context of speeding up compilation.

However I had a different need for "standard" precompiled headers.

The idea is that if we have "standard" precompiled headers which can be explicitly included like header files, we can release template libraries in binary form in the same way as we release dlls or static libs. (i.e. without giving out source code).

Let's also not forget that up until now, a lot of the benefit of metaprogramming has been taken by ever increasingly clever compile-time optimisations.

For example

if(sizeof(void*) == 4) Do_X86()else if(sizeof(void*) == 8 ) Do_X64()

behaves as a static-if in Visual Studio's release builds, because the compiler is smart enough to see that the condition can be determined at compile-time and the unused branch can be removed.

Similarly (3 * foo) typically becomes ((foo << 1) + foo) in release builds to avoid the multiply - something that other programming languages might try and do by having a meta-programming multiply_by_constant that is clever enough to know tricks to avoid performing multiplies on the hardware.

Meta-programming is certainly interesting from a language perspective, but without a good grounding in compiler theory, it's easy to overstate its important from a performance perspective.

@evildictait​or: I tried this very technique recently instead of resorting to compile-time dispatch and I got compiler warnings (else is never executed etc.) so I disagree. If compilers are getting smarter then that is great, but I don't see that it makes metaprogramming unnecessary.

Something like that... Sorry for not being specific (no exact dates). There will be great content here from this event, but we need to be patient (I mean, I'm ready to ship it all, but that's not going to happen...).

C

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.