>Hi Paul.
>
>>i've looked into C++ and don't see why people would use that.
>
>For three reasons: Portability, control and performance.
>
>C/C++ is still the most portable language available. While you can't necessarily port an entire application easily that depends on a number of external libraries, you can still port any application that just uses the standard libraries to a broad variety of devices ranging from a chip card to a main frame computer.
>
>C/C++ also gives quite a bit of control of how you do things in your application. The only faster option is always assembler. not only only would you loose portability, these days it's also hard to beat C++ compilers with hand-coded assembler code. You have to be a damn good coder to write more optimized code than a C++ compiler produces.
>
>Even though MSIL (.NET) is compiled just in time to native machine code, C++ is usually faster than C#. At least C++ is more reliable fast. With C# (and other .NET) languages you have too many dependencies on the CLR and the .NET framework to confidently write fast code. For example, the following C# program is actually slower than a VFP program doing the same, even though C# is compiled to native machine code whereas VFP is interpreted:
>

>int Count = 0;
>DateTime Start = DateTime.Now;
>while( Start.AddSeconds(5) > DateTime.Now )
>{
>  Count = Count + 1;
>}
>Console.Write( Count );
>

>On my machine, VFP is about 20% faster:
>

>Local lnStart, lnCount
>lnStart = Seconds()
>lnCount = 0
>Do While lnStart+5 > Seconds()
>	lnCount = lnCount + 1
>EndDo
>? lnCount
>

not exact.
seconds() is a internal vfp function,
and from the 23:59:55 it doesn't work anymore.

the exact comparison is with DATETIME()

Local lnStart, lnCount
lnStart = DATETIME()
lnCount = 0
Do While lnStart+5 > DATETIME()
	lnCount = lnCount + 1
EndDo
? lnCount

and I am certain that VFP now loses the competition with C#