🚀 go-pugleaf

On Thu, 29 Dec 2005 02:28:59 +0100, AB wrote:

> j.w.

Cholera, ubiegłeś mnie ;>>>

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Spinacz biurowy, Derek Kuliński / takeda <d.kulinski@gmail.com>!

>> j.w.
> 
> Cholera, ubiegłeś mnie ;>>>

Cześć TaKeDa :)

-- 
Adam Wysocki :: www.gophi.rotfl.pl :: GG: 1234 :: Fidonet: 2:480/138
Koty na przykład kompletnie nie jarają mnie seksualnie.. (C) futszaK
W prezencie dla spamerów: xyguuie@tlmz.brgu.ye phisfkb@saclf.smyd.nu

On Thu, 29 Dec 2005 02:43:58 +0000 (UTC), Adam Wysocki wrote:

>>> j.w.
>> Cholera, ubiegłeś mnie ;>>>
> Cześć TaKeDa :)

Cześć, ja nawet przegapiłem okres kiedy było głosowanie na tą grupę =)
Dopiero zauważyłem, że przeszłą jak TS controla wysłał =)

A żeby być na temat grupy:

Jestem początkującym jeżeli chodzi o asma. Właściwie w tym miesiącu
skończyłem kurs =).

Niestety, nauczyciel aby ułatwić życie postanowił użyć tzw. High Level
Assebler (HLA) heh, nie śmiejcie się, wiem że to coś jak woda w proszku ;)

Niemniej ułatwiło to trochę naukę, np nie trzeba było kombinować aby
wypisać wynik działania programu. No i mam pytanie. Gdy nie zamierzam
używać HLA to jak właściwie prosto wyświetlić wynik programu na konsolę?

Na innej grupie widziałem, już że można zlinkować program do libc i używać
np. printf. Co jest (a przynajmniej wygląda) na proste. Są jeszcze jakieś
inne sposoby aby wyświetlić wynik działania programu?

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Thu, 29 Dec 2005 02:28:59 +0100 jednostka biologiczna o nazwie "AB"
<AB@ab.pl> wyslala do portu 119
jednego z serwerow news nastepujace dane:

>j.w. 

POPJERAM !!!!!111 ;-)

"Derek Kuliński / takeda" <d.kulinski@gmail.com> wrote in message 
news:19gt62gras201.dlg@takeda.tk.invalid...
> On Thu, 29 Dec 2005 02:43:58 +0000 (UTC), Adam Wysocki wrote:
>
>>>> j.w.
>>> Cholera, ubiegłeś mnie ;>>>
>> Cześć TaKeDa :)

>
> Na innej grupie widziałem, już że można zlinkować program do libc i używać
> np. printf. Co jest (a przynajmniej wygląda) na proste. Są jeszcze jakieś
> inne sposoby aby wyświetlić wynik działania programu?

Pod linuxem wywolujesz odpowiednie wywolanie systemowe (write), wpisujac do 
odpowiednich rejestrow dlugosc lancucha, jego adres i deskryptor otwartego 
pliku - konsola ma deskryptor 1.
section .text
global _start ;Declaracja dla linkera (ld)
STDOUT equ 1 ;Standardowe wyjscie (deskryptor)
;; Wywołania systemowe
SYS_WRITE equ 4
_start: ;Poczatek programu (punkt wejscia)
mov edx,dlug ;długosc bufora (arg 3)
mov ecx,napis ;adres bufora (arg 2)
mov ebx,STDOUT ;deskryptor pliku (arg 1)
mov eax,SYS_WRITE ;numer wywołania systemowego
int 0x80 ;wywołanie systemowe

funkcje z biblioteki C tez oczywiscie mozesz uzywac (printf). Tylko 
parametry przekazujesz na stosie.

Powyzszy kod wkleilem z 
http://rainbow.mimuw.edu.pl/~zbyszek/akpn-zsi/glowny.pdf (krotkie notatki , 
22 strony), jest tam tez jakis przyklad jak uzyc printfa i jak zlinkowac.

Pod Dosem oczywiscie jest inaczej , a pod Win jeszcze inaczej.

-- 

Pozdr. A.B.

On Thu, 29 Dec 2005 15:10:13 +0100, AB wrote:

> Powyzszy kod wkleilem z 
> http://rainbow.mimuw.edu.pl/~zbyszek/akpn-zsi/glowny.pdf (krotkie notatki , 
> 22 strony), jest tam tez jakis przyklad jak uzyc printfa i jak zlinkowac.

Bardzo fajny papier =)

> Pod Dosem oczywiscie jest inaczej , a pod Win jeszcze inaczej.

Szczerze mówiąc DOS mnie nie interesuje, ale dobrze byłoby wiedzieć jak to
zrobić jeszcze pod windowsem...

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Thu, 29 Dec 2005 14:39:30 -0800 jednostka biologiczna o nazwie Derek
Kuliński / takeda <d.kulinski@gmail.com> wyslala do portu 119
jednego z serwerow news nastepujace dane:

>Szczerze mówiąc DOS mnie nie interesuje, ale dobrze byłoby wiedzieć jak to
>zrobić jeszcze pod windowsem...
Znaczy co ? Wyświetlić cokolwiek ?
Np. MessageBox.

Funkcje Windows API wywołujemy kładąc na stos kolejne argumenty i
robiąc call.
Np.:

;tutaj rozne definicje
.data

napis db 'To jest testowy MessageBox',0
tytul db 'Info',0

.code

push 0l		;MB_OK
push offset tytul
push offset napis
push 0l		 ;Moglibysmy wstawic tu handle naszego modulu, trzeba
                 ;by ja uzyskac funkcja GetModuleHandleA
call MessageBoxA ;powinien sie wyswietlic MessageBox o tytule "Info",
		 ;z tekstem "To jest testowy MessageBox"
		 ;i z przyciskiem OK (styl MB_OK)


Litera l na końcu informuje że na stos ma być położona liczba
32-bitowa. Można też wyzerować któryś rejestr np. EAX i go kłaść na
stos.

Generalnie do dyspozycji jest od cholery funkcji, ale programowanie w
assemblerze pod Windows to niestety straszna rzeźnia. Warto raczej
pisać w C/C++ a wybrane fragmenty (np. procedury obróbki grafiki) w
assemblerze.
Wszystkie funkcje masz opisane na http://msdn.microsoft.com i w Win32
Programmer's Reference - pliku pomocy rozprowadzanym z każdym
kompilatorem dla Windows.

oj kiedyś się pisało gry w asm'ie, pamiętam jeszcze czasy 8-bit Atari (LDA, 
STA) :D
potem 16 bit x86:

mov ax, 13h
int 10h  (czy jakos tak zeby włączyć 320x200)

potem 32 bit gdzie doszło 'e' przed nazwami rejestrów (i nie tylko)

a na koniec wylądalowałem w jakiejś javie/c++ i innych takich...

z chęcią bym wrócił w te czasy :(

Pozdrawiam wszystkich piszących w asm'ie z pasji...
Mirek 

On Sat, 31 Dec 2005 10:52:40 +0100, QUESS wrote:

> oj kiedyś się pisało gry w asm'ie, pamiętam jeszcze czasy 8-bit Atari (LDA, 
> STA) :D
> potem 16 bit x86:
> 
> mov ax, 13h
> int 10h  (czy jakos tak zeby włączyć 320x200)
> 
> potem 32 bit gdzie doszło 'e' przed nazwami rejestrów (i nie tylko)
> 
> a na koniec wylądalowałem w jakiejś javie/c++ i innych takich...
> 
> z chęcią bym wrócił w te czasy :(
> 
> Pozdrawiam wszystkich piszących w asm'ie z pasji...

Ja to mogę tylko powspominać BASIC'a z C64 =)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

On Fri, 30 Dec 2005 11:37:42 +0100, BLE_Maciek wrote:

> Generalnie do dyspozycji jest od cholery funkcji, ale programowanie w
> assemblerze pod Windows to niestety straszna rzeźnia. Warto raczej
> pisać w C/C++ a wybrane fragmenty (np. procedury obróbki grafiki) w
> assemblerze.
> Wszystkie funkcje masz opisane na http://msdn.microsoft.com i w Win32
> Programmer's Reference - pliku pomocy rozprowadzanym z każdym
> kompilatorem dla Windows.

Chodziło mi raczej o pisanie na konsole pod windows, ale pewnie odpowiednia
funkcja też będzie na msdn :)))

Dzięki za pomoc.
-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

BLE_Maciek napisał(a):
> 
>>Szczerze mówiąc DOS mnie nie interesuje, ale dobrze byłoby wiedzieć jak to
>>zrobić jeszcze pod windowsem...
> 
> Znaczy co ? Wyświetlić cokolwiek ?
> Np. MessageBox.

[...]

> push 0l		;MB_OK
> push offset tytul
> push offset napis
> push 0l		 ;Moglibysmy wstawic tu handle naszego modulu, trzeba
>                  ;by ja uzyskac funkcja GetModuleHandleA

Nie myl pojęć. Tu ma być uchwyt okna, a nie modułu. To jakby co innego.

> call MessageBoxA ;powinien sie wyswietlic MessageBox o tytule "Info",

Pozdrawiam,
Morris

Derek Kuliński / takeda napisał(a):
> On Fri, 30 Dec 2005 11:37:42 +0100, BLE_Maciek wrote:
> 
> 
>>Generalnie do dyspozycji jest od cholery funkcji, ale programowanie w
>>assemblerze pod Windows to niestety straszna rzeźnia. Warto raczej
>>pisać w C/C++ a wybrane fragmenty (np. procedury obróbki grafiki) w
>>assemblerze.
>>Wszystkie funkcje masz opisane na http://msdn.microsoft.com i w Win32
>>Programmer's Reference - pliku pomocy rozprowadzanym z każdym
>>kompilatorem dla Windows.
> 
> Chodziło mi raczej o pisanie na konsole pod windows, ale pewnie odpowiednia
> funkcja też będzie na msdn :)))
> 

np. tak (dla MASM):

<code>
         .386
         .model flat, stdcall
         option casemap:none

         include windows.inc
         include kernel32.inc
         includelib kernel32.lib
         include user32.inc
         includelib user32.lib

.data?
         hStdOut dd ?
         written dd ?
.code
start:
         ;pobranie uchwytu konsoli
         invoke GetStdHandle, STD_OUTPUT_HANDLE
         mov hStdOut, eax

         ;pobranie linii poleceń
         invoke GetCommandLine
         mov ebx, eax

         ;długość linii poleceń
         invoke lstrlen, eax
         push eax

         ;konwersja znaków linii poleceń
         invoke CharToOem, ebx, ebx
         pop eax

         ;wypisanie na konsolę
         invoke WriteConsole, hStdOut, ebx, eax, addr written, NULL
         invoke ExitProcess, 0
end start
</code>

Pozdrawiam,
Morris

Fri, 06 Jan 2006 14:41:35 +0100 jednostka biologiczna o nazwie Paweł
Pawlak <morr!s@elys!um.pl> wyslala do portu 119
jednego z serwerow news nastepujace dane:

>Nie myl pojęć. Tu ma być uchwyt okna, a nie modułu. To jakby co innego.
No fakt. Sorry.

AB wrote:
> j.w.

Witam!

> programowanie w assemblerze pod Windows
> to niestety straszna rzeźnia.


Czytałem na grupach masę takich dyskusji
o wyższości C nad Asm, lub odwrotnie.

Mnie to przypomina dyskusję - czy lepsze
jest dłuto rzeźbiarskie, czy nowoczesna
automatyczna linia produkcyjna. Przecież
tego nie da się rozstrzygnąć. Jedno i drugie
mają swoje przeznaczenie i właściwe zastosowanie.

A kodowanie pod Win32 w Masm32 wcale nie jest
takie straszne i bardzo podobne do C++.


Pozdrawiam!

--
Remek

On 03.03.2006, Remek <remeka@gazeta.pl> wrote:
>> programowanie w assemblerze pod Windows
>> to niestety straszna rzeźnia.
>
>
> Czytałem na grupach masę takich dyskusji
> o wyższości C nad Asm, lub odwrotnie.
>
> Mnie to przypomina dyskusję - czy lepsze
> jest dłuto rzeźbiarskie, czy nowoczesna
> automatyczna linia produkcyjna. Przecież
> tego nie da się rozstrzygnąć. Jedno i drugie
> mają swoje przeznaczenie i właściwe zastosowanie.

Z tym można się jeszcze zgodzić...

> A kodowanie pod Win32 w Masm32 wcale nie jest
> takie straszne i bardzo podobne do C++.

ROTFL. Nie pisałeś nigdy w C++, prawda? Co najwyżej w C z użyciem cin>>
i cout<<.

-- 
Feel free to correct my English
Stanislaw Klekot

Witam!

> ROTFL. Nie pisałeś nigdy w C++, prawda?

Przypominam, że jesteśmy na grupie
asemblerowej, gdzie panuje pewna kultura
i nie ma zwyczaju podśmiewania się z
kogokolwiek. Nieważne czy piszę w C, czy
w asm. Uważam oba języki za mające swoje
miejsce i twierdzę, że dyskusja o wyższości
jednego nad drugim nie ma sensu. Ludzie
straszący początkujących asemblerem, albo
go nie znają, albo zakończyli edukację
na etepie 16 bitowych aplikacji, które
faktycznie wymagają mrówczej pracy.
Masm32 dla Win32 jest zupełnie innym narzędziem
podobnym w swoich możliwościach do C++.
Jest na ten temat sporo poważnych opracowań
w sieci. Odsyłam do nich. Ja nie aspiruję
do miana eksperta i tylko wyrażam swoje zdanie.

To przykład programiku w C++:

 #include <windows.h>
 #include <stdlib.h>

LRESULT CALLBACK WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam,
LPARAM lParam);

WNDCLASS wndclass = {
  0,
  WindowProc,
  0,
  0,
  NULL,
  NULL,
  NULL,
  (HBRUSH)(COLOR_MENU + 1),
  NULL,
  "Simple"
};

HWND hwnd;
HWND button1;
HWND button2;
HWND edit;

WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmdLine,
int nCmdShow) {
  MSG msg;

  wndclass.hInstance = hInst;
  wndclass.hIcon     = LoadIcon (NULL, IDI_APPLICATION);
  wndclass.hCursor   = LoadCursor (NULL, IDC_ARROW);
  RegisterClass (&wndclass);

  hwnd = CreateWindow (wndclass.lpszClassName, "Proste kontrolki",
                       WS_OVERLAPPEDWINDOW,
                       500, 300, 200, 120,
                       NULL, NULL, hInst, NULL);

  button1 = CreateWindow (
            "button",
            "Wypisz",
            BS_PUSHBUTTON|WS_CHILD|WS_VISIBLE,
            25, 5, 60, 20,
            hwnd,     //<-- uchwyt rodzica, na ktorym umieszczamy
przycisk
            (HMENU)1, //<-- tu przekazujemy identyfikator okienka
            hInst,    //    bedzie uzywany do rozpoznawania przyciskow
            NULL);

  button2 = CreateWindow (
            "button",
            "Zapiszcz",
            BS_PUSHBUTTON|WS_CHILD|WS_VISIBLE,
            110, 5, 70, 20,
            hwnd,
            (HMENU)2, //<-- wazne zeby nie uzyc tych samych
identyfikatorow
            hInst,
            NULL);

  edit = CreateWindowEx (
            WS_EX_CLIENTEDGE, //<-- bez tego wyglada jak w win 3.11
            "edit",
             0,                   // "wpisz cos",
            WS_CHILD|WS_VISIBLE,
            25, 30, 140, 20,
            hwnd,
            (HMENU)3,
            hInst,
            NULL);

  edit = CreateWindowEx (
            WS_EX_CLIENTEDGE, //<-- bez tego wyglada jak w win 3.11
            "edit",
             0,                   // "wpisz cos",
            WS_CHILD|WS_VISIBLE,
            25, 60, 140, 20,
            hwnd,
            (HMENU)4,
            hInst,
            NULL);



  ShowWindow (hwnd, nCmdShow);

  while (GetMessage (&msg, NULL, 0, 0)) {
    TranslateMessage(&msg);    //<-- istotne dla dzialania kontrolek
do
    DispatchMessage(&msg);     //    wpisywania tekstu
  }

  return 0;
}

LRESULT CALLBACK WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam,
LPARAM lParam) {
  switch (uMsg) {
  case WM_COMMAND: {
    int id = LOWORD(wParam); //<-- identyfikator kontrolki

    // przycisk 'wypisz', wypisuje tekst kontrolki edycji
    if (id == 1)
     {
      int textLength = GetWindowTextLength(edit);
      char* text = (char*)malloc(textLength+1);  // nie zapomniec o
miejscu na '\0' !!
      GetWindowText(edit, text, textLength+1);
      MessageBox(hwnd, text, "Z KONTROLKI EDYCJI", MB_OK);
      free(text);
    }

    // przycisk 'zapiszcz'
    else if (id == 2) {
      MessageBeep(MB_ICONEXCLAMATION);
    }
    break;
    }

  case WM_DESTROY:
    PostQuitMessage (0);
    return 0;
  }

  return DefWindowProc (hwnd, uMsg, wParam, lParam);
}


I bardzo podobny w Masm32:


.386
.model flat,stdcall
option casemap:none

  include  C:\MASM32\include\Windows.inc
  include  C:\MASM32\include\user32.inc
  include  C:\MASM32\include\kernel32.inc
  includelib  C:\MASM32\lib\user32.lib
  includelib  C:\MASM32\lib\kernel32.lib
  includelib  C:\MASM32\lib\\remeka.lib

   _dec_hex  PROTO
   _wyswietl PROTO


.data

klasa        db "WinClass",0
tytul        db "       Konwerter dec/hex",0
classbutton  db "button",0
Button1Text  db "OK",0
Button2Text  db "Exit",0
classedit    db "edit",0
msgTekst3  db "Wpisz coś", 0
msgTytul db "Error!", 0
Bufor1          db 32 dup(0)
Bufor2          db 32 dup(0)
Bufor3          db 32 dup(0)

.data?

uchwyt       dd ?
hEdit1       dd ?
hEdit2       dd ?

.const

Button1ID   equ 3
Button2ID   equ 4

.code

start:

 invoke GetModuleHandleA, 0
     mov uchwyt, eax

     call WinMain
zamknij:
     invoke ExitProcess, 0

WinMain proc

    LOCAL wc:WNDCLASSEX
    LOCAL msg:MSG
    LOCAL hwnd:HWND
    mov wc.cbSize,SIZEOF WNDCLASSEX
    mov wc.style,CS_HREDRAW or CS_VREDRAW   ;poczytać o tym
    mov wc.lpfnWndProc,offset WndProc
    mov wc.cbClsExtra,0
    mov wc.cbWndExtra,0
    push uchwyt
    pop wc.hInstance
    mov wc.hbrBackground,COLOR_WINDOW
    mov wc.lpszMenuName,0
    mov wc.lpszClassName,offset klasa
    invoke LoadIcon, 0, IDI_APPLICATION
    mov wc.hIcon,eax
    mov wc.hIconSm,eax
    invoke LoadCursor, 0, IDC_ARROW
    mov wc.hCursor,eax

    invoke RegisterClassEx, addr wc

    invoke CreateWindowEx, WS_OVERLAPPEDWINDOW, offset klasa, offset
tytul, WS_TILEDWINDOW,\
           520, 430, 270, 90, 0, 0, uchwyt, 0
     mov hwnd,eax
    invoke ShowWindow, hwnd, SW_SHOWNORMAL
    invoke UpdateWindow, hwnd

 .WHILE TRUE
  invoke GetMessage,ADDR msg,0,0,0
  .BREAK .IF (!eax)
  invoke TranslateMessage,ADDR msg
  invoke DispatchMessage,ADDR msg
 .ENDW
      mov  eax, msg.wParam
      ret

WinMain endp

WndProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

        .IF uMsg==WM_DESTROY
    invoke PostQuitMessage,0
            .ELSEIF uMsg==WM_CREATE

    invoke CreateWindowEx, WS_EX_CLIENTEDGE, ADDR classedit, 0,
WS_CHILD or WS_VISIBLE or WS_BORDER or ES_RIGHT,\
           10, 10, 165, 22, hWnd, 0, uchwyt, 0
     mov hEdit1, eax
        invoke SetFocus, hEdit1

    invoke CreateWindowEx, WS_EX_CLIENTEDGE, offset classedit, 0,
WS_CHILD or WS_VISIBLE or WS_BORDER or ES_RIGHT,\
           10, 33, 165, 22, hWnd, 0, uchwyt, 0
     mov hEdit2, eax

    invoke CreateWindowEx, 0, addr classbutton, addr Button1Text,
WS_CHILD or WS_VISIBLE,\
    189, 10, 60, 22, hWnd, Button1ID, uchwyt, 0

    invoke CreateWindowEx, 0, addr classbutton, addr Button2Text,
WS_CHILD or WS_VISIBLE,\
    189, 33, 60, 22, hWnd, Button2ID, uchwyt, 0

 .ELSEIF uMsg==WM_COMMAND
            mov eax,wParam
      .IF ax==Button1ID

     invoke GetWindowText, hEdit1, addr Bufor1, 16

 push edi
 push esi
 push ebp
 push ebx

 lea esi, Bufor1
 mov ecx, eax
 invoke _dec_hex
 cmp eax, 'b'
 jz jeszcz
 mov dword ptr [Bufor2], edi
 lea esi, Bufor2
 lea edi, Bufor3
 invoke _wyswietl

 pop ebx
 pop ebp
 pop esi
 pop edi

 invoke SetWindowTextA, hEdit2, addr Bufor3
     ret

wpisz:
       invoke MessageBox, 0, addr msgTekst3, addr msgTytul, MB_OK
     ret

jeszcz:
 pop ebx
 pop ebp
 pop esi
 pop edi

    invoke SetWindowTextA, hEdit1, 0

 .ELSEIF ax==Button2ID
     jmp zamknij

     .ENDIF

  .ELSE
    invoke DefWindowProc,hWnd,uMsg,wParam,lParam
  ret
     .ENDIF
 ret

WndProc endp

end start


Oba programiki wykonują podobne operacje. Czy tak bardzo się
różnią sposobem pisania? Ten w C++ po kompilacji ma 8,5 kB,
a ten w Masm 3,5 kB.

Nie ma co straszyć dzieci asemblerem.


Pozdrawiam!

--
Remek

On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
> Witam!
>
>> ROTFL. Nie pisałeś nigdy w C++, prawda?
>
> Przypominam, że jesteśmy na grupie
> asemblerowej, gdzie panuje pewna kultura
> i nie ma zwyczaju podśmiewania się z
> kogokolwiek.

Nie śmieję się z ciebie (przynajmniej na razie), tylko z twojego
stwierdzenia, jakoby
#v+
A kodowanie pod Win32 w Masm32 wcale nie jest
takie straszne i bardzo podobne do C++.
#v-
Znaczy z fragmentu "bardzo podobne do C++".

> Nieważne czy piszę w C, czy
> w asm.

Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
się porównywać z assemblerem.

> Uważam oba języki za mające swoje
> miejsce i twierdzę, że dyskusja o wyższości
> jednego nad drugim nie ma sensu. Ludzie
> straszący początkujących asemblerem, albo
> go nie znają, albo zakończyli edukację
> na etepie 16 bitowych aplikacji, które
> faktycznie wymagają mrówczej pracy.
> Masm32 dla Win32 jest zupełnie innym narzędziem
> podobnym w swoich możliwościach do C++.

Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i funkcji
wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
przestrzeni nazw.

> Jest na ten temat sporo poważnych opracowań
> w sieci. Odsyłam do nich. Ja nie aspiruję
> do miana eksperta i tylko wyrażam swoje zdanie.
>
> To przykład programiku w C++:
>
[ciach win-C]

No i gdzie tu C++? Nie używasz tu *nic*, co by wychodziło ponad C.

> I bardzo podobny w Masm32:
[ciach win-ASM]
> Oba programiki wykonują podobne operacje. Czy tak bardzo się
> różnią sposobem pisania? Ten w C++ po kompilacji ma 8,5 kB,
> a ten w Masm 3,5 kB.
>
> Nie ma co straszyć dzieci asemblerem.

Nie ma co robić z siebie... No, w każdym razie kłuć innych w oczy
nieodróżnianiem jednego języka od drugiego. Gotów jesteś jeszcze
powiedzieć, że Obiektowe C (Objective C) to C++.

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>
> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
> się porównywać z assemblerem.
>

Na prawdę? Hint, co jest efektem pracy kompilatora C++?

>
> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i funkcji
> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
> przestrzeni nazw.
>

Jeśli chcesz wystraszyć początkującego to pokaż mu rzutowanie typów w C++, 
dziedziczenie nie będzie potrzebne by już nigdy nie brał się za 
programowanie.

 -- 
ZZ@private 

On 08.03.2006, Zbyszek Zarzycki <zbyszekz@borland.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
>> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>>
>> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
>> się porównywać z assemblerem.
>>
>
> Na prawdę? Hint, co jest efektem pracy kompilatora C++?
  ^^^^^^^^^^
A na fałsz?

I uważasz ręczne symulowanie większości mechanizmów za coś, dzięki czemu
można porównywać dwa diametralnie różne języki? To może i Haskella
z leniwym obliczaniem wartości wyrażeń sprowadzisz do "w assemblerze też
się da"?

>> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i funkcji
>> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
>> przestrzeni nazw.
>>
>
> Jeśli chcesz wystraszyć początkującego to pokaż mu rzutowanie typów w C++, 

Że niby co tu jest trudnego?

> dziedziczenie nie będzie potrzebne by już nigdy nie brał się za 
> programowanie.

-- 
Feel free to correct my English
Stanislaw Klekot

Newsuser "Zbyszek Zarzycki" wrote:
> Jeśli chcesz wystraszyć początkującego to pokaż mu rzutowanie typów w C++, 
> dziedziczenie nie będzie potrzebne by już nigdy nie brał się za 
> programowanie.

Jabym mu pokazał śjakiś metaprogram w C++
:>

pzdr
mk 

Pozdrawiam!

> Nie śmieję się z ciebie (przynajmniej na razie ...

No to się cieszę (na razie ...).

Proponuję nie kontynuować tej jałowej
dyskusji. W żadnym miejscu nie napisalem,
że asemler jest lepszy od C++, czy
czegokolwiek i nie napiszę. Różnych
zupełnie języków nie da się prosto
porównać.
Chodziło mi o zachęcenie początkującego
do nauki Masm32 twierdzeniem, że nie
jest to takie straszne. I tyle. Poza tym
brzydzę się takim sposobem prowadzenia
dyskusji. Proszę wybaczyć, wypisuję się.

--
Remek

On 09.03.2006, Remek <remeka@gazeta.pl> wrote:
> Pozdrawiam!
>
>> Nie śmieję się z ciebie (przynajmniej na razie ...
>
> No to się cieszę (na razie ...).
>
> Proponuję nie kontynuować tej jałowej
> dyskusji. W żadnym miejscu nie napisalem,
> że asemler jest lepszy od C++, czy
> czegokolwiek i nie napiszę.

Za to napisałeś, że nie różni się za bardzo od C++, co jest bzdurą.
I faktycznie, tu możemy zakończyć dyskusję.

> Różnych
> zupełnie języków nie da się prosto
> porównać.
> Chodziło mi o zachęcenie początkującego
> do nauki Masm32 twierdzeniem, że nie
> jest to takie straszne. I tyle. Poza tym
> brzydzę się takim sposobem prowadzenia
> dyskusji. Proszę wybaczyć, wypisuję się.

Znaczy jakim? Nie lubisz, gdy ktoś ci wytyka nieznajomość C++?
A, prawda, mieliśmy nie dyskutować.

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne0ujul.3od.dozzie@hans.zsh.bash.org.pl...
> On 08.03.2006, Zbyszek Zarzycki <zbyszekz@borland.pl> wrote:
>>
>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
>>> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>>>
>>> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
>>> się porównywać z assemblerem.
>>>
>>
>> Na prawdę? Hint, co jest efektem pracy kompilatora C++?
>  ^^^^^^^^^^
> A na fałsz?
>
> I uważasz ręczne symulowanie większości mechanizmów za coś, dzięki czemu
> można porównywać dwa diametralnie różne języki? To może i Haskella
> z leniwym obliczaniem wartości wyrażeń sprowadzisz do "w assemblerze też
> się da"?
>
>>> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i funkcji
>>> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
>>> przestrzeni nazw.
Chyba nie wiesz o czym piszesz, i tak na końcu jest kod maszynowy.
Kompilator C to tylko sprytny parser tekstu tworzący wsad dla 
makroassemblera
;-P

pzdr
AK

PS
Nie wiem jak jest teraz ale tak to sie robiło na Intelu 8080 czy Z80
(pomijam sprawdzanie typu parametru co też było możliwe)

;virtual
MACRO DO_STH
.WARNING    |virtual sub used|
;do nothing
ENDM
;overloaded
MACRO DO_STH PAR1,PAR2
IFB <PAR2>
IFB <PAR1>
.ERROR    |no version sub without parms|
ELSE
DO_STH2 PAR1,PAR2
ELSE
DO_STH1 PAR1
ENDIF
ENDM

.... 

On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne0ujul.3od.dozzie@hans.zsh.bash.org.pl...
>> On 08.03.2006, Zbyszek Zarzycki <zbyszekz@borland.pl> wrote:
>>>
>>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>> napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
>>>> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>>>>
>>>> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
>>>> się porównywać z assemblerem.
>>>>
>>>
>>> Na prawdę? Hint, co jest efektem pracy kompilatora C++?
>>  ^^^^^^^^^^
>> A na fałsz?
>>
>> I uważasz ręczne symulowanie większości mechanizmów za coś, dzięki czemu
>> można porównywać dwa diametralnie różne języki? To może i Haskella
>> z leniwym obliczaniem wartości wyrażeń sprowadzisz do "w assemblerze też
>> się da"?
>>
>>>> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i funkcji
>>>> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
>>>> przestrzeni nazw.
> Chyba nie wiesz o czym piszesz, i tak na końcu jest kod maszynowy.

Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
assemblerowy takie coś:

#v+
#include <iostream>
#include <string>
#include <vector>
using namespace std;

int main(void)
{
  typedef int mytype;
  typedef vector<mytype> myvec;
  myvec v;
  mytype l;
  while (cin >> l)
    v.push_back(l);

  for (myvec::reverse_iterator i = v.rbegin(); i != v.rend(); ++i)
    cout << *i << endl;

  return 0;
}
#v-

Masz zachować elastyczność typedefów (jedna zmiana na char, double,
string albo mój własny typ) i wektora (nie martwię się o ilość miejsca
potrzebnego na pojedynczy element, nie martwię się o alokację,
realokację ani dealokację). Bardzo chcę zobaczyć, jak zapewniasz mi
automatyczne zwolnienie pamięci potrzebnej dla wektora używając makr
albo jak zrobisz _szablon_ kontenera (vector<cokolwiek>).

> Kompilator C to tylko sprytny parser tekstu tworzący wsad dla 
> makroassemblera
> ;-P

Ale ja nie mówię o kompilatorze C, tylko o kompilatorze C++. I ty
twierdzisz, że ja nie wiem, o czym mówię?

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1arl3.9jm.dozzie@hans.zsh.bash.org.pl...
> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>
>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> napisał w wiadomości news:slrne0ujul.3od.dozzie@hans.zsh.bash.org.pl...
>>> On 08.03.2006, Zbyszek Zarzycki <zbyszekz@borland.pl> wrote:
>>>>
>>>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>>> napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
>>>>> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>>>>>
>>>>> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
>>>>> się porównywać z assemblerem.
>>>>>
>>>>
>>>> Na prawdę? Hint, co jest efektem pracy kompilatora C++?
>>>  ^^^^^^^^^^
>>> A na fałsz?
>>>
>>> I uważasz ręczne symulowanie większości mechanizmów za coś, dzięki czemu
>>> można porównywać dwa diametralnie różne języki? To może i Haskella
>>> z leniwym obliczaniem wartości wyrażeń sprowadzisz do "w assemblerze też
>>> się da"?
>>>
>>>>> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i 
>>>>> funkcji
>>>>> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
>>>>> przestrzeni nazw.
>> Chyba nie wiesz o czym piszesz, i tak na końcu jest kod maszynowy.
>
> Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
> assemblerowy takie coś:
>
> #v+
> #include <iostream>
> #include <string>
> #include <vector>
> using namespace std;
>
> int main(void)
> {
>  typedef int mytype;
>  typedef vector<mytype> myvec;
>  myvec v;
>  mytype l;
>  while (cin >> l)
>    v.push_back(l);
>
>  for (myvec::reverse_iterator i = v.rbegin(); i != v.rend(); ++i)
>    cout << *i << endl;
>
>  return 0;
> }
> #v-
>
> Masz zachować elastyczność typedefów (jedna zmiana na char, double,
> string albo mój własny typ) i wektora (nie martwię się o ilość miejsca
> potrzebnego na pojedynczy element, nie martwię się o alokację,
> realokację ani dealokację). Bardzo chcę zobaczyć, jak zapewniasz mi
> automatyczne zwolnienie pamięci potrzebnej dla wektora używając makr
> albo jak zrobisz _szablon_ kontenera (vector<cokolwiek>).
Jak będziesz wiedział jak działa kompilator C,C++ czy C# to bez trudu
takie makra sam napiszesz. Mówię makra nie kod.
>
>> Kompilator C to tylko sprytny parser tekstu tworzący wsad dla
>> makroassemblera
>> ;-P
>
> Ale ja nie mówię o kompilatorze C, tylko o kompilatorze C++. I ty
> twierdzisz, że ja nie wiem, o czym mówię?
Tym bardziej tak twierdzę.

pzdr
AK

On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1arl3.9jm.dozzie@hans.zsh.bash.org.pl...
>> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>
>>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>> napisał w wiadomości news:slrne0ujul.3od.dozzie@hans.zsh.bash.org.pl...
>>>> On 08.03.2006, Zbyszek Zarzycki <zbyszekz@borland.pl> wrote:
>>>>>
>>>>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>>>> napisał w wiadomości news:slrne0uap2.384.dozzie@hans.zsh.bash.org.pl...
>>>>>> On 08.03.2006, Remek <remeka@gazeta.pl> wrote:
>>>>>>
>>>>>> Ale C to nie C++. C++ ma znacznie więcej mechanizmów. Tego już nie da
>>>>>> się porównywać z assemblerem.
>>>>>>
>>>>>
>>>>> Na prawdę? Hint, co jest efektem pracy kompilatora C++?
>>>>  ^^^^^^^^^^
>>>> A na fałsz?
>>>>
>>>> I uważasz ręczne symulowanie większości mechanizmów za coś, dzięki czemu
>>>> można porównywać dwa diametralnie różne języki? To może i Haskella
>>>> z leniwym obliczaniem wartości wyrażeń sprowadzisz do "w assemblerze też
>>>> się da"?
>>>>
>>>>>> Oh really? To pokaż mi masmowy odpowiednik klas, dziedziczenia i 
>>>>>> funkcji
>>>>>> wirtualnych. Albo przeciążania funkcji. Albo szablonów. Albo choćby
>>>>>> przestrzeni nazw.
>>> Chyba nie wiesz o czym piszesz, i tak na końcu jest kod maszynowy.
>>
>> Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
>> assemblerowy takie coś:
[...]
>> Masz zachować elastyczność typedefów (jedna zmiana na char, double,
>> string albo mój własny typ) i wektora (nie martwię się o ilość miejsca
>> potrzebnego na pojedynczy element, nie martwię się o alokację,
>> realokację ani dealokację). Bardzo chcę zobaczyć, jak zapewniasz mi
>> automatyczne zwolnienie pamięci potrzebnej dla wektora używając makr
>> albo jak zrobisz _szablon_ kontenera (vector<cokolwiek>).
> Jak będziesz wiedział jak działa kompilator C,C++ czy C# to bez trudu
> takie makra sam napiszesz. Mówię makra nie kod.
>>
>>> Kompilator C to tylko sprytny parser tekstu tworzący wsad dla
>>> makroassemblera
>>> ;-P
>>
>> Ale ja nie mówię o kompilatorze C, tylko o kompilatorze C++. I ty
>> twierdzisz, że ja nie wiem, o czym mówię?
> Tym bardziej tak twierdzę.

ROTFL. Popisz może trochę w C++, to możemy wrócić do rozmowy. Ale w C++,
a nie tylko C z cin>> i cout<<.

A, i ałtlóka skonfiguruj. Nie deklarujesz kodowania.

-- 
Feel free to correct my English
Stanislaw Klekot

Odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana „Stachu
'Dozzie' K.”.

> Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
> assemblerowy takie coś:
> 
> #v+
> #include <iostream>
> #include <string>
> #include <vector>
> using namespace std;
> 
> int main(void)
> {
>   typedef int mytype;
>   typedef vector<mytype> myvec;
>   myvec v;
>   mytype l;
>   while (cin >> l)
>     v.push_back(l);
> 
>   for (myvec::reverse_iterator i = v.rbegin(); i != v.rend(); ++i)
>     cout << *i << endl;
> 
>   return 0;
> }
> #v-
Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
jako parametr makra. Dokładnie tak jak to robi kompilator C++.

Wasz
-- 
: qo   |)     =@=N%_g=v=a=g_ed_e=c()=d=8= %IGn@8're: w8in ad
:    _x/ ,     H'%'a'h4'HA.XO'Xo'xo'xO.R %expo1ited: *-1 teh
:    |    ng  __%-- __ -- __ -- __ -- __%/by$qVerCo: &GooMee
^.__ -- __ -- % dbqr74oh4ekrbrgz.onion %/^v^'^ww^v^;_<E-O-F>

On 13.03.2006, Rat Without Tail <ratwithouttail@gazeta.pl> wrote:
> Odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana ?Stachu
> 'Dozzie' K.?.
>
>> Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
>> assemblerowy takie coś:
>> 
>> #v+
>> #include <iostream>
>> #include <string>
>> #include <vector>
>> using namespace std;
>> 
>> int main(void)
>> {
>>   typedef int mytype;
>>   typedef vector<mytype> myvec;
>>   myvec v;
>>   mytype l;
>>   while (cin >> l)
>>     v.push_back(l);
>> 
>>   for (myvec::reverse_iterator i = v.rbegin(); i != v.rend(); ++i)
>>     cout << *i << endl;
>> 
>>   return 0;
>> }
>> #v-
> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
> jako parametr makra.

Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam>
w wiadomości <slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl> napisał:
> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?

A czy naprawdę w każdym programie używasz tych wszystkich technik?
IMHO w C++ jedynym poważnym usprawnieniem było wprowadzenie
czegoś takiego jak string. Tego tylko brakowało mi w C.

W ogóle nie rozumiem o co Wy się kłucicie.
Do czego innego służy asembler i do czego innego służą języki wyższego
poziomu.
Wprawdzie można napisać w asemblerze program z okienkami i wszystkimi
"bajerami" windowsa, lecz nikt, oprócz osób, które chcą się czegoś nauczyć,
nie będzie się w coś takiego bawił bo to po prostu szkoda czasu. Więcej
"pisaniny" niż efektów.
Asembler stosuje się wtedy, gdy naprawdę zależy nam na szybkości działana,
ponieważ tylko wtedy możemy zoptymalizować program tak, aby działał on
możliwie najszybciej.
Języki wyższego poziomu stosujemy natomiast wtedy, gdy zależy nam nie tyle
na szybkości działania, co na szybkości pisania kodu.
Oprócz tego odnośnie aplikacji "okienkowych" pisanych w C++ i tak osobiście
wolałbym, zamiast żmudnego tworzenia samodzielnie okienek, zastosować
którąś z bibliotek, np. qt czy inne wxwindows, ponieważ bez tego faktycznie
projektowanie okienek czy to pod C czy to pod C++ niewiele odbiega od
projektowania okienek pod asemblerem.

On 14.03.2006, Daniel P. <nako@go2.i.do.not.like.spam.pl> wrote:
> Użytkownik Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam>
> w wiadomości <slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl> napisał:
>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>
> A czy naprawdę w każdym programie używasz tych wszystkich technik?

Nie. Tam, gdzie tego nie używam, używam C.

> IMHO w C++ jedynym poważnym usprawnieniem było wprowadzenie
> czegoś takiego jak string. Tego tylko brakowało mi w C.

To jakoś mało używasz C++, IMO. Mnie się podoba cała masa kontenerów
(biblioteka standardowa), odseparowanie reprezentacji danych od operacji
na nich wykonywanych, zwiększenie "code reusability" (OOP i szablony)
i coś, co się nazywa algorytmy uogólnione (#include <algorithm>).

> W ogóle nie rozumiem o co Wy się kłucicie.

A ja nie wiem, co to znaczy "kłucicie".

> Do czego innego służy asembler i do czego innego służą języki wyższego
> poziomu.

Zgadza się. I zupełnie inna jest konstrukcja języka tu i tam, czego
niektórzy nie mogą zrozumieć i uparcie twierdzą, że assembler nie różni
się za bardzo od C++.

> Asembler stosuje się wtedy, gdy naprawdę zależy nam na szybkości działana,
> ponieważ tylko wtedy możemy zoptymalizować program tak, aby działał on
> możliwie najszybciej.

Z tego co wiem, kompilator radzi sobie z optymalizacją dużo szybciej,
efektywniej i bardziej przenośnie od człowieka. Co zresztą dyktuje
zdrowy rozsądek: optymalizator pisał cały sztab ludzi stosujących
wszystkie brudne tricki, jakie da się wykorzystać.

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl...
> On 13.03.2006, Rat Without Tail <ratwithouttail@gazeta.pl> wrote:
>> Odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana ?Stachu
>> 'Dozzie' K.?.
>>
>>> Najwyraźniej to ty nie wiesz, o czym mówisz. Przetłumacz mi na kod
>>> assemblerowy takie coś:
>>>
>>> #v+
>>> #include <iostream>
>>> #include <string>
>>> #include <vector>
>>> using namespace std;
>>>
>>> int main(void)
>>> {
>>>   typedef int mytype;
>>>   typedef vector<mytype> myvec;
>>>   myvec v;
>>>   mytype l;
>>>   while (cin >> l)
>>>     v.push_back(l);
>>>
>>>   for (myvec::reverse_iterator i = v.rbegin(); i != v.rend(); ++i)
>>>     cout << *i << endl;
>>>
>>>   return 0;
>>> }
>>> #v-
>> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
>> jako parametr makra.
>
> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
Demonizujesz pewne pojęcia.
Automatycznego destruktora używał juz basic napisany w latach 70tych
relokacja obszaru też już była w tymże basicu - wszystkie zmienne miały
uchwyt z nazwą i wskazaniem na aktualnie zajmowany obszar.
Przestrzeń nazw w uproszczeniu to tylko dawna dyrektywa LIB
wskazująca na biblioteki. Poliformizm danych? Wszystkie mają
tą samą postać, różnią sie tylko interpretacją.

pzdr
AK

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1ats9.9ri.dozzie@hans.zsh.bash.org.pl...
> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>

> ROTFL. Popisz może trochę w C++, to możemy wrócić do rozmowy. Ale w C++,
> a nie tylko C z cin>> i cout<<.
Dzięki za uznanie, programy w C pisałem 25 lat temu, C++ jakieś 15.
Faktycznie pewnie już co nieco zapomniałem bo to historyczne ciekawostki
sie powoli tylko robią :-P
Może mało efektowne były to programy bo 'real-time' i do dziś
pracują niezawodnie w kilkudziesięciu tysiącach urządzeń 
telekomunikacyjnych.
A wracając do pisania:
Jako ćwiczenie napisz obsługę przerwania DMA.
Taką najprostszą - odebrać przerwanie, zinkrementować licznik i wykonać
pierwotną procedurę obsługi tego przerwania.
Oczywiście w czystym C++, bez użycia assemblera inline.
No i najlepiej niezależnie od systemu.
Tak na oko w assemblerze to z dziesięć linijek, w C jedna, a w C++ 
deklaracji samych
przestrzeni nazw będzie ze trzy ekrany.

>
> A, i ałtlóka skonfiguruj. Nie deklarujesz kodowania.
Nie ja tylko ałtlók nie deklaruje, niestety napisany jest w C++ które tak 
demonizujesz.

pzdr
AK

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1ats9.9ri.dozzie@hans.zsh.bash.org.pl...
>> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>
>
>> ROTFL. Popisz może trochę w C++, to możemy wrócić do rozmowy. Ale w C++,
>> a nie tylko C z cin>> i cout<<.
> Dzięki za uznanie, programy w C pisałem 25 lat temu, C++ jakieś 15.
                                                       ^^^^^^^^^^^^^
To wiele tłumaczy. Wtedy faktycznie C++ było czymś tylko troszeczkę
więcej niż C.

> Faktycznie pewnie już co nieco zapomniałem bo to historyczne ciekawostki
> sie powoli tylko robią :-P
> Może mało efektowne były to programy bo 'real-time' i do dziś
> pracują niezawodnie w kilkudziesięciu tysiącach urządzeń 
> telekomunikacyjnych.

I to ma pokazać, że znasz C++, tak? Nie? To po co się chwalisz?

> A wracając do pisania:
> Jako ćwiczenie napisz obsługę przerwania DMA.
> Taką najprostszą - odebrać przerwanie, zinkrementować licznik i wykonać
> pierwotną procedurę obsługi tego przerwania.
> Oczywiście w czystym C++, bez użycia assemblera inline.
> No i najlepiej niezależnie od systemu.

Po co? Co mi przyjdzie z przechwycenia przerwania DMA? I dlaczego
miałbym to pisać bez assemblera?

> Tak na oko w assemblerze to z dziesięć linijek, w C jedna, a w C++ 
> deklaracji samych
> przestrzeni nazw będzie ze trzy ekrany.

Doczytaj o przestrzeniach nazw, zanim zaczniesz używać tego pojęcia.

>> A, i ałtlóka skonfiguruj. Nie deklarujesz kodowania.
> Nie ja tylko ałtlók nie deklaruje, niestety napisany jest w C++ które tak 
> demonizujesz.

Ale ty go używasz i ty go (nie) skonfigurowałeś.

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1c4ok.bae.dozzie@hans.zsh.bash.org.pl...
> On 14.03.2006, Daniel P. <nako@go2.i.do.not.like.spam.pl> wrote:
>> Użytkownik Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> w wiadomości <slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl> napisał:
>>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>>
>> A czy naprawdę w każdym programie używasz tych wszystkich technik?
>
> Nie. Tam, gdzie tego nie używam, używam C.
Sam dobierasz narzedzia do skali zadania, a innym zabraniasz.

>
>> IMHO w C++ jedynym poważnym usprawnieniem było wprowadzenie
>> czegoś takiego jak string. Tego tylko brakowało mi w C.
>
> To jakoś mało używasz C++, IMO. Mnie się podoba cała masa kontenerów
> (biblioteka standardowa), odseparowanie reprezentacji danych od operacji
> na nich wykonywanych, zwiększenie "code reusability" (OOP i szablony)
> i coś, co się nazywa algorytmy uogólnione (#include <algorithm>).
>
>> W ogóle nie rozumiem o co Wy się kłucicie.
>
> A ja nie wiem, co to znaczy "kłucicie".
Pewnie chodziło "kłócicie", kompilator FORTRAN 68 bez problemu
takie błędy rozpoznawał i poprawiał. Ale to był jedyny chyba kompilator
który w 10 liniach kodu tolerował ponad setkę błędów i zezwalał
na uruchomienie programu. To był swojego rozdzaju sport w owym czasie ;-)
>
>> Do czego innego służy asembler i do czego innego służą języki wyższego
>> poziomu.
>
> Zgadza się. I zupełnie inna jest konstrukcja języka tu i tam, czego
> niektórzy nie mogą zrozumieć i uparcie twierdzą, że assembler nie różni
> się za bardzo od C++.
To Ty istoty sporu nie zrozumiałeś - w assemblerze mozna pisac tak samo
jak innych językach - kwestia makr. C++ nie zwalnia od myślenia,
assembler zmusza do myślenia to jedyna zasadnicza różnica.

>
>> Asembler stosuje się wtedy, gdy naprawdę zależy nam na szybkości 
>> działana,
>> ponieważ tylko wtedy możemy zoptymalizować program tak, aby działał on
>> możliwie najszybciej.
>
> Z tego co wiem, kompilator radzi sobie z optymalizacją dużo szybciej,
> efektywniej i bardziej przenośnie od człowieka. Co zresztą dyktuje
> zdrowy rozsądek: optymalizator pisał cały sztab ludzi stosujących
> wszystkie brudne tricki, jakie da się wykorzystać.
Brudne tricki kolidują z przenośnością, można je 'uaktywniać' w C,
zlikwidowano to całkowicie w C++. Optymalizator dysponuje
tylko określonym zbiorem reguł. Prawdziwa optymalizacja
to zmiana algorytmu, a nie wyrzucenie zbędnych operacji.
Typowe to np. wywalenie jakiejś instrukcji z wnętrza pętli
na zewnątrz - w wielu przypadkach kompilator nie ma prawa
tego zrobić np. w przypadku wywolania funkcji.

pzdr
AK

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
>>> jako parametr makra.
>>
>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
> Demonizujesz pewne pojęcia.
> Automatycznego destruktora używał juz basic napisany w latach 70tych

Tak? W czym? Destruktor to pojęcie żywcem z programowania obiektowego.
Masz klasę alokującą zasoby, które trzeba potem ręcznie zwolnić. No to
bach, piszemy destruktor. Basic (powstały jeszcze w latach 60, nie 70)
w latach 70 nie miał zielonego pojęcia o OOP.

> Przestrzeń nazw w uproszczeniu to tylko dawna dyrektywa LIB
> wskazująca na biblioteki.

Zapewnia mi, że symbole z różnych przestrzeni nazw ze sobą nie kolidują?
Pozwala potem importować do bieżącej przestrzeni nazw ten symbol, który
mi odpowiada?

> Poliformizm danych? Wszystkie mają
> tą samą postać, różnią sie tylko interpretacją.

Co to jest "polimorfizm danych"? Nie używaj pojęć, których nie
rozumiesz, dziękuję bardzo.

-- 
Feel free to correct my English
Stanislaw Klekot

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1c4ok.bae.dozzie@hans.zsh.bash.org.pl...
>> On 14.03.2006, Daniel P. <nako@go2.i.do.not.like.spam.pl> wrote:
>>> Użytkownik Stachu 'Dozzie' K. <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>> w wiadomości <slrne1bumf.am6.dozzie@hans.zsh.bash.org.pl> napisał:
>>>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>>>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>>>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>>>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>>>
>>> A czy naprawdę w każdym programie używasz tych wszystkich technik?
>>
>> Nie. Tam, gdzie tego nie używam, używam C.
> Sam dobierasz narzedzia do skali zadania, a innym zabraniasz.

Że co robię? Gdzie ja komukolwiek zabraniam czegokolwiek? Ja tylko
wyjaśniam, gdzie jest C++, a gdzie nie. I że C++ nie jest takim
masmem na sterydach.

>>> IMHO w C++ jedynym poważnym usprawnieniem było wprowadzenie
>>> czegoś takiego jak string. Tego tylko brakowało mi w C.
>>
>> To jakoś mało używasz C++, IMO. Mnie się podoba cała masa kontenerów
>> (biblioteka standardowa), odseparowanie reprezentacji danych od operacji
>> na nich wykonywanych, zwiększenie "code reusability" (OOP i szablony)
>> i coś, co się nazywa algorytmy uogólnione (#include <algorithm>).
[...]
>>> Do czego innego służy asembler i do czego innego służą języki wyższego
>>> poziomu.
>>
>> Zgadza się. I zupełnie inna jest konstrukcja języka tu i tam, czego
>> niektórzy nie mogą zrozumieć i uparcie twierdzą, że assembler nie różni
>> się za bardzo od C++.
> To Ty istoty sporu nie zrozumiałeś - w assemblerze mozna pisac tak samo
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> jak innych językach - kwestia makr.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Znowu ROTFL. I jak chcesz samymi makrami symulować klasy z obiektami?
A obliczenia leniwe? A funkcyjne? A co z programowaniem deklaratywnym?
Aha, i doczytaj o programowaniu funkcyjnym (albo funkcjonalnym; polska
terminologia nie jeszcze tu nie okrzepła) i deklaratywnym.
Hint: Haskell, SML, Prolog.
Albo nie, nawet nie. Pokaż mi, jakbyś chciał zrobić choć część kodu
pisanego w Perlu, Tclu albo Rubym. Przykładów poszukaj w sieci.

> C++ nie zwalnia od myślenia,
> assembler zmusza do myślenia to jedyna zasadnicza różnica.

Dla kogoś, kto nie używał C++, to i owszem, to jest jedyna większa
różnica. Dla kogoś, kto pisał w obu, C++ to coś znacznie więcej.

>>> Asembler stosuje się wtedy, gdy naprawdę zależy nam na szybkości 
>>> działana,
>>> ponieważ tylko wtedy możemy zoptymalizować program tak, aby działał on
>>> możliwie najszybciej.
>>
>> Z tego co wiem, kompilator radzi sobie z optymalizacją dużo szybciej,
>> efektywniej i bardziej przenośnie od człowieka. Co zresztą dyktuje
>> zdrowy rozsądek: optymalizator pisał cały sztab ludzi stosujących
>> wszystkie brudne tricki, jakie da się wykorzystać.
> Brudne tricki kolidują z przenośnością, można je 'uaktywniać' w C,
> zlikwidowano to całkowicie w C++. Optymalizator dysponuje
> tylko określonym zbiorem reguł. Prawdziwa optymalizacja
> to zmiana algorytmu, a nie wyrzucenie zbędnych operacji.
> Typowe to np. wywalenie jakiejś instrukcji z wnętrza pętli
> na zewnątrz - w wielu przypadkach kompilator nie ma prawa
> tego zrobić np. w przypadku wywolania funkcji.

I co to ma wspólnego z optymalizacją na poziomie kodu assemblera?

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1d58v.f5t.dozzie@hans.zsh.bash.org.pl...
> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
>>>> jako parametr makra.
>>>
>>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>> Demonizujesz pewne pojęcia.
>> Automatycznego destruktora używał juz basic napisany w latach 70tych
>
> Tak? W czym? Destruktor to pojęcie żywcem z programowania obiektowego.
> Masz klasę alokującą zasoby, które trzeba potem ręcznie zwolnić. No to
> bach, piszemy destruktor. Basic (powstały jeszcze w latach 60, nie 70)
> w latach 70 nie miał zielonego pojęcia o OOP.
Co do basica to zgoda nie będę bił się o szczegóły.
Co do OOP to były takie języki jak SIMULA 67 a więc lata 60,
później SmallTalk, Lisp czy Python też przed powstaniem C++.
Więc znowu "nihil novi sub sole".

>
>> Przestrzeń nazw w uproszczeniu to tylko dawna dyrektywa LIB
>> wskazująca na biblioteki.
>
> Zapewnia mi, że symbole z różnych przestrzeni nazw ze sobą nie kolidują?
Ciekawe jak? Jeżeli dwie różne przestrzenie maja te same nazwy i obie w 
danym
momencie używam to i tak muszę jawnie wskazać właściwą.

> Pozwala potem importować do bieżącej przestrzeni nazw ten symbol, który
> mi odpowiada?
Dokładnie tak, z bieżącej biblioteki (obecnie przestrzeni nazw)
>
>> Poliformizm danych? Wszystkie mają
>> tą samą postać, różnią sie tylko interpretacją.
>
> Co to jest "polimorfizm danych"? Nie używaj pojęć, których nie
> rozumiesz, dziękuję bardzo.
Pomyliłeś chyba polimorfizm danych z poliformizmem metod
bo z tym mamy doczynienia w OOP

pzdr
AK

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1d4ev.f5t.dozzie@hans.zsh.bash.org.pl...
> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>
>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> napisał w wiadomości news:slrne1ats9.9ri.dozzie@hans.zsh.bash.org.pl...
>>> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>>
>>
>>> ROTFL. Popisz może trochę w C++, to możemy wrócić do rozmowy. Ale w C++,
>>> a nie tylko C z cin>> i cout<<.
>> Dzięki za uznanie, programy w C pisałem 25 lat temu, C++ jakieś 15.
>                                                       ^^^^^^^^^^^^^
> To wiele tłumaczy. Wtedy faktycznie C++ było czymś tylko troszeczkę
> więcej niż C.
>
>> Faktycznie pewnie już co nieco zapomniałem bo to historyczne ciekawostki
>> sie powoli tylko robią :-P
>> Może mało efektowne były to programy bo 'real-time' i do dziś
>> pracują niezawodnie w kilkudziesięciu tysiącach urządzeń
>> telekomunikacyjnych.
>
> I to ma pokazać, że znasz C++, tak? Nie? To po co się chwalisz?
To że programuję i to nie tylko w C++.

>
>> A wracając do pisania:
>> Jako ćwiczenie napisz obsługę przerwania DMA.
>> Taką najprostszą - odebrać przerwanie, zinkrementować licznik i wykonać
>> pierwotną procedurę obsługi tego przerwania.
>> Oczywiście w czystym C++, bez użycia assemblera inline.
>> No i najlepiej niezależnie od systemu.
>
> Po co? Co mi przyjdzie z przechwycenia przerwania DMA? I dlaczego
> miałbym to pisać bez assemblera?
Dla sportu, bo się da.
>
>> Tak na oko w assemblerze to z dziesięć linijek, w C jedna, a w C++
>> deklaracji samych
>> przestrzeni nazw będzie ze trzy ekrany.
>
> Doczytaj o przestrzeniach nazw, zanim zaczniesz używać tego pojęcia.
Mam nadzieję że myślimy o tym samym - deklarowaniu "domyślnego prefiksu"
dla nazw jak w tym nieśmiertelnym przykładzie:
----------------------------------------------
#include <iostream>
using namespace std;
int main( )
{
   cout << "Hello World!" << endl;
   return 0;
}
-----------------------------------------------
#include <iostream>
int main( )
{
   std::cout << "Hello World!" << std::endl;
   return 0;
}
------------------------------------------------

>
>>> A, i ałtlóka skonfiguruj. Nie deklarujesz kodowania.
>> Nie ja tylko ałtlók nie deklaruje, niestety napisany jest w C++ które tak
>> demonizujesz.
>
> Ale ty go używasz i ty go (nie) skonfigurowałeś.
Nie ja, admistrator całej sieci i mam sie nie dotykać :(

pzdr
AK

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1d4ev.f5t.dozzie@hans.zsh.bash.org.pl...
>> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>
>>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>>> napisał w wiadomości news:slrne1ats9.9ri.dozzie@hans.zsh.bash.org.pl...
>>>> On 13.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>>>
>>>
>>>> ROTFL. Popisz może trochę w C++, to możemy wrócić do rozmowy. Ale w C++,
>>>> a nie tylko C z cin>> i cout<<.
>>> Dzięki za uznanie, programy w C pisałem 25 lat temu, C++ jakieś 15.
>>                                                       ^^^^^^^^^^^^^
>> To wiele tłumaczy. Wtedy faktycznie C++ było czymś tylko troszeczkę
>> więcej niż C.
>>
>>> Faktycznie pewnie już co nieco zapomniałem bo to historyczne ciekawostki
>>> sie powoli tylko robią :-P
>>> Może mało efektowne były to programy bo 'real-time' i do dziś
>>> pracują niezawodnie w kilkudziesięciu tysiącach urządzeń
>>> telekomunikacyjnych.
>>
>> I to ma pokazać, że znasz C++, tak? Nie? To po co się chwalisz?
> To że programuję i to nie tylko w C++.

To trochę nie trafiłeś. To pokazuje, że _kiedyś_ pisałeś, i to w C++
jeszcze sprzed czasów standaryzacji, czyli ani sensownych szablonów,
ani biblioteki standardowej.

-- 
Feel free to correct my English
Stanislaw Klekot

On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał w wiadomości news:slrne1d58v.f5t.dozzie@hans.zsh.bash.org.pl...
>> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>>> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
>>>>> jako parametr makra.
>>>>
>>>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>>>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, gdy
>>>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami zrobisz?
>>>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>>> Demonizujesz pewne pojęcia.
>>> Automatycznego destruktora używał juz basic napisany w latach 70tych
>>
>> Tak? W czym? Destruktor to pojęcie żywcem z programowania obiektowego.
>> Masz klasę alokującą zasoby, które trzeba potem ręcznie zwolnić. No to
>> bach, piszemy destruktor. Basic (powstały jeszcze w latach 60, nie 70)
>> w latach 70 nie miał zielonego pojęcia o OOP.
> Co do basica to zgoda nie będę bił się o szczegóły.
> Co do OOP to były takie języki jak SIMULA 67 a więc lata 60,
> później SmallTalk, Lisp czy Python też przed powstaniem C++.
> Więc znowu "nihil novi sub sole".

A czy ja mówię, że C++ był pierwszy? Ja mówię, że C++ to znacznie więcej
niż zestaw makr dla assemblera.

>>> Poliformizm danych? Wszystkie mają
>>> tą samą postać, różnią sie tylko interpretacją.
>>
>> Co to jest "polimorfizm danych"? Nie używaj pojęć, których nie
>> rozumiesz, dziękuję bardzo.
> Pomyliłeś chyba polimorfizm danych z poliformizmem metod
> bo z tym mamy doczynienia w OOP

To pokaż jakiś tekst o tym "poliformizmie danych". Google nic o tym nie
wiedzą, ani po polsku, ani po angielsku.

-- 
Feel free to correct my English
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1d5mo.f5t.dozzie@hans.zsh.bash.org.pl...
> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>
>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> napisał w wiadomości news:slrne1c4ok.bae.dozzie@hans.zsh.bash.org.pl...

>>> Zgadza się. I zupełnie inna jest konstrukcja języka tu i tam, czego
>>> niektórzy nie mogą zrozumieć i uparcie twierdzą, że assembler nie różni
>>> się za bardzo od C++.
>> To Ty istoty sporu nie zrozumiałeś - w assemblerze mozna pisac tak samo
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> jak innych językach - kwestia makr.
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Znowu ROTFL. I jak chcesz samymi makrami symulować klasy z obiektami?
Wiesz jak reprezentowana na etapie run-time jest klasa, a jak obiekt?
> A obliczenia leniwe? A funkcyjne? A co z programowaniem deklaratywnym?
A wyniki niedeterministyczne?
> Aha, i doczytaj o programowaniu funkcyjnym (albo funkcjonalnym; polska
> terminologia nie jeszcze tu nie okrzepła) i deklaratywnym.
> Hint: Haskell, SML, Prolog.
> Albo nie, nawet nie. Pokaż mi, jakbyś chciał zrobić choć część kodu
> pisanego w Perlu, Tclu albo Rubym. Przykładów poszukaj w sieci.
Poddaję się :-)
znam Gophera bo go używałem do szperania po sieci, Prologa bo był przydatny,
na Perlu (tym bez CGI) też sie ćwiczyło pewne algorytmy przed przełożeniem 
na
kod maszynowy. Reszty tylko pobieżnie.

Przy okazji: słyszałeś o takich językach jak: Erlang czy Chill?
Jako student IT pewnie tak.

I tu zbliżamy sie do sedna problemu :-)
Chciałbym łaskawie zauważyć że wspomniane języki są implemetowane
głównie jako interpretery, a nie kompilatory.

>
>> C++ nie zwalnia od myślenia,
>> assembler zmusza do myślenia to jedyna zasadnicza różnica.
>
> Dla kogoś, kto nie używał C++, to i owszem, to jest jedyna większa
> różnica. Dla kogoś, kto pisał w obu, C++ to coś znacznie więcej.
C++ jak sama nazwa wskazuje to zinkrementowane C czyli więcej
o ile nie nastąpiło przepełnienie rejestru :-P

>
>> Brudne tricki kolidują z przenośnością, można je 'uaktywniać' w C,
>> zlikwidowano to całkowicie w C++. Optymalizator dysponuje
>> tylko określonym zbiorem reguł. Prawdziwa optymalizacja
>> to zmiana algorytmu, a nie wyrzucenie zbędnych operacji.
>> Typowe to np. wywalenie jakiejś instrukcji z wnętrza pętli
>> na zewnątrz - w wielu przypadkach kompilator nie ma prawa
>> tego zrobić np. w przypadku wywolania funkcji.
>
> I co to ma wspólnego z optymalizacją na poziomie kodu assemblera?
No własnie nic, optymalizacja algorytmu w asemblerze i C++ kieruje się tymi
samymi zasadami i nie ma zmiłuj.
Tak było zawsze teraz i na wieki wieków amen.
Znowu nie widać różnicy :-P

pzdr
AK

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał w wiadomości news:slrne1dhf9.jfq.dozzie@hans.zsh.bash.org.pl...
> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>
>> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam>
>> napisał w wiadomości news:slrne1d58v.f5t.dozzie@hans.zsh.bash.org.pl...
>>> On 14.03.2006, Artur Kowalski <a.kowalski@cti.mikrotel.pl> wrote:
>>>>>> Używając wskaźników do danych na stosie o przesunięciu zdefiniowanym
>>>>>> jako parametr makra.
>>>>>
>>>>> Tak? A jak zapewnisz automatyczne wykonanie destruktora? A co
>>>>> z polimorfizmem? A realokacja obszaru używanego do trzymania danych, 
>>>>> gdy
>>>>> obecny zrobi się za mały? A przestrzenie nazw? Wszystko makrami 
>>>>> zrobisz?
>>>>> Ile z tego będzie trzeba wstawiać ręcznie w każdym miejscu użycia?
>>>> Demonizujesz pewne pojęcia.
>>>> Automatycznego destruktora używał juz basic napisany w latach 70tych
>>>
>>> Tak? W czym? Destruktor to pojęcie żywcem z programowania obiektowego.
>>> Masz klasę alokującą zasoby, które trzeba potem ręcznie zwolnić. No to
>>> bach, piszemy destruktor. Basic (powstały jeszcze w latach 60, nie 70)
>>> w latach 70 nie miał zielonego pojęcia o OOP.
>> Co do basica to zgoda nie będę bił się o szczegóły.
>> Co do OOP to były takie języki jak SIMULA 67 a więc lata 60,
>> później SmallTalk, Lisp czy Python też przed powstaniem C++.
>> Więc znowu "nihil novi sub sole".
>
> A czy ja mówię, że C++ był pierwszy? Ja mówię, że C++ to znacznie więcej
> niż zestaw makr dla assemblera.
>
>>>> Poliformizm danych? Wszystkie mają
>>>> tą samą postać, różnią sie tylko interpretacją.
>>>
>>> Co to jest "polimorfizm danych"? Nie używaj pojęć, których nie
>>> rozumiesz, dziękuję bardzo.
>> Pomyliłeś chyba polimorfizm danych z poliformizmem metod
>> bo z tym mamy doczynienia w OOP
>
> To pokaż jakiś tekst o tym "poliformizmie danych". Google nic o tym nie
> wiedzą, ani po polsku, ani po angielsku.
Ja też nic nie wiem, przecież wyraźnie napisałem:
"Pomyliłeś chyba polimorfizm danych z poliformizmem metod".
OK, juz wiem skąd to sie wzięło.
Zweryfikowałem gógla:
http://www.google.com/search?hl=eng&q=data+polymorphism&lr=
jednak jest takie cuś. Dwa pierwsze z brzegu:
http://www.codeproject.com/useritems/dpolymorph.asp
http://shed-skin.blogspot.com/2005/07/problem-of-data-polymorphism.html

pzdr
AK