Message
From
26/06/2001 16:59:46
To
26/06/2001 15:34:30
Miscellaneous
Thread ID:
00523643
Message ID:
00523847
Views:
25
>>>From the VFP web site:
>>>
>>>Why would I build a component in Visual FoxPro when I can build the same component in Microsoft Visual Basic® or Microsoft Visual C++®?
>>>
>>>Visual FoxPro components are extremely fast, thanks to the data-centric language of Visual FoxPro and its ability to quickly retrieve and manipulate data. Further, Visual FoxPro can build character strings very swiftly. A Visual FoxPro component that works with data and returns HTML will, therefore, be very fast.
>>>
>>>Visual FoxPro also has object-oriented programming capabilities, including inheritance. This provides a high degree of reuse across applications. A Visual FoxPro developer can create a set of classes that includes the core functionality of a Web database component, so that code will not need to be rewritten each time a component is needed in a Web application. The developer can simply create a component that inherits the base functionality, and then add application-specific code to it.
>>>
>>>Finally, building COM components in Visual FoxPro is an excellent way to reuse existing code. Code that is already written and tested can be built into a component, rather than being recreated in another language.
>>>
>>>
>>>http://msdn.microsoft.com/vfoxpro/prodinfo/qa.asp
>>
>>Wasn't string-manipulation the theme for last year's VFP vs. VB showdown in the off.ramp at devx? Or was that combined with low-level file functions?
>
>Yeah, but it was heavily weighted in VB's favor. The challenge combined file I/O and string manipulation. Among other things, VB had the advantage in the file I/O area since the test involved opening a file of a given structure, one of who's members was an IEEE format 8 byte double precision floating point number. I think also that there was some array stuff involved with the array being in excess of 65,000 elements.
>
>>In any case, in the context of generating HTML from VFP cursors I can see how VFP would be faster. I guess a test is at hand.
John K. walked into an ambush there!
I would agree that with more business-like data types and no file I/O involved (as is commonly the case when generating HTML from cursor data) VFP should have the edge.
>>>
>>>Why would I build a component in Visual FoxPro when I can build the same component in Microsoft Visual Basic® or Microsoft Visual C++®?
>>>
>>>Visual FoxPro components are extremely fast, thanks to the data-centric language of Visual FoxPro and its ability to quickly retrieve and manipulate data. Further, Visual FoxPro can build character strings very swiftly. A Visual FoxPro component that works with data and returns HTML will, therefore, be very fast.
>>>
>>>Visual FoxPro also has object-oriented programming capabilities, including inheritance. This provides a high degree of reuse across applications. A Visual FoxPro developer can create a set of classes that includes the core functionality of a Web database component, so that code will not need to be rewritten each time a component is needed in a Web application. The developer can simply create a component that inherits the base functionality, and then add application-specific code to it.
>>>
>>>Finally, building COM components in Visual FoxPro is an excellent way to reuse existing code. Code that is already written and tested can be built into a component, rather than being recreated in another language.
>>>
>>>
>>>http://msdn.microsoft.com/vfoxpro/prodinfo/qa.asp
>>
>>Wasn't string-manipulation the theme for last year's VFP vs. VB showdown in the off.ramp at devx? Or was that combined with low-level file functions?
>
>Yeah, but it was heavily weighted in VB's favor. The challenge combined file I/O and string manipulation. Among other things, VB had the advantage in the file I/O area since the test involved opening a file of a given structure, one of who's members was an IEEE format 8 byte double precision floating point number. I think also that there was some array stuff involved with the array being in excess of 65,000 elements.
>
>>In any case, in the context of generating HTML from VFP cursors I can see how VFP would be faster. I guess a test is at hand.
John K. walked into an ambush there!
I would agree that with more business-like data types and no file I/O involved (as is commonly the case when generating HTML from cursor data) VFP should have the edge.