[bcb] Szyfrowanie

[matijas6113]

Witam ponownie:)

 

A więc nie ważne o co pytałem w ostatnim poście jeśli ktoś czytał mimo ze będzie go dotyczyć po części. Chce zrobić szyfrowanie w BCB ale proszę czytać dalej, umie zrobić je za pomocą StringReplace

ale dla mnie efektywniejsze by było szyfrowanie na binar;] w zwykłym c++(korzystam z deva) poradziłem sobie bez problemu ale w BCB ten sposób mi trochę nie działa:

kod jest już trochę zmieniony (pod bcb) i tez nie chce odpowiedzi ze nie jest optymalny czy coś, po prostu się uczę sam i potem sam się zastanawiam co można zrobić inaczej i lepiej.

 

kod: (tylko ten co ma szyfrować bo chyba więcej nie potrzeba)

 

void __fastcall TForm1::Button1Click(TObject *Sender)

{

int dl,k=0,j;

napis=Memo1->Lines->Text;

dl=Memo1->Lines->Text.Length();

while (k<dl)

{

j=napis[k];

tekst2="";

while (j>0)

{

if(j%2==0) Memo2->Lines->Text.Insert("0",0);

else Memo2->Lines->Text.Insert("1",0);

j=j/2;

}k++;

}

}

//---------------------------------------------------------------------------

 

Proszę o jakąś podpowiedź

[PelzaK]

ale co konkretnie trochę nie działa... postaw sobie breakpointa na początku funkcji i potem krok po kroku puszczaj program po linii sprawdzając co jest w zmiennym (najeżdżając na nie myszką). Jak się uczysz to się ucz debugowania :)

[matijas6113]

jestem takim samoukiem... nie mam żadnej ksiązki tylko sam kombinuje bo znam troche podstaw jezyka no i coś tam z neta biore. Do czego jest debugowanie tak prostym językiem jeśli można??

[PelzaK]

de - od, bug - pluskwa, er - wykonawca czynności, czyli odpluskwiacz w bardzo głupim polskim tłumaczeniu :). Jest to narzędzie bez którego praca programisty była by najcięższym zawodem świata, i służy do usuwania błędów (bugów).

 

Musisz po pierwsze w opcjach kompilacji projektu mieć zaznaczoną/wybraną opcję DEBUG, nie RELEASE. Wtedy kompilator dorzuca mnóstwo zbędnego kodu, który pomaga w wyłapywaniu błędów wszelakiej maści, w śledzeniu wartości zmiennych etc. Z Twojego punktu widzenia objawia się to tylko tym, że sam program działa nieco wolniej w kompilacji DEBUG. Następnie uruchamiasz program ze środowiska ale nie opcją RUN tylko RUN DEBUG. W visual studio jest to skrót F5 z debugerem, ctrl+F5 - bez debugera.

 

Zapewne wielokrotnie włączałeś program z debugerem nawet o tym nie wiedząc, przez co nie skorzystałeś :). Teraz.. w swoim kodzie, np na początku metody Button1Click klikasz prawym klawiszem myszki i będzie tam opcja BREAKPOINT, tudzież wystarczy kliknać na lewo od kodu aby pojawiła się czerwona zazwyczaj kulka. Odpalasz program z debugerem, i jak program dojdzie do miejsca w kodzie gdzie jest breakpoint, to program się zatrzyma i będziesz miał strzałkę wskazująca linię kodu do wykonania.

Następnie (w visual studio) masz opcje STEP OVER (F10), STEP INTO (F11) i naciskając je widzisz jak wykonuje się program linijka po linijce. Step into powoduje wejście w wywołanie funkcji jeśli takowa jest do wykonania.

Przy okazji najeżdzając myszką na dowolną zmienną pojawi Ci się informacja o jej typie, wartości, jesli jest to typ nieprosty to będziesz mógł sobie rozwijać i podglądać jego zawartość (np obiekty klas).

 

Warto także zwrócić uwagę na takie okna jak:

- stack trace - pokazuje Ci dokładnie która metodą którą wywołała, mozesz się oczywiście przenosić pomiędzy metodami sprawdzając wartości zmiennych/obiektów (warto miec to na stałe widoczne w debugu)

- quick watch

- autos - automatycznie pokazuje wartości zmiennych będących aktualnie w zakresie (warto miec to na stałe widoczne w debugu)

- output - tu można sobie pisać (trejsować TRACE) rózne rzeczy z kodu uzywając odpowiednich komend (W .NETcie np System::Diagnostics::Trace::Writeln("blabla");)

 

Dzięki temu możesz sprawdzić dlaczego kod wykonuje się tak a nie inaczej, i porównać to co wg Ciebie powinny zawierać zmienne z tym co faktycznie zawierają.

Owocnej pracy ;]

[matijas6113]

Wielkie dzięki:D:)