C / C++ / MFC

kilt wrote:

This has no sense at all.
You can do it with 10 lines of code with COM (or UDLTF)

kilt wrote:

You can do it with 10 lines of code

kilt wrote:

This has no sense at all.

#include "afxinet.h"
...
BOOL GetPageSource(CString& url, CString& source){
	CInternetSession ises;
	CFile* file=new CFile();
	try{//There might occur a connection error
	  file=ises.OpenURL(url);//CInternetSession::OpenURL(url) returns a source code in CHttpFile;
	}
	catch(CInternetException* e){ //If an error occured, show messagebox with errorcode
		CString error=L"";
		error.Format(L"Connection error!\nError code: %ld",e->m_dwError);
		AfxMessageBox(error);
		return FALSE;
	}
	UINT len=1024;
	char buf[1024];
	source=L"";
	while(len>0){
		len=file->Read(buf,1024);
		if(len>0)source.Append(CString(buf),len);
	}
	file->Close();
	ises.Close();
	return TRUE;
}

__erfan__ wrote:

if you find that please let me know

Rationale and Examples
This is especially important to break long dependency chains into smaller executing units in floating-point code, whether it is mapped to x87, SSE, or SSE2 instructions, because of the longer latency of
floating-point operations. Because most languages (including ANSI C) guarantee that floating-point expressions are not reordered, compilers cannot usually perform such optimizations unless they offer a switch to allow noncompliant reordering of floating-point expressions according to algebraic rules.
Reordered code that is algebraically identical to the original code does not necessarily produce identical computational results due to the lack of associativity of floating-point operations. There are
well-known numerical considerations in applying these optimizations (consult a book on numerical analysis). In some cases, these optimizations may lead to unexpected results. In the vast majority of
cases, the final result differs only in the least-significant bits.

Listing 10. Avoid

double a[100], sum;
int i;
sum = 0.0f;
for (i = 0; i < 100; i++) {
   sum += a[i];
}

Listing 11. Preferred

double a[100], sum1, sum2, sum3, sum4, sum;
int i;
sum1 = 0.0;
sum2 = 0.0;
sum3 = 0.0;
sum4 = 0.0;
for (i = 0; i < 100; i + 4) {
   sum1 += a[i];
   sum2 += a[i+1];
   sum3 += a[i+2];
   sum4 += a[i+3];
}
sum = (sum4 + sum3) + (sum1 + sum2);

Notice that the four-way unrolling is chosen to exploit the four-stage fully pipelined floating-point adder. Each stage of the floating-point adder is occupied on every clock cycle, ensuring maximum sustained utilization.

Snakefoot wrote:

Notice that the four-way unrolling is chosen to exploit the four-stage fully pipelined floating-point adder.