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.

posted by PhrostByte

posted by PhrostByte

posted by PhrostByte

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

posted by PhrostByte

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.

posted by PhrostByte

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.

posted by PhrostByte

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.

posted by PhrostByte

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?

posted by PhrostByte

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

posted by PhrostByte

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.

posted by PhrostByte

• 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 better way to use SIMD intrinsics.  They're kind of a pain right now and I think it could be made much much better, to express it as native C++.  PPL is hyped as a way to better utilize your CPU, while a lot of people are still missing out on 2x-20x increases SIMD can provide to certain problems!
• 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.

posted by PhrostByte

Happy to hear that concepts and polymorphic functions are still on the plate.  Thanks for all your hard work -- looking forward to playing with it when compilers catch up.

posted by PhrostByte

Basically instead of

[](int i) { return i * 2; }

You would have:

[](i) { return i * 2; }

Which would generate a functor that takes a parameter 'i' of any type -- equivalent to this:

struct func
{
   template<typename T>
   auto operator()(T i) -> decltype(i * 2) { return i * 2; }
}; 

These are called polymorphic lambdas.  They were discussed for C++0x but dropped as it was decided to be too complex to implement in a way compatible with Concepts (which were themselves removed).  I'm hoping to see it in a future standard.

posted by PhrostByte

var enumerable = foo.Select(x => x.y).OrderByDescending(y => y.z);

VS (made as good as I could think)

auto range = from(foo.cbegin(), foo.cend()).select([](my_struct const &x) { return x.y; }).sort_desc([](my_sub_struct const &y) { return y.z; });

Now think of all the extra typing you'd have to do for a longer, more complex query with Join() etc. -- it's not nearly as concise.  We don't have anonymous types either, so for some queries things might need to be declared outside of the query.  What I wrote there is certainly doable, though, and would likely perform significantly better than the equivalent LINQ.

I wish C++0x allowed shorter lambdas that didn't specify parameter types -- it could work if they boiled down to a template functor that takes any argument type.

posted by PhrostByte

I don't think it would be easy for a C++ GC to reach the performance of the .NET GC, because .NET is so much stricter about what you can do with an object, ie. there's nothing stopping me from holding a pointer to a member of an object and using an offset to compute the actual object's address.  I believe the .NET GC also defragments the heap, seems unlikely with C++.

posted by PhrostByte

And a slight correction: having the same initialism is fun, but shared_ptr etc. were not added to SGI's Standard Template Library, but to the C++ Standard Library.

posted by PhrostByte

#define _CRT_SECURE_NO_WARNINGS
#define _SCL_SECURE_NO_WARNINGS

#ifndef _DEBUG
#define _SECURE_SCL 0
#endif

#define NOMINMAX

posted by PhrostByte

posted by PhrostByte

posted by PhrostByte

posted by PhrostByte

posted by PhrostByte