Comments

Good video.

littleguru wrote:

I would like to know how you guys make sure that function a(i) isn't calling a x(...) that relies on a global variable (like a singleton).

That's an interesting thought. I have no particular insight into the answer, but I'm guessing it would be quite difficult to implement due to at least a couple reasons:

a) To generalize your question (correctly, I hope), it's not just globals that are a concern, it's any shared state--is your lambda expression using shared state in a thread-safe fashion? Here's a simple non-global example:

    R r = new R();
    Parallel.For(0, 1000, 
        i => {
            int v = r.Next(1, 6);
            ...
        });

Here we have N threads accessing r. How do you determine whether r is being used in a thread-safe manner? If you know that class R is not thread-safe, then this code isn't either. But how would a compiler or runtime determine whether this is safe, through static or run-time analysis of all the possible code paths? This seems to me to be a rather difficult problem.

b) Aside from the difficultly of analyzing the code, how do you define what's "correct?" If I substitute a thread-safe class for R how would you now determine that the use of r is now thread-safe? Perhaps analysis would show the use of a locking mechanism? What if the new class is written using a lockless technique, how would you determine whether it's safe or not?

As mentioned in the video some problems require shared state and some problems don't. For example, consider applying update operations to a graph in parallel. Shared state isn't a side effect here; in fact, the whole point is to update shared state. How would analysis take that into account?

It's an interesting thought, though.

stevetei wrote:

...we know that C++ developers are secure and self-confident in their own coolness and don't need all of that public relations stuff to tell them they're cool. 

I like to think we're also less distracted by bright, shiny objects.

Great video!

FWIW, the WMA/MP3 link buttons are reversed.

TomS wrote:



Seriously, I couldn't take more than few minutes of this guy.

I took 31 minutes of it and think Ron did an adequate job of simplifying or digging deeper when Chris' answers sounded opaque or insubstantial. Some parts of this business involve a lot of new terminology, architecture and SOA being among them.

Nice interview.

Charles,

When you mention creating a Media Center add-in for C9, can I assume that you folks are planning on using Vista's RSS engine to download the C9 Videos feed (maybe Podcasts, too) and using the RSS engine's capability to automatically download the video file (background transfer via BITS, of course) and make that available for viewing?

Please?

Just an idea I've had.

Nice interview on both sides of the camera.

Robert, good luck on your new venture! And the one beyond that, and the one beyond that, and the one beyond that!

leighsword wrote:

Thanks, MS seems evil, but their employees have always been care about their customers.

Martyn, I think that's a compliment.

leighsword wrote:

Here I have a problem on sizeof. the following foo shows szDen[] and strDen[] both are the same array, why sz != sz1?

sz is the size of the character array you've declared on the stack. sz1 is the size of the char* you've passed to the function. You've declared it as char[], but the compiler really passes a char*, not the full array. Someone (Sven?) can probably put that in C++ specification-compliant terms.

leighsword wrote:

And what’s the difference between strcpy_s and strncpy and memcpy?

It's probably better to compare strncpy_s to strncpy since they do the same thing. (strcpy_s copies a whole string, strncpy copies N characters.)

strncpy_s returns error information where strncpy does not. It's difficult to write "good" code with strncpy (where "good" means checking for errors). strncpy does not return an error code because it doesn't know the size of the output buffer.

EDIT: Oh, and memcpy is ignorant of types and their sizes. It copies bytes, not characters. With it you can do things like:

    int i;

    memcpy(&i, "Hello, world", sizeof(i));

Which you just about never want to do. If you know you're copying strings, use the string functions--the compiler can do more type checking for you.

leighsword wrote:

char* strcopy(char strDen[]/*char* strDen*/, const char* strSou)
{
     size_t sz1 = sizeof(strDen);  //sz1 always be 4?
     _ASSERT(szDen && sizeof(strDen) >= strlen(strSou));
     char* p = NULL;
     for(p = strDen;*strDen++ = *strSou++; );
     return p;
}

int _tmain(int argc, _TCHAR* argv[])
{
     char szDen[6];
     size_t sz = sizeof(szDen); //sz == 6
     memset(szDen, 0, sizeof(szDen))
     strcopy(szDen, "hello");
     return 0;
}

Karim wrote:

Once I'm at the point where I can describe the problem in my own words, the customer's eyes light up and they go "Yes!  Finally, someone who understands the problem." 

Isn't that the funnest reaction? It's strongest when the customer can't quite clearly describe the problem they're trying to solve and you wrap it up nicely in a little box with a bow and hand it back to them. "Zounds! That's it!"

Some aspects of this field really are satisfying. How odd that it involves people.

Great interview. Good questions, Robert.