Ve lo scrivo quì poi magari spostatelo...(anche a Redmond si parla di TDD)

[Gammaglobulino]

Questo è un corso per dipendenti.... guardate chi lo fa?


Driving Development with Tests
____________
Delivery: Tuesday, October 25, 10:00 A.M. - 11:30 A.M., 34/2615 (Quinalt), Corporate Main Campus maps
Discipline focus: Development, testing, and Web development*
Registration URL: submit Registration alternative: waiting lists FAQ: known issues
Materials: Handouts will not be provided. Materials links will be posted to the registration site when available.
Remote access: An online recording will be available 3 days afterward on the registration page. The videotape will be available 1 day afterward.
____________
Presenter: James Newkirk, group program manager, MSCOM Experience Platform & Solutions (MXPS)
Description: Test-driven development (TDD) is defined as driving software development with automated tests. Most people who learn TDD find that it changes the way they program for the better. "Test infected" is the phrase Erich Gamma uses to describe this change in programming practice.
This session:
§ Provides an introduction to TDD.
§ Demonstrates how it works using a straightforward process.
§ Describes the benefits that you can achieve through test-driven development
Topic-related resource: “Test-Driven Development in Microsoft .NET,” James Newkirk and Alexei Vorontsov; and [email protected]

[fek]

Era ora visto che avete scazzato con il VS2005 e lo unit testing. Non vorrei che dopo aver perso Ward se ne andasse anche Newkirk

(premio post caustico 2005)

[Imparate, si scrivono cosi' i topic antiMS]

[Gammaglobulino]

Originariamente inviato da fek

Era ora visto che avete scazzato con il VS2005 e lo unit testing. Non vorrei che dopo aver perso Ward se ne andasse anche Newkirk

(premio post caustico 2005)

[Imparate, si scrivono cosi' i topic antiMS]

Con tutti i soldi che prende .... figurati

Ragazzi non lo faccio più giuro ma vi devo postare una cazziata (e non è l'unica.. so come cane e gatto) di Stan Lippman (C++ Primer) a Herb Sutter ) enjoy:


##############################################


No, I disagree completely. The only place to put an object is on the stack



int I;

int *pi;

int &ri = I;

int ia[10];

int (*ip)() = foo();



each of these puppies is allocated the space necessary for its type for an established extent – in this case, all but one is 4 bytes and all exist on the portion of the machine defined by the stack. An object is not an object, but an object is defined by the language – which is an artificial construct. you’re being rhetorical when you say, an object is an object. That has no meaning.







-------------------------------------------------------

Stan Lippman

http://blogs.msdn.com/slippman






--------------------------------------------------------------------------------

From: Herb Sutter
Sent: Thursday, September 01, 2005 1:04 PM
To: Stan Lippman; Yves Dolce; Keiji Oenoki
Cc: David Schwartz (VCUE); C++ Language Designers
Subject: RE: how does this work: auto_handle



We should chat about it sometime. I think you’re right that a whiteboard would help. Just to respond here, though:



So, you have no choice about N – it is on the stack because that is the fundamental essence of an object in C++ -- if you want it somewhere else, you must modify its definition – that is, N* is a pointer, N& is a ephemeral pointer, N[] is a pointer to an array, and N() is a pointer to a function.



To me, this sounds like it confuses programming model abstractions with their syntax and/or implementation. An object is an object.



1. Syntax (“N n; is the natural syntax”): If you’re claiming that the essence of an N object is to exist on the stack just because that’s the tersest (and arguably default) syntax, note that you can make the same syntax argument to say that the fundamental essence of an object in C++ is to be a directly embedded member in another object (e.g., class C1 { C2 member; … }. That’s the same syntax. I think we’d agree that’s not true, and that holding a member by value vs. by pointer or reference is simply one of the choices, right?



2. Implementation (e.g., someone could say “but every C++ implementation uses a stack, that’s fundamentally natural”): You can implement C++ without placing any object physically on the stack. In the C++ programming model, the stack itself is an abstraction, and you could have a 100% conforming native C++ implementation that supported all native C++ stack-based semantics (i.e., provided the stack abstraction from the programmer’s point of view, with stack-based expression of the bounds on an object’s lifetime) without the implementation actually putting any program objects on any stack under the covers anywhere at all (e.g., the compiler could put everything physically on the heap, and simply automatically call delete at the right times such as block ends).



There no “natural” location for an object of a given type. If there were, the constructor would take a location, and objects would be able to tell whether they were put on the stack or not. It does not, and they cannot. Statements like stack and member variable declarations and new-expressions, which are what determine placement, all go call the same constructor. The object certainly doesn’t care where it sits, and can’t tell. C and C++ syntax happens to be tersest when there’s no indirection involved, but that’s mere syntax.



So I don’t agree that an N or an R (or an object or any other type) has any “natural” location at all in the programming model. Yes, down in the implementation, there may be different implementation techniques for different types for where the compiler decides to put them (e.g., based on constraints in the implementation platform), but that’s purely an implementation detail and separate from the abstraction in the programming model.



An object is an object. Recognizing that, and having a language design that applies features uniformly across the type system, for all objects regardless of what type they are (which we did, only we didn’t have time to implement everything in Whidbey, such as “gcnew N”), is one of the primary design elegances of C++/CLI. When we do N^, you can put an N on the gc heap just as naturally as you can put an R on the gc heap, just as today you can put an R on the stack as naturally as you can put an N there.



Herb

[Gammaglobulino]

scusate tutto è partito da questo
Fra scusa se ho sbordato sul forum


From: Stan Lippman
Sent: Thursday, September 01, 2005 12:03 PM
To: Herb Sutter; Yves Dolce; Keiji Oenoki
Cc: David Schwartz (VCUE); C++ Language Designers
Subject: RE: how does this work: auto_handle



You asked:

My question is, why have both



For the same reason we have N on the stack and auto_ptr on the stack.



No, I’m sorry. Bjarne made a deliberate decision to allow polymorphic objects on the stack, based on his experience with Simula, and his need to coexist with C. So, you have no choice about N – it is on the stack because that is the fundamental essence of an object in C++ -- if you want it somewhere else, you must modify its definition – that is, N* is a pointer, N& is a ephemeral pointer, N[] is a pointer to an array, and N() is a pointer to a function.



That is, in C++, either you have an object in hand – or you have a pointer of some various entity – object, contiguous memory of some extent, or code. there are two variety of pointers – a soft pointer, the C pointer, and the harsh pointer, the C++ reference, which Bjarne invented out of thin air, as far as I can tell.



The CLI has a completely different view of types, and you are confusing the C/C++ type system with the CLI system. There is no analogy, except in your mind. It’s very confusing to my mind – because the natural state of a reference object is R^ -- that is, R^ is to N, not R is to N – that is not correct. I’m sorry to disagree with you, but that is a fundamental difference – i don’t believe an email exchange will change our positions. I just think you are wrong here. J





stan

[cionci]

Lo sposto