Comments

2 days ago

@PhrostByte it is very easy to invalidate this, constant member functions do not enforce referentially transparency (pure functions) even in C++11. You can still modify global or (class) static unsynchronized variables in constant member functions or modify unsynchronized data members marked as mutable.

You can say this is a bug/undefined behavior (in the context of concurrent/parallel code) but this is an issue with the language/library if the standard say that constant member functions must be side-effect free but the language does not enforce this thus the compiler will never enforce this.

From my point of view const does not guarantee thread safety, this is only a promise that can be silently broken. This is not particular useful.

This change in C++11 is actually a breaking but silent change to existing code and you have no help from the language/compiler to find and fix any buggy code which is not C++11 compliant.

In other words, it's no different from most everything else in C++ -- helping you a good deal but still not "enforcing" anything, allowing you to do whatever the hell you want in the end

A compiler may not be able to catch and warn about all instances of broken code (you're right, this is a breaking change), but there's a lot of room here for it to help.

Well, that's an interesting insight. It's going to take me a moment to wrap my head around this . I keep coming up with ways to invalidate it, but then go "oh, no, it still holds..."

@Andi: Reading and writing from a file asynchronously has been possible for some time.  It's opening/closing that I'm curious about. It's not normally an issue, but when you open a file over a network or from a CD there can be serious latency -- so true async opening/closing has always been a dream of mine. I was quite surprised when Herb mentioned it already being there, so I hope he didn't misspeak!

About 34min in, Herb mentions that Windows has asynchronous file opening/closing, demanded by the Office team. What are the functions? I've been wanting this for a very long time!

I know WinRT has async opening, but I assumed it was merely using a thread pool in the background.

I think Stephan has all the "learning C++" videos cornered well... I don't think we need more of that here.

Maybe you can discuss news for native that month.  Perhaps highlight cool third-party libraries.

I would love to hear from the compiler team.  Pretty much anything will do

I'd also like to know where native is being used within Microsoft:

• Where is C++ specifically -- not C or COM, but real C++ -- being used over other technologies, and why?
• Where is native being used over managed, and why?
• Where is native being used with managed?
• What things started out as native/managed, but were switched? Why?

Agreed. With Diego and plenty of other guests we've had on Channel 9, I sometimes need to give my full attention to understand them. Microsoft is very diverse! I don't know if it's the video format, the mic used for recording, my speakers, or just an inability on my part, but a transcript would be really helpful.

1 day ago

Support Windows Phone 7 +!!!!!!!

Agree completely.  I love Silverlight/.NET but WP7's memory/CPU constraints sometimes make me itch for some optimizations that just aren't possible in managed code.

Jun 15, 2011 at 7:42 PM, PhrostByte wrote

Things I would like to see for VC++ and C++ in Windows:

• A bigger focus on modern C++ design.  Look at the PPL -- it knows that it's in C++ and takes full advantage of it.  It fits perfectly, working exactly as expected.  Contrast this with so many of the other C++ offerings at MS which rely on or try to mimic COM.  COM is not a good or friendly way to write C++!
• A new, pure-native UI framework with a focus on databinding.  Direct2D and pure vector like WPF would be a plus.  Built-in async databinding would be even better! Like WPF, design as if there was a clean slate -- don't just upgrade Win32 or MFC.
• A kitchen-sink library similar to the .NET Framework.  Windows already has APIs scattered around for much of this, but a collection of supported, modern C++ wrappers would be fantastic.

Funny, a week after I write this I read an article on Ars that makes it sounds like much of this is coming in Windows 8.  Perhaps it's time I get a job at MS (or at least, start working for some tech predictions website), if I'm so randomly in tune with their thoughts on the native future.

This looks pretty cool.  I see that it supports n-dimensional data and GPU builtin functions, so that answers two of my questions.

The C++ extension looks clean enough, I'll be curious to see if GCC and ICC implement it.  Still, at the moment it looks like it's only going to be useful for quickly adding some GPU support to apps targeting Windows Vista and up.  For anything portable, OpenCL will remain king.

Some questions:

1. Does it support keeping data in RAM closest to the execution unit?  For example, if I have a multi-pass function like an orthogonal 2D resampler, I want to keep the data in GPU RAM without having it transfer to CPU RAM between passes.
2. Does it use texture units?  I see a 2D array example in the video, but it's not clear if it uses a texture.  Textures are different in that they are organized in memory as 2D tiles instead of 1D rows -- this improves cache usage when your algorithm has 2D access patterns.
3. Does it support SIMD and easy shuffles?
4. Are there any things you can do in GPGPU languages that you can't do in AMP, or that AMP makes more difficult?
5. How does performance compare to writing directly in a GPGPU language?

I'll be interested to see if GCC and ICC implement this extension.  Lots of work but possibly well worth it.  For now, it sounds like a great way to quickly add some GPU support to apps intended for Windows Vista and up.  For anything truly portable, OpenCL will remain king.

Does AMP support all the GPU-specific stuff, like math function builtins and texture units?  How about 2D/3D data?  Can I specify that a buffer should stay in GPU memory (or to be generic: in the memory closest to the execution unit), so it's not passed back to system RAM in a multi-pass function?  Exciting!

Downloading the video right now.  Been waiting for this all day

1 hour ago, new2STL wrote

@PhrostByte:

*snip*. I think what you want is support for vectorization/vectorization library. Yea, vectorization support are nice but the ones I see around (gcc, Intel) still very close to C + compiler extensions. I hope things begin to get better after the C++ and GPU talk in the C&B and in the AMD Fusion Developer's Conference.

Actually I love the intrinsic header files (and it is the only way mix assembler code from 64bit), but I'm suspect to talk about it (I'm that type of crazy dev who like to "brush bits" sometimes )

Sadly most existing libraries are too inflexible or require you to jump out of C++ and use some other language to define the vector bits.

I'm not convinced GPU stuff like AMP will help at all for SIMD on the CPU -- GPU and CPU design are just too different.  CPU requires a much more careful design, where an algorithm might look completely different between SSE2, SSE4, and AVX instruction sets.  GPU still requires a careful design, but in wildly different areas.