Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Sposób na małe oszustwo [Visual Studio C++]

07 Sty 2010 02:57 2515 8
  • Poziom 10  
    Po kompilacji w trybie release program zachowuje mi się całkowicie odmiennie niż wykonywany w trybie debug, nawet po inicjacji wszystkich zmiennych jakie występują w aplikacji. Jeśli umieści się biblioteki takie jak:
    vcompd.dll
    Microsoft.VC80.DebugOpenMP.manifest
    Microsoft.VC80.DebugCRT.manifest
    oraz:
    msvcm80d.dll
    msvcp80d.dll
    msvcr80d.dll
    w katalogu z plikiem wykonywalnym .exe to można przenosić aplikację skompilowaną w trybie debug pomiędzy komputerami. Niestety osoba znająca się trochę na programowaniu, widząc te nazwy, może śmiać się ze mnie, że finalna wersja programu została skompilowana w trybie debug, a nie uśmiecha mi się szukać błędów by program działał w trybie release tak jak w wersji debug, wobec tego czy możliwe jest oszustwo polegające na zmianie nazw powyższych bibliotek na obojętnie jakie??? Czy raczej nic nie da się zmienić w Visualu, ani dodać w programie jakichś dyrektyw, bo twórcy oprogramowania tak nazwali sobie powyższe biblioteki i nie da rady zmienić ich nazw i tak by plik wykonywalny można było przenosić?
  • Poziom 26  
    Lepiej jak znajdziesz miejsca które powodują różne działanie i je poprawisz, bo Twoje rozwiązanie nie jest dobre.
  • Poziom 10  
    Nie da rady poprawić, bo już próby wielogodzinne były uczynione. Proszę o niepisanie na ten temat postu w tym wątku, bo nie po to wątek został założony by dywagować czy poprawiać czy nie, tylko czy da radę i jeśli tak to jak zmienić te nazwy, by dalej była przenośność kodu. Z góry dziękuję. Mój program nie ma tysiąca czy dwóch tysięcy linijek kodu tylko tego jest z 50 tysięcy, bo to pół roku pracy było, więc nikt nie będzie siedział kolejne pół roku by wersja release działała tak jak debug. Więc by nie zboczyć z wątku proszę o odpowiedzi do pierwszego postu.
  • Poziom 10  
    Niestety nie da się tym narzędziem złączyć plików. Ja programuje od niedawna, stąd pierwszy raz się z tym spotykam i się dziwię czemu jeszcze to na świecie nie wyszło na jaw, że w szajs-Visualu tworzysz program i sprawdzasz jego działanie w trybie debug, a ostateczną wersję wydajesz w trybie release, który rządzi się innymi prawami od debug i w efekcie twoje sprawdzanie poszło na marne, bo jeszcze raz trzeba wszystko sprawdzać i testować od nowa. Przecież to głupota jakaś. Jedna wersja powinna być i od razu powinno się mieć możliwość jej debugowania (sprawdzania). To dowód jak dzisiejsi ludzie są marionetkami i nie myślą. Takie rozwiązanie Microsoftu powinno zostać na całym świecie wyśmiane, a tu ludzie przyjęli to jako normalkę i zaakceptowali.:)
  • Poziom 31  
    kadu napisał:
    Ja programuje od niedawna, stąd pierwszy raz się z tym spotykam i się dziwię czemu jeszcze to na świecie nie wyszło na jaw, że w szajs-Visualu tworzysz program i sprawdzasz jego działanie w trybie debug, a ostateczną wersję wydajesz w trybie release, który rządzi się innymi prawami od debug i w efekcie twoje sprawdzanie poszło na marne, bo jeszcze raz trzeba wszystko sprawdzać i testować od nowa. Przecież to głupota jakaś.
    To nieprawda, że testowanie wersji Debug idzie na marne. Usuwa się wtedy sporo bardziej oczywistych problemów. Znalezienie i usunięcie ich w wersji Release byłoby trudniejsze.
    kadu napisał:
    Jedna wersja powinna być i od razu powinno się mieć możliwość jej debugowania (sprawdzania).
    Niektóre programy są publikowane w wersji Debug i świadczy to o ich niedorobieniu. Jeśli program nie działa w wersji Release, to znaczy, że ma błędy, a w wersji Debug działa z przypadku. Zgodnie ze sztuką należy te błędy znaleźć, usunąć i wydać program w wersji Release.
    kadu napisał:
    To dowód jak dzisiejsi ludzie są marionetkami i nie myślą. Takie rozwiązanie Microsoftu powinno zostać na całym świecie wyśmiane, a tu ludzie przyjęli to jako normalkę i zaakceptowali.:)
    Po pierwsze, to nie jest unikatowe rozwiązanie Microsoftu. Programy do wydania kompiluje się bez symboli debuggowych i z włączonymi optymalizacjami (i oczywiście dokładnie testuje), a wersja Debug służy tylko do ułatwienia debuggowania. W takim GCC na przykład dochodzi jeszcze śledzenie bugów w samym kompilatorze przy wyższych poziomach optymalizacji. Bezmyślne jest raczej założenie, że jak program w miarę działa w wersji Debug, to już na pewno nie ma błędów i będzie dobrze działał u klientów.
    Skoro nie zależy ci na wydajności, to może powinieneś się zainteresować łatwiejszym językiem programowania (wyższego poziomu, np. python, w którym pewnego rodzaju problemy związane z dostępem do pamięci nie występują); będzie być może mniej powodów do frustracji.
  • Specjalista elektryk
    Sam Sung napisał:
    Jeśli program nie działa w wersji Release, to znaczy, że ma błędy, a w wersji Debug działa z przypadku. Zgodnie ze sztuką należy te błędy znaleźć, usunąć i wydać program w wersji Release.

    Zgadzam się z kolegą Sam Sung. Program działa z przypadku. Może się okazać, że przy uruchomieniu na którymś komputerze błąd się ujawni. Znam gościa, ktorego program działał niby poprawnie do momentu, gdy Micro$oft coś załatał.

    kadu napisał:
    Ja programuje od niedawna, stąd pierwszy raz się z tym spotykam i się dziwię czemu jeszcze to na świecie nie wyszło na jaw,
    Ameryki kolega nie odkrył. Ja wcześniej pracowałem z Borland C++ i też mi się to parę razy zdarzyło. Oczywiście błędy znalazłem. Bardzo łatwo zresztą jest uwarunkować program, aby inaczej działał w kompilacji Release i Debug. W VS dopiero co zaczynam (i tylko C#), ale myślę, że jest podobnie jak i Borlandzie.

    kadu napisał:
    nawet po inicjacji wszystkich zmiennych jakie występują w aplikacji.

    myślałem, że jest to normalne, że wszystkie zmienne się inicjuje - inaczej to by można było zginąć, szczególnie z programem, który ma 50tys linii.

    pzdr
    -DAREK-
  • Poziom 13  
    To ja zaproponuję metodę stosowaną przez starożytnych - wydruki kontrolne.
  • Moderator Samochody
    Nie wiem jak w C++ ale w C# debugger działa zarówno w konfiguracji Debug jak i Release... i zarówno w jednej jak i drugiej można uruchomić program bez debuggera (Ctrl+F5).

    Jak mi się cuda w programie dzieją to sobie robię zrzut danych na konsolę, poza tym są fajne pułapki warunkowe.

    Tak na marginesie - to projekt w zarządzanym C++ (.NET) czy w niezarządzanym C++?