Russell Hadley: The Route to C++ Code Optimization

The Spec# programming system is a new attempt at a more cost effective way to develop and maintain high-quality software. Spec# is pronounced "Spec sharp" and can be written (and searched for) as the "specsharp" or "Spec# programming system". The Spec# system consists of:
A unique feature of the Spec# programming system is its guarantee of maintaining invariants in object-oriented programs in the presence of callbacks, threads, and inter-object relationships.
The Spec# programming system is being developed as a research project at Microsoft Research in Redmond, primarily by the
Programming Languages and Methods group.
Here, Expert to Expert guest expert and programming language guru Erik Meijer chats with MSR researchers and spec# designers Wolfram Schulte, Rustan Leino and Peter Mueller. We dig into the details of Spec# and contract oriented programming in general. Plenty
of code on the screen and lots of deep conversation. Just how we like it for Going Deep and Expert to Expert.
Enjoy!
LOW RES FILE
MP4
ZUNE
Intersting Stuff. The media length looked too much but it was a short discussion at the end with many things left unaddressed.
Handling Overloaded Function
For overloaded function(s), there must be a single case specification, or each function must be addressed seperately.
Moreover, Unlike Java, C# allows funtion overloading based upon return types, which When called in code, tend to confuse reader/compiler.
For example,to multiply 2 integers, a class can include following overloaded functions:
..
int mult(int, int); // call if result is less than max (int), return int
long mult(int, int); // call if max (int) <=result<=max (long), return long
float mult(int, int); // call if max (long) <=result<=max (float), return float
double mult(int, int); // call if max (long) <=result<=max (double), return double
...
Compiler Intelligence conflicting software design principles
This is a Programmer responsibility and Compiler responsibility case, that is, what a programmer need to specify and what a compiler must assume.
This C/C++ code is self explanatory without any documentation/comments
...
unsigned x=[some expresion];
..
if (x)
...
...
The C/C++ compilers are intelligent enough to assume that condition will execute if x is a positive integer, and Java/ C# compilers require an explicit condition for that adding burden to programmer.
A fun case
As discussedm, Spec is applied on C code to catch/handle every possible case. Learning the languaage, this is the first piece of code developers eneter:
#include <stdio.h>
int main()
{
printf("xyz"); //xyz can be any string
return 0;
}
Going deep in the language, at a stage programmer discover that printf() in fact returns a value, which is usually a positive integer but in the most rare case, it can be negative indicating an exception. Applying spec on rare cases like this, perhaps once
in a lifetime sort of case...
adamjcooper wrote:Hi littleguru,
There are two Design by Contact frameworks I know of that you can use today in C#. They both enforce checks at runtime, but take very different approaches and will appeal to very different audiences.
...
Adam.
umer_a wrote:Compiler Intelligence conflicting software design principles
This is a Programmer responsibility and Compiler responsibility case, that is, what a programmer need to specify and what a compiler must assume.
This C/C++ code is self explanatory without any documentation/comments
...
unsigned x=[some expresion];
..
if (x)
...
...
The C/C++ compilers are intelligent enough to assume that condition will execute if x is a positive integer, and Java/ C# compilers require an explicit condition for that adding burden to programmer.
umer_a wrote:That was about compiler efficiency and intelligence, i.e., a compiler intelligent enough to assume certain conditions. You can say limiting a programmer creativity by restricting to a certain struct like bool or allowing him the choice of using bool if required.
The code provided requires two explicit test conditions to be entered in Java/C# compilers and your question will still remain unanswered.
if (S_OK)
....;
else if (S_FAIL)
......;
In Java/C#
....; //get some value for x somehow
if (x==S_OK)
....;
else if (x==S_FAIL)
....;
In both versions, you cannot answer unless you have some hint on constants, but at least one extra statement and two explicit test conditions due to developer in Java/C# version.
The first question people have regarding contracts is, why bother? The speakers addressed this by explaining how much money Microsoft saved in manual testing time. But there are other savings as well.
By specifying assumptions explicitly, the design improves. You move from fuzzy verbal communication to concise, precise communication about the behavior and expectations of code. This has the same benefits as writing documentation before code, or writing tests
before code. It clarifies the design.
Even without compile-time or run-time contract checks, a contract allows one to view classes or methods as black boxes with precise behavior, ignoring internal details. This helps to logically determine if a design functions correctly.
Another benefit is reduced debugging time. If you use only run-time contract checks, you eliminate the time normally spent trying to narrow down a bug -- you find it earlier, before it is manifested in peculiar ways. If you have compile time checking as well,
as in spec#, the same bug would never occur -- it would spotted by the compiler.
The work done by the spec# group is important. I hope it goes into products as soon as possible.
littleguru wrote:Still, you didn't answer the question on S_OK and S_FAIL and therefore I will tell you what they are: S_OK == 0 and S_FAIL == 1 - interesting, isn't it?
umer_a wrote:
littleguru wrote:
Still, you didn't answer the question on S_OK and S_FAIL and therefore I will tell you what they are: S_OK == 0 and S_FAIL == 1 - interesting, isn't it?this is platform specific code, or constants defined on a specific platform, the same constants may have different value in C/C++ compiler running on Linux/Solaris or some other platform or they might not exist at all. We were never interested in win32 or platform specific discussion, here.
aJanuary wrote:"Is this based on C# 3.0? or is this an invariation of C# 2.0?"
From what I remember from other interviews it is based on C# 2.0.
Another interesting interview (which I think is where I got the above from) can be found at http://www.hanselminutes.com/default.aspx?showID=128
vesuvius wrote:
aJanuary wrote:
"Is this based on C# 3.0? or is this an invariation of C# 2.0?"
From what I remember from other interviews it is based on C# 2.0.
Another interesting interview (which I think is where I got the above from) can be found at http://www.hanselminutes.com/default.aspx?showID=128
I really don't see what the obsession with whether it's a .NET 2.0 or 3.0 invariant.
A quick read of the Spec # website tells you that that it is an extension (Variation) of the C# language, so using the word invariant is incorrect. Use the word invariant with Objects when programming Spec#.
Furthermore, the Research Team utilise MSIL, so there is no reason that is unimplemantable in Visual Basic or other .NET aware language. If you or steveo_ are that curious install the Spec# VS2005 or 2008 versions from the website, and have a quick check to see whether you can write/use extension methods, automatic properties, partial methods anonymous types or object initialisers. That should satisfy your curiosity, although the 'meat and potatoes' is definitely with object invariants (.NET 2.0 and 3.0 both have objects - and nulls) so I would certainly deem this a curiosity, but wholly inconsequential to understanding Spec#.
stevo_ wrote:
vesuvius wrote:
aJanuary wrote:
"Is this based on C# 3.0? or is this an invariation of C# 2.0?"
From what I remember from other interviews it is based on C# 2.0.
Another interesting interview (which I think is where I got the above from) can be found at http://www.hanselminutes.com/default.aspx?showID=128
I really don't see what the obsession with whether it's a .NET 2.0 or 3.0 invariant.
A quick read of the Spec # website tells you that that it is an extension (Variation) of the C# language, so using the word invariant is incorrect. Use the word invariant with Objects when programming Spec#.
Furthermore, the Research Team utilise MSIL, so there is no reason that is unimplemantable in Visual Basic or other .NET aware language. If you or steveo_ are that curious install the Spec# VS2005 or 2008 versions from the website, and have a quick check to see whether you can write/use extension methods, automatic properties, partial methods anonymous types or object initialisers. That should satisfy your curiosity, although the 'meat and potatoes' is definitely with object invariants (.NET 2.0 and 3.0 both have objects - and nulls) so I would certainly deem this a curiosity, but wholly inconsequential to understanding Spec#.
Pretty ironic post to say you summed up "why ask a question when you can google it" with an overzealous post.. its almost on the level of quoting someone with "stop spamming"...
Believe it or not, people actually want to discuss and show interest.. not just watch then google the rest.. I wanted to post mainly to show that I appreciated their time to do the video, and to work on spec# in the first place..
And for the record, its pretty obvious why someone may ask, is this based on c# 2 or 3, since no point did it state this was an extension to c# in general, vs a sort of 'branch'..
vesuvius wrote:
I did not Google it, I simply read what Charles posted. If you read that initial post, you will find that that's where I extrapolated my info. There is a very clear link to the Spec# site with additional info posted by Charles.
Other information was deduced from watching the video, and my post remains correct. Your clearly misunderstood the meaning and usage of the word invariant, and are "barking up the wrong tree" with regard to .NET 2.0 and .NET 3.0 as their are inconsequential.
How can you show appreciation for watching the video by going ahead and showing you misunderstood it? These are pretty smart guys, and I find it offensive you'd see it as important to ask such misconstructed information.
Read Charles's initial post properly. Don't try save face posting ambiguous and poorly explained posts. I have made myself abundantly clear.
aJanuary wrote:"Is this based on C# 3.0? or is this an invariation of C# 2.0?"
From what I remember from other interviews it is based on C# 2.0.
Another interesting interview (which I think is where I got the above from) can be found at http://www.hanselminutes.com/default.aspx?showID=128