C++ Builder XE4

[nightman]

Pytanie do znających się na sprawie.
Jak zmusić kompilator, by wersję release traktował w pewnych kluczowych miejscach tak jak wersja debug?
Mam wprawdzie manię inicjalizowania każdej ze zmiennych, jednak czasami gdzieś mi się ten nawyk zapodziewa i wychodzą klocki.
Klasa posiadająca kilka zmiennych, które w konstruktorze nie są jawnie inicjalizowane podczas jego pracy inicjalizują się zerami lub nullami w trybie DEBUG. Niestety przekompilowanie tego do wersji release nie działa identycznie i zmienne inicjalizują się śmieciami, co powoduje różne i niekoniecznie oczekiwane zachowania programu.

Pomijam temat, przeglądnąć cały kod i zainicjalizować zmienne - to już zrobiłem i teraz programik działa ok, jednak nie mogę trafić na opcję która załatwia tę sprawę w ustawieniach. Podobno jest, pytanie czy jestem aż tak ślepy?

[Cyfrowy Baron]

Przecież w trybie release program nie jest debudowany, więc czego właściwie oczekujesz? Może o to: menu Project Options sekcja C++ Compiler Debuggin. W sekcji po prawej stronie w polu Target wybierasz Release Configuration a tabeli poniżej zaznaczasz ptaszkiem opcje: Debug information = true; Debug line number information = true; Expand inline function = false;

[nightman]

Przecież w trybie release program nie jest debudowany,

I bardzo dobrze, że nie jest.

więc czego właściwie oczekujesz? Może o to: menu Project Options sekcja C++ Compiler Debuggin. W sekcji po prawej stronie w polu Target wybierasz Release Configuration a tabeli poniżej zaznaczasz ptaszkiem opcje: Debug information = true; Debug line number information = true; Expand inline function = false;

Gdybym chciał wypuszczać wersje DEBUG zamiast RELEASE, lub wersje RELEASE z informacją DEBUG, to tak bym robił. Nie ma to jednak sensu.

O co mi właściwie chodzi? O coś takiego kolego.
int x; - deklaracja w headerze klasy...

Obiekty klasy, tworzą trzy konstruktory stosowane rzecz jasna zamiennie...Ręczna inicjalizacja wszystkich "x" zerami w każdym z nich wygląda źle/dziwnie gdyż zmiennych/wskaźników jest całkiem sporo itp.
Próba odczytu takiego "x" w trybie DEBUG daje wynik ZERO.... i tutaj się cieszę, próba odczytu w trybie RELEASE tego samego "x" po tych samych operacjach daje wynik "%!%$@%#$@" - czyli śmieci. Wniosek prosty, w trybie DEBUG kompilator inicjalizuje z automatu zmienne ZERAMI, NULLAMI itp, w trybie RELEASE tego nie robi. Pytanie zatem czemu i gdzie przestawić kompilator, żeby w wersji RELEASE też nulował zmienne automatycznie tak jak to robi w trybie DEBUG.

Prościej się już nie da tego napisać. Ciekawostką jest to, ze BCB6 nie miał tego problemu.

[polymorphism]

To nie środowisko ma problem, tylko Ty. W standardzie języka masz jednoznacznie opisane, kiedy zmienne są zerowane, a kiedy nie. W przypadku, o którym piszesz, kompilator zachowuje się poprawnie. Jak chcesz mieć składowe klasy wyzerowane, to od tego jest konstruktor, żeby je tam wyzerować. A jak masz dużo konstruktorów w klasie, to po prostu napisz sobie metodę, która ustawia odpowiednio składowe, i daj jej wywołanie na początku każdego konstruktora.

[nightman]

To nie środowisko ma problem, tylko Ty. W standardzie języka masz jednoznacznie opisane, kiedy zmienne są zerowane, a kiedy nie. W przypadku, o którym piszesz, kompilator zachowuje się poprawnie. Jak chcesz mieć składowe klasy wyzerowane, to od tego jest konstruktor, żeby je tam wyzerować. A jak masz dużo konstruktorów w klasie, to po prostu napisz sobie metodę, która ustawia odpowiednio składowe, i daj jej wywołanie na początku każdego konstruktora.

Nie obraź się "kolego", prosiłem o odpowiedzi kogoś kto ma pojęcie o temacie. Skoro jednak się wypowiedziałeś i jednocześnie tak się przykleiłeś standardu, to mi odpowiedz, z jakiego powodu tryb DEBUG działa wg jednego standardu a tryb RELEASE wg innego i gdzie te STANDARDY w ustawieniach ujednolicić.
Nie odbierz tego jako sarkazm, po prostu chcę się uczyć od mądrzejszych.

[polymorphism]

A dlaczego twierdzisz, że w trybie debug działa według innego standardu niż release? Bo w wersji debug masz wyzerowane wskaźniki i zmienne? W C/C++ domyślnie zerowane są tylko zmienne globalne/statyczne (mowa o typach skalarnych). Zmienne lokalne niestatyczne i składowe klas/struktur nie mają przypisywanej wartości domyślnej, to leży w gestii programisty. A że masz tam zera w debug - czysty przypadek. Niezainicjalizowana zmienna może zawierać cokolwiek, nawet wartość zero.

Masz po prostu kod z błędami, które w wersji release wyłażą. Nihil novi. Popraw je i problem zniknie.

p.s. nie wyjeżdżaj mi tu z "pojęciem o temacie", bo to nie ja mam problem z podstawami, tylko Ty

[nightman]

@polymorphism, poczytaj wątek od początku bo się ciut pogubiłeś - może dojdziesz do faktycznego sedna mojego pytania. Czytanie ze zrozumieniem nie boli
Jesteś dla mnie mistrzem pisania kodu i w kwestii nie ma dwóch zdań. Z wypowiedzi sądzę, że przerobiłeś miliony linii kodu, stworzyłeś dziesiątki programów narzędziowych a Twoje produkty sterują liniami przemysłowymi dla zagadnień JustInTime. Nie podważam więc Twojej wiedzy, lecz sens Twojej odpowiedzi, który z góry jest nastawiony na moją totalną niewiedzę. Szkoda.
Nie szukam wyjaśnień podstaw, bo nie o to idzie, lecz rozwiązania jak zmusić kompilator do nullowania zmiennych dla wersji RELEASE - identycznie jak to robi dla wersji DEBUG, przy czym nie chce by moja RELEASE była wersją DEBUG nawet w kilku procentach.
Jak zapewne przeczytałeś na początku wątku, cierpię na wręcz maniakalną zasadę ręcznego inicjalizowania zmiennych i nie cierpię kiedy kompilator robi coś za mnie w dodatku za moimi plecami ( XE4 ma do takiego magicznego działania szczególne skłonności ). Odpowiadanie, że mam problemy z niezainicjalizowanymi zmiennymi nie wnosi w temat niczego, podobnie jak powoływanie się na standardy jest tutaj bez sensu.
Swoją drogą, jakoś nie trafiłem na standard języka C++ dla wersji DEBUG i standard C++ dla wersji RELEASE - .... Jeżeli znasz takie rozróżnienia to poproszę, wszak człowiek uczy się całe życie.

Trybisz teraz @polymorphism sens pytania, czy dalej będziesz mi robił wykłady z podstaw i standardów C++ ?
Nie ma sensu więc walczyć ze sobą i wykładać sobie podstawy. Jeżeli wiesz jak zmienić ustawienia ( podobno się da, ale jakoś nie umiem na to trafić ) to napisz - dzięki z góry, jeżeli nie wiesz, to po prostu odpuść sobie temat.

[polymorphism]

@nightman, ja doskonale zrozumiałem, o co Tobie chodzi, tylko:

(...) cierpię na wręcz maniakalną zasadę ręcznego inicjalizowania zmiennych i nie cierpię kiedy kompilator robi coś za mnie w dodatku za moimi plecami

(...) jednak czasami gdzieś mi się ten nawyk zapodziewa i wychodzą klocki.

Czyli szukasz opcji, która "poprawi" twoje błędy. Ze standardem wyjechałem dlatego, ponieważ stwierdziłeś, że twoje IDE ma jakiś problem (którego BCB6 nie ma). Chciałem Ci jedynie uzmysłowić, że takiego problemu nie ma. Nawet jeśli jest opcja automatycznego inicjalizowania zmiennych, to nie zdziwiłbym się, gdyby była ona ograniczona tylko do trybu debug, bo prawdopodobnie na potrzeby diagnostyki ona powstała.

Swoją drogą, jakoś nie trafiłem na standard języka C++ dla wersji DEBUG i standard C++ dla wersji RELEASE - .... Jeżeli znasz takie rozróżnienia to poproszę, wszak człowiek uczy się całe życie.

A gdzie ja twierdzę, że jest jakieś rozróżnienie? Tryb kompilacji nie ma w ogóle związku ze standardem czy regułami/gramatyką języka.

[nightman]

Czyli szukasz opcji, która "poprawi" twoje błędy.

Nareszcie gadany z sensem, jednak nie chodzi o moje domniemane błędy, lecz o uczynienie mnie "szczęśliwym leniem".

A gdzie ja twierdzę, że jest jakieś rozróżnienie? Tryb kompilacji nie ma w ogóle związku ze standardem czy regułami/gramatyką języka.

Jeżeli idzie o jakiś wymysł standardu C++ DEBUG czy C++ RELEASE, to jasne że takiego rozdzielania w standardach języka nie ma, bo i jak ma być skoro tryb RELEASE/DEBUG to tryb pracy kompilatora a nie języka. Pisząc o trybach i ich ustawieniach Ty mi jedziesz na siłę o standardach. Skoro więc obaj wiemy co znaczy RELEASE/DEBUG a Ty mi podajesz uparcie standardy, to stąd pojawia się moje ciut ironiczne pytanie o przykłady.

Nie zrozum mnie źle i mam nadzieję że się nie obraziłeś, ale lubię się czasami poprzegadywać, szczególnie jak dwóch rozmówców ciągnie temat w dwie różne strony Ty starasz się przedstawić mi opcję, gdzie kod w którym pozostawienie zmiennych tylko zadeklarowanych może powodować, że znajdziemy w nich śmieci - tu się zgadzam w 100%, a ja ciągnę w kierunku, "jak zmusić kompilator do automatycznego inicjalizowania tych zmiennych w RELEASE, skoro dla DEBUG to potrafi robić". Pomijam, czy jest to zgodne ze standardem języka czy nie. Pytanie jak, skoro on to umie zrobić.

[Cyfrowy Baron]

Stworzyłem testowy program i w sekcji private pliku nagłówkowego zadeklarowałem zmienną test typu int. Nic więcej z tą zmienną nie zrobiłem. Sprawdziłem zawartość zmiennej takim kodem:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::Button1Click(TObject *Sender)
{
 ShowMessage( IntToStr(test) );
}

Skompilowałem program zarówno jako RELEASE jak i DEBUG i w obydwu przypadkach zwraca mi 0. Może czegoś nie rozumiem, ale nie ma znaczenia jak jest kompilowana aplikacja, zawsze zwraca mi 0. Korzystam ze środowiska C++Builder XE2, wersja 16.0.4429.46931

Podaj przykład kodu, w którym u ciebie jest w DEBUG zero a w RELEASE śmieci.

[nightman]

Unit 1 - header

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

class TForm1 : public TForm
{
__published:    // IDE-managed Components
        TButton *Button1;
        TListView *ListView1;
        void __fastcall FormCreate(TObject *Sender);
        void __fastcall FormDestroy(TObject *Sender);
        void __fastcall Button1Click(TObject *Sender);

private:        // User declarations
        TList *tlLista;
        void __fastcall UtworzObiekty();
        void __fastcall KasujListe();
        void __fastcall ShowValuesInList();
public:         // User declarations
        __fastcall TForm1(TComponent* Owner);
};
//---------------------------------------------------------------------------
extern PACKAGE TForm1 *Form1;
 

Unit1.cpp

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
        : TForm(Owner)
{
        tlLista = NULL;
}
//---------------------------------------------------------------------------
void __fastcall TForm1::UtworzObiekty()
{
        for(int i=0;i<5000;i++)
        {
                tlLista->Add(new TKlasa());
        }
}
//---------------------------------------------------------------------------
void __fastcall TForm1::KasujListe()
{
        TKlasa *ptrKlasa = NULL;
        while(tlLista->Count>0)
        {
                ptrKlasa = (TKlasa *)tlLista->Items[0];
                if(ptrKlasa!=NULL)
                {
                        tlLista->Remove(ptrKlasa);
                        delete ptrKlasa;
                        ptrKlasa = NULL;
                }
         }
}
//---------------------------------------------------------------------------
void __fastcall TForm1::ShowValuesInList()
{
        TListItem *tlItem;
        ListView1->Clear();
        TKlasa *ptrKlasa;
        for(int j=0;j<tlLista->Count;j++)
        {
                ptrKlasa = (TKlasa *)tlLista->Items[j];
                if(ptrKlasa!=NULL)
                {
                        tlItem = ListView1->Items->Add();
                        tlItem->Data = ptrKlasa;
                        tlItem->Caption = IntToStr(j);
                        tlItem->SubItems->Add(IntToStr(ptrKlasa->X));
                        tlItem->SubItems->Add(FloatToStr(ptrKlasa->Y));

                }
        }
}
//---------------------------------------------------------------------------
void __fastcall TForm1::FormCreate(TObject *Sender)
{
        tlLista = new TList();
}
//---------------------------------------------------------------------------
void __fastcall TForm1::FormDestroy(TObject *Sender)
{
if(tlLista!=NULL)
{
        KasujListe();
        delete tlLista;
        tlLista=NULL;
}
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
UtworzObiekty();
KasujListe();
UtworzObiekty();
ShowValuesInList();
}
//---------------------------------------------------------------------------
 

Unit2.header

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

//---------------------------------------------------------------------------
class TKlasa
{
        int x;
        float y;
public:
        __fastcall TKlasa();

        __property int X = {read=x};
        __property float Y = {read=y};
};
//---------------------------------------------------------------------------
 

Unit2.cpp

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

//---------------------------------------------------------------------------
__fastcall TKlasa::TKlasa()
{
//celowo zmienne x oraz y nie zostały zainicjalizowane;
}
//---------------------------------------------------------------------------
 

System : Win7 64 bit
środowisko : Embarcadero® C++Builder® XE4 Version 18.0.4854.59655
Kompilacja dla 32 bitowców
Jeżeli dasz mi możliwość podesłania załączników, to służę. Podam wersję DEBUG i wersję RELEASE jaka wychodzi po kompilacji.

[Cyfrowy Baron]

U mnie twój kod zarówno w debug jak i w release daje 0. W załączniku przykłady obydwu wersji.

Jeżeli dasz mi możliwość podesłania załączników, to służę. Podam wersję DEBUG i wersję RELEASE jaka wychodzi po kompilacji.

Sprawdziłem twoje uprawnienia i możesz wstawiać załączniki do postów, więc nie rozumiem w czym problem.

[nightman]

U mnie twój kod zarówno w debug jak i w release daje 0. W załączniku przykłady obydwu wersji.

Ciekawe i zastanawiające zarazem. Odpaliłem oba Twoje przykłady i oba mają mniej więcej od połowy śmieci w zmiennych - czyli tak jak powinno być. Jest to jednak ciut coś innego niż piszesz. W załączniku podałem oba przykłady "po mojemu" wraz z bibliotekami.

Sprawdziłem twoje uprawnienia i możesz wstawiać załączniki do postów, więc nie rozumiem w czym problem.

Heh, prawa faktycznie są, natomiast problem tkwi w magicznej zakładce, której po prostu nie widać w dostępnym szablonie

Jednak temat nie tyczy tego drobiazgu - to tylko gwoli zrozumienia problemu.

[Cyfrowy Baron]

Heh, prawa faktycznie są, natomiast problem tkwi w magicznej zakładce, której po prostu nie widać w dostępnym szablonie

Tak to wygląda tylko w Firefox. Niestety nie znam się na skryptach PHP i nie potrafię tego poprawić. Niemniej jednak, da się tego używać.

Odpaliłem oba Twoje przykłady i oba mają mniej więcej od połowy śmieci w zmiennych - czyli tak jak powinno być. J

Tylko u ciebie, u mnie są same zera.

---

U mnie twoje programy działają dokładnie tak samo. Jeśli chcesz mogę ci to pokazać na SKYPE poprzez udostępnianie ekranu. Winny jest więc twój system.

[nightman]

Tak to wygląda tylko w Firefox. Niestety nie znam się na skryptach PHP i nie potrafię tego poprawić. Niemniej jednak, da się tego używać.

Oczywiście, że się da - jeżeli się wie, że to tam powinno być . Na forum nie pisze "not for FireFox", a skoro pisałeś, że nie rozumiesz tematu to chciałem Ci wyjaśnić czemu nie widzę opcji załączników.

Winny jest więc twój system.

Widzę kolego, że jesteś kimś w rodzaju informatyka - szukasz winnych - to mnie nie interesuje, ja szukam rozwiązań, niemniej jednak dziękuję za konwersację. Wszak wiadomo, że zmienne po zdefiniowaniu powinny zostać zainicjalizowane zanim ich użyjemy i to nie ulega dyskusji - przynajmniej w C++.
Trikulca z jakimś automatycznym inicjalizowaniem nullami widziałem jednak już w Deplhi6 prof a i moje dawne BCB6 też tak jakoś dziwacznie ustawione było ( ciekawe bo z automatu ). Mniejsza o to - było minęło.
Bez żadnych ingerencji "z niebios" niezainicjalizowane zmienne mogą wprawdzie posiadać zerowe wartości, ale to występuje po pierwszym starcie programu, z tym, że żadnej gwarancji nie ma, że tam te zera będą. Efekt taki, wynika ze specyfiki rezerwacji pamięci dla zmiennych, że o typach wskaźnikowych nie wspomnę bo to trochę inna para kaloszy, choć w zasadzie idea podobna.
Sytuacja z rezerwacją zostaje wyolbrzymiona w momencie zadziałania managera pamięci i ssaniu dodatkowej przestrzeni przez naszą apkę ( czyli np zabawie w new/delete na setkach/tysiącach obiektów ). Kolejne tworzone obiekty powinny być ładowane śmieciem - czemu raz się dzieje tak, że dostajemy nulle a raz śmieci? Zarówno w teorii jak i w praktyce powinniśmy dostać śmieci, bo pochłanianie pamięci na potrzeby programu działa mniej więcej tak....

Mała konwersacja slave'a, czyli naszej apki oraz mastera - czyli windozy....
- NaszaApka do Windowsa - "...siema Windoza potrzeba więcej zasobów, zapodaj bro potrzebującym pamięć jak masz..."
- Windows, odpowiada kulturalnie naszej NaszaApka - "...Siema ziom, dawno się nie odzywałaś ile zadilować ? tam jest tyle a tyle wolnego - kopsnij bom dziś dobry...."
ewentualnie Windows odpowiada mniej kulturalnie - " bujaj się szmaciarzu, nie ma dilu". Otrzymujemy wtedy super info "out of...." Jeżeli jednak windoza jest kulturalna to konwersjacja trwa dalej....
- NaszaApka informuje Windowse - "...Thx bro, biorę ile mi potrzeba na tę chwilę a ty lamusie pamiętaj, żeby tej pamięci komuś innemu jeszcze nie dać..."

W efekcie nasza apka dostaje coś, co wcześniej śmiało mogło i zapewne było przez windoze i jego podopiecznych używane na jakieś inne potrzeby. Niekoniecznie jest to świeży obszar, więc będą tam shity które my poprzez inicjalizację zmiennej odpowiednio sobie czyścimy. Jeżeli zmiennej nie zainicjalizujemy będziemy mieć szajs...a przynajmniej powinniśmy ten szajs mieć. Chyba że coś czuwa nad nami z góry a nam ten szajs ślicznie nuluje.
Mając na uwadze powyższe, pomimo wszystko stawiam na ustawienia "komplikatora" ewentualnie managera pamięci a nie sam system, gdyż przesłane w załącznikach przykłady sprawdziłem na 4 testowych systemach Win7 64/32b, WinXP 32b, Win8 64b i starej Win98. Wyobraź sobie, na wszystkich efekt jest identyczny . Mając na uwadze ogólne mechanizmy dilerki pamięci, trochę dziwią mnie te Twoje zera, szczególnie na moich kompilantach...

Wątek moim zdaniem ciekawy - raz działa coś tak, innym razem ciut inaczej... Niestety, ze względu na to, że nikt w temacie zmiany ustawienia nie potrafi wiele konstruktywnego dodać a sam temat raczej kręci się w obszarze "poprawności pisania kodu" - temat kieruje do zamknięcia.
Dzięki wszystkim za chęci i zapoznanie w formie konwersacyjnej.