Ĺadny brzuch
Mam pytanie...
czy jest sens uczyć sie porządnie C++ i WinAPI ze względu na zbliżający sie czas wprowadzenia procesorów 64 bitowych?
Czy np.:
#include <iostream> using namespace std; int main(){ cout << "Hello World " << endl; return 0 }
Będzie wyglądał inaczej?
a czy program w WinAPi:
#include #include <windows.h> /* Declare Windows procedure */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /* Make the class name into a global variable */ char szClassName[ ] = "WindowsApp"; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nFunsterStil) { HWND hwnd; /* This is the handle for our window */ MSG messages; /* Here messages to the application are saved */ WNDCLASSEX wincl; /* Data structure for the windowclass */ /* The Window structure */ wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ wincl.style = CS_DBLCLKS; /* Catch double-clicks */ wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; /* No menu */ wincl.cbClsExtra = 0; /* No extra bytes after the window class */ wincl.cbWndExtra = 0; /* structure or the window instance */ /* Use Windows's default color as the background of the window */ wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let's create the program*/ hwnd = CreateWindowEx ( 0, /* Extended possibilites for variation */ szClassName, /* Classname */ "Windows App", /* Title Text */ WS_OVERLAPPEDWINDOW, /* default window */ CW_USEDEFAULT, /* Windows decides the position */ CW_USEDEFAULT, /* where the window ends up on the screen */ 544, /* The programs width */ 375, /* and height in pixels */ HWND_DESKTOP, /* The window is a child-window to desktop */ NULL, /* No menu */ hThisInstance, /* Program Instance handler */ NULL /* No Window Creation data */ ); /* Make the window visible on the screen */ ShowWindow (hwnd, nFunsterStil); /* Run the message loop. It will run until GetMessage() returns 0 */ while (GetMessage (&messages, NULL, 0, 0)) { /* Translate virtual-key messages into character messages */ TranslateMessage(&messages); /* Send message to WindowProcedure */ DispatchMessage(&messages); } /* The program return-value is 0 - The value that PostQuitMessage() gave */ return messages.wParam; } /* This function is called by the Windows function DispatchMessage() */ LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) /* handle the messages */ { case WM_DESTROY: PostQuitMessage (0); /* send a WM_QUIT to the message queue */ break; default: /* for messages that we don't deal with */ return DefWindowProc (hwnd, message, wParam, lParam); } return 0; }
Będzie ywglądał inaczej? Prosże o odpowiedź (może jakies przykłady)?
Najprawdopodobniej (99%) nic się nie zmieni. Tak jak z resztą od zawsze...
Może tylko się zmienić system optymalizacji kodu pod 64-bity, ale to i tak nie wpływa na poprawność kodu.
generalnie jak chodzi o same procesory to nie. one nei zmienią w programach nic. już prędzej systemy operacyjne 64-bit a nie zanosi się żeby szybko się to zmieniło.
przecież już obecnie są procki 64-bit i jakoś można na nich pracować normalnie w środowisku 64 - bit
Napewno jak bedziesz pisał gre standardowo (32bit) to na prockach 64bitowych i dwórdzeniowych to nie wykożystasz w pełni możliwości mocy obliczeniowej procesora ponieważ gra ta będzie wykożystywała tylko 1 rdzeń.
Nie wiem jak sprawa ma sie w programach użytkowych.
Hmm to kwestia czasu kiedy bedzie 99% kompilatorow optymalizowalo kod pod 64 bitowe procki :)
Nie wiem jak sprawa ma sie w programach użytkowych.
Hmm to kwestia czasu kiedy bedzie 99% kompilatorow optymalizowalo kod pod 64 bitowe procki :)
Z tym się zgodzę i dodam, że wedłóg mnie chodzi tu głównie o optymalizację kodu w czasie translacji z języka wysokiego poziomu do języka maszynowego (rozkazy przenoszenia spakowanych 64-bitowych zmiennych).
identycznie - tyle ze tutaj ta moc nie jest tak potrzebna :)
hmm... ;) wydaje mi się że z tymi programami użytkowymi to tak nie do końca - chodzi mi o np. DXP Protel'a 2004, albo o 3DS. Przy nich duża moc procesora jest jak najbardziej wskazana...
Pozdro!
zanotowane.pl doc.pisz.pl pdf.pisz.pl zsf.htw.pl
czy jest sens uczyć sie porządnie C++ i WinAPI ze względu na zbliżający sie czas wprowadzenia procesorów 64 bitowych?
Czy np.:
#include <iostream> using namespace std; int main(){ cout << "Hello World " << endl; return 0 }
Będzie wyglądał inaczej?
a czy program w WinAPi:
#include #include <windows.h> /* Declare Windows procedure */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /* Make the class name into a global variable */ char szClassName[ ] = "WindowsApp"; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nFunsterStil) { HWND hwnd; /* This is the handle for our window */ MSG messages; /* Here messages to the application are saved */ WNDCLASSEX wincl; /* Data structure for the windowclass */ /* The Window structure */ wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ wincl.style = CS_DBLCLKS; /* Catch double-clicks */ wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; /* No menu */ wincl.cbClsExtra = 0; /* No extra bytes after the window class */ wincl.cbWndExtra = 0; /* structure or the window instance */ /* Use Windows's default color as the background of the window */ wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let's create the program*/ hwnd = CreateWindowEx ( 0, /* Extended possibilites for variation */ szClassName, /* Classname */ "Windows App", /* Title Text */ WS_OVERLAPPEDWINDOW, /* default window */ CW_USEDEFAULT, /* Windows decides the position */ CW_USEDEFAULT, /* where the window ends up on the screen */ 544, /* The programs width */ 375, /* and height in pixels */ HWND_DESKTOP, /* The window is a child-window to desktop */ NULL, /* No menu */ hThisInstance, /* Program Instance handler */ NULL /* No Window Creation data */ ); /* Make the window visible on the screen */ ShowWindow (hwnd, nFunsterStil); /* Run the message loop. It will run until GetMessage() returns 0 */ while (GetMessage (&messages, NULL, 0, 0)) { /* Translate virtual-key messages into character messages */ TranslateMessage(&messages); /* Send message to WindowProcedure */ DispatchMessage(&messages); } /* The program return-value is 0 - The value that PostQuitMessage() gave */ return messages.wParam; } /* This function is called by the Windows function DispatchMessage() */ LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) /* handle the messages */ { case WM_DESTROY: PostQuitMessage (0); /* send a WM_QUIT to the message queue */ break; default: /* for messages that we don't deal with */ return DefWindowProc (hwnd, message, wParam, lParam); } return 0; }
Będzie ywglądał inaczej? Prosże o odpowiedź (może jakies przykłady)?
Najprawdopodobniej (99%) nic się nie zmieni. Tak jak z resztą od zawsze...
Może tylko się zmienić system optymalizacji kodu pod 64-bity, ale to i tak nie wpływa na poprawność kodu.
generalnie jak chodzi o same procesory to nie. one nei zmienią w programach nic. już prędzej systemy operacyjne 64-bit a nie zanosi się żeby szybko się to zmieniło.
przecież już obecnie są procki 64-bit i jakoś można na nich pracować normalnie w środowisku 64 - bit
Napewno jak bedziesz pisał gre standardowo (32bit) to na prockach 64bitowych i dwórdzeniowych to nie wykożystasz w pełni możliwości mocy obliczeniowej procesora ponieważ gra ta będzie wykożystywała tylko 1 rdzeń.
Nie wiem jak sprawa ma sie w programach użytkowych.
Hmm to kwestia czasu kiedy bedzie 99% kompilatorow optymalizowalo kod pod 64 bitowe procki :)
Nie wiem jak sprawa ma sie w programach użytkowych.
Hmm to kwestia czasu kiedy bedzie 99% kompilatorow optymalizowalo kod pod 64 bitowe procki :)
Z tym się zgodzę i dodam, że wedłóg mnie chodzi tu głównie o optymalizację kodu w czasie translacji z języka wysokiego poziomu do języka maszynowego (rozkazy przenoszenia spakowanych 64-bitowych zmiennych).
identycznie - tyle ze tutaj ta moc nie jest tak potrzebna :)
hmm... ;) wydaje mi się że z tymi programami użytkowymi to tak nie do końca - chodzi mi o np. DXP Protel'a 2004, albo o 3DS. Przy nich duża moc procesora jest jak najbardziej wskazana...
Pozdro!