Jak rozumieć warunek w którym argumentem jest wskaźnik

0

Rozważmy pewien kawałek kodu

int *wsk = nullptr; //cleowo nie ustawiam na coś wskaźnika

if(wsk)
{
  cout << "wskaźnik NIE zawiera adresu" << endl;
}
else{
  cout << "wskaźnik zawiera adres" << endl;
}

Czytałem, że wskaźnik podawany w argumencie jest niejawnie konwertowany na typ BOOL.

Teraz celowo uczepię się fragmentu kodu if(wsk) przy tak postawionym warunku wynik mam następujący

wskaźnik NIE jest pusty

jak nie jest pusty, skoro zawiera wartość NULL, ZERO ? Natomiast gdy zrobię w ten sposób

int *wsk = nullptr; //cleowo nie ustawiam na coś wskaźnika

if(wsk == nullptr) //tutaj daję w warunku do czego ma być porównany
{
  cout << "wskaźnik NIE zawiera adresu" << endl;
}
else{
  cout << "wskaźnik zawiera adres" << endl;
}

wynik mam

wskaźnik jest pusty

no to teraz rozważmy dalej poniższy kod

int main()
{
    int *wsk = nullptr;
    int liczba;

    wsk = &liczba;

    if(wsk == nullptr){
        cout << "wskaźnik NIE zawiera adresu" << endl;
    }
    else{
        cout << "wskaźnik zawiera adres" << endl;
    }

    return 0;
}

przy powyższym kodzie wynik mam wskaźnik zawiera adres

Natomiast jak znowu nie porównam z niczym - kod poniżej

int main()
{
    int *wsk = nullptr;
    int liczba;

    wsk = &liczba;

    if(wsk){ //tutaj celowo NIC nie porównuję
        cout << "wskaźnik NIE zawiera adresu" << endl;
    }
    else{
        cout << "wskaźnik zawiera adres" << endl;
    }

    return 0;
}

to wynik mam wskaźnik NIE zawiera adresu

Więc na podstawie powyższych rozważań pytanie jest następujące

Skoro warunek zwraca inne wyniki, niż wynika to z teorii (czyli wskaźnik POWINIEN być NIEJAWNIE konwertowany na typ BOOL) - to jak należy rozumieć zapis

if(wsk) ? że do czego jest porównywany ? Albo, że co zwraca ? Albo ktoś wyjaśni ?

Tak poważnie, to już zgłupieć można, bo spotykam się z zapisami if(wsk) - nie wiem co jest teraz prawdą, a co kłamstwem ? Jaka prawidłowa wartość jest zwracana ? Jak TEORETYCZNIE wskaźnik niejawnie jest konwertowany na typ BOOL, to powinien być konwertowany, a wychodzi na to, że nie jest

Wiem, że zaraz będziecie się tu nabijać itp itd... mam gdzieś ludzi głupio-mądrych, bo jak nie potrafią racjonalnie wyjaśnić prostej rzeczy, to dla mnie taki osobnik sam nie rozumie tematu i tylko bezmyślnie zakuł regułki podane w książce, a to, że jemu w robocie kod wychodzi, to już inna bajka.

Więc czytając wszystkie kursy, stanowisko powinno być jedne, spójne i nie powinno wprowadzać zamętu, a w praktyce jest zupełnie inaczej.

PS. Dla ciekawości podam, że jak jawnie ustawię if(wsk == true) kompilator mówi mi coś takiego

screenshot-20230219100520.png

4
zkubinski napisał(a):

Rozważmy pewien kawałek kodu

int *wsk = nullptr; //cleowo nie ustawiam na coś wskaźnika

if(wsk)
{
  cout << "wskaźnik NIE zawiera adresu" << endl;
}
else{
  cout << "wskaźnik zawiera adres" << endl;
}

Dokładnie na odwrót. Nie wiem skad to przywlokłeś, pewnie od kogoś początkującego, bo takiego śmiecia w necie najwiecej

Cała niejawna konwersja wszystkiego na bool zakłada że null, zero (zmienno / stało przecinkowe) to false

Jedna z cech C, z których nie należy się cieszyć, a jeden z większych syfów tego jezyka.

0

Jerzy Grębosz symfonia C++ rozdział 8.13.

Masz strukturę zmiennej, pole adres,pole wartość,pole rozmiar,pole numer w tablicy(nazwa).
Czyli jeśli wskaźnik ma to samo, to w polu "adres" - nie ma nic?
Myślisz, że to jest dynamicznie alokowane? Pole zmiennej w której jest wartość?
Tu by trzeba było użyć ... drugiego wskaźnika.
A dla tego drugiego wskaźnika... kolejny wskaźnik.

Rozumiesz?

Bo to trzeba tak jak śpiewała Morcheeba "just enjoy the ride".

A jak bardzo chcesz to dawaj printf("adres wskaznika to -%ud",wsk);
Czy jak tam się unsigned int wyświetla.

Ja uważam, że nie potrzebujesz nic wiedzieć o wskaźniku dokąd go nie zapisujesz albo nie odczytujesz.
A tutaj idziesz w obszary w obszary inne.
Uważam, że tracisz czas, chyba że będziesz opracowywał nowy system operacyjny albo nowy język programowania, ale wtedy takie rzeczy mówisz mi.

0
zkubinski napisał(a):

if(wsk) ? że do czego jest porównywany ? Albo, że co zwraca ? Albo ktoś wyjaśni ?

if, jak zawsze, potrzebuje, żeby jego warunek (tzn. if (warunek) {…}) był boolem. Zatem wsk jest rzutowany na boola. W standardowy sposób.

Tak poważnie, to już zgłupieć można, bo spotykam się z zapisami if(wsk) - nie wiem co jest teraz prawdą, a co kłamstwem ?

Co do zasady¹, puste lub zerowe wartości są fałszem, a wszystkie inne — nie. Wskaźniki nie są wyjątkiem.

Jaka prawidłowa wartość jest zwracana ?

Prawidłowa wartość zwracana dla nullptr to false, dla wszystkich innych — true.

Jak TEORETYCZNIE wskaźnik niejawnie jest konwertowany na typ BOOL, to powinien być konwertowany, a wychodzi na to, że nie jest

Nie wiem, skąd ten wniosek. Konwersja jak najbardziej zachodzi.

Wiem, że zaraz będziecie się tu nabijać itp itd... mam gdzieś ludzi głupio-mądrych, bo jak nie potrafią racjonalnie wyjaśnić prostej rzeczy, to dla mnie taki osobnik sam nie rozumie tematu i tylko bezmyślnie zakuł regułki podane w książce, a to, że jemu w robocie kod wychodzi, to już inna bajka.

🤷

Więc czytając wszystkie kursy, stanowisko powinno być jedne, spójne i nie powinno wprowadzać zamętu, a w praktyce jest zupełnie inaczej.

Skąd ten wniosek? Który kurs Ci tak namieszał?

PS. Dla ciekawości podam, że jak jawnie ustawię if(wsk == true) kompilator mówi mi coś takiego

Kompilator uważa, poniekąd słusznie, bool za liczbę — zaszłość mocno z C łupanego, ale ma to swój sens i w „nowoczesnym” C++. Traktowanie wskaźnika jako liczby bardzo rzadko kiedy ma sens i prowadzi do czegoś sensownego, zatem kompilator słusznie się czepia. Dlaczego zatem się nie czepia, gdy nie porównujesz tego w ten sposób? Bo kompilator stara się uchronić Cię przed porównaniem wskaźnika z intem, a bez, no cóż, porównania, tego nie robisz — tylko albo w if (wsk) rzutujesz ten wskaźnik (po coś — kompilator cierpi tutaj na krótkowzroczność i nie widzi jeszcze po co), a w if (wsk == nullptr) porównujesz ze wskaźnikiem.

tl;dr; Uznałeś na odwrót, co jest prawdą, a co kłamstwem, i potem wokół tego dobudowałeś sobie uzasadnienie niewiadomego pochodzenia i wątpliwej prawdziwości.


¹ Tzn. ta konwencja jest dla typów standardowych i wśród wszystkich tych, którzy się trzymają tej konwencji, a nie cudują.

2

@Althorion:

Jestem za każdym razem coraz bardziej zdziwoony, jak kolega PO LATACH ujawnia coraz bardziej podstawowe braki.
Za każdym razem chciałbym wierzyć "no dobra, tego nie wie, ale może ma jakieś ugruntowanie"

W ostatnich dniach pokazał, że pękają podstawowe abstrakcje (klasa / instancja), tu elementarz C.

0

masz internet, masz kursy a nie korzystasz z tego w ogóle? Ba masz chatgpt który nie wszystkieo wyjaśnia dokładnie ale nawet z jego odpowiedzi idzie co nieco wyciągnąć. Ale po co?
cppkubinski.png

1
Althorion napisał(a):

Co do zasady¹, puste lub zerowe wartości są fałszem, a wszystkie inne — nie. Wskaźniki nie są wyjątkiem.

Jaka prawidłowa wartość jest zwracana ?

Prawidłowa wartość zwracana dla nullptr to false, dla wszystkich innych — true.

Przy czym standard wcale nie wymaga, by nullptr był wskaźnikiem o wszystkich bitach zerowych.
Konkretna (egzotyczna) platforma może wymagać, by wskaźnik zerowy (nullptr, NULL, (void*)0) miał inną fizyczną reprezentację niż (uintptr_t)0.

0
ZrobieDobrze napisał(a):

Dokładnie na odwrót. Nie wiem skad to przywlokłeś, pewnie od kogoś początkującego, bo takiego śmiecia w necie najwiecej

zacząłem drążyć temat listy jednokierunkowej aby dowiedzieć się czegoś więcej - więc znalazłem kilka stron i na jednej z nich jest poniższy kod - ściślej przytoczę tutaj fragment kodu

osoba *temp = pierwsza;
        
        while (temp->nastepna) // <--- właśnie zaczęło mnie to zastanawiać
        {
            // znajdujemy wskaźnik na ostatni element
            temp = temp->nastepna;
        }

więc skoro tam jest while (wskaźnik) to w nawiasie jest jakiś warunek, a warunek powinien być do czegoś przyrównany - więc nie wiem jak mam rozumieć ten zapis ? Drążąc temat natknąłem się na takie wyjaśnienie

więc zrobiłem sobie kod jak na początku posta, a że wychodzą z tego jakieś głupoty, to postanowiłem rozwiać swoje wątpliwości zadając pytanie tutaj

1

@zkubinski:

więc skoro tam jest while (wskaźnik) to w nawiasie jest jakiś warunek, a warunek powinien być do czegoś przyrównany

No nie właśnie, co Ci próbowaliśmy — niestety bezskutecznie — wytłumaczyć… już przynajmniej z pięć razy. Warunki są wyrażeniami logicznymi. Porównanie czegoś do czegoś jest wyrażeniem logicznym, prawda, ale nie jest jedynym możliwym wyrażeniem logicznym. Nie ma potrzeby porównywania warunku z czymkolwiek.

więc nie wiem jak mam rozumieć ten zapis ?

while (cokolwiek) {…} to „zewaluuj cokolwiek i tak długo, jak będzie prawdą, rób ”. Ewaluacja wskaźnika — rzutowanie na boola — działa, jak pisałem, wg standardowej logiki C(++). nullptr jest fałszem, wszystko co nie jest nullptrem jest prawdą.

Zaakceptowana odpowiedź z zalinkowanego przez Ciebie tematu na Stacku Ci powiedziała wszystko, co wiedzieć powinieneś i podała źródło.

no to wyjaśnij jak rozumieć zapis while(wskaźnik) - bo do mnie ten zapis nie dociera - nie wiem jak sobie to uzmysłowić

Tak jak zawsze przy warunkach. Program będzie sprawdzał wartość logiczną wskaźnik, wg swoich reguł. Dla wskaźnika brzmią one, bardzo podobnie do tego, jak brzmią zawsze przy standardowych typach¹, „jeśli to nullptr, to fałsz; jeśli nie, to prawda”.

jak wskaźnik wskazuje na coś to MUSI zawierać JAKIŚ adres byle adres był w formacie np 0xFFFFF, a nie 0

Nie rozumiem tego zdania. 0 nie jest niby „w formacie 0xFFFFF”? Co tutaj miałeś na myśli?


¹ Tworząc swój własny typ można je ustawić dowolnie. Sugeruję trzymać się takich samych, celem nie utrudniania sobie i innym życia.

0
Althorion napisał(a):

nie jest niby „w formacie 0xFFFFF? Co tutaj miałeś na myśli?

Człowiek sobie graficznie rysuje w głowie, i tyle - jest jak nadalszy od uogólnień jakie my normalnie mamy

0

@zkubinski: pisałem Ci, wejdź na poziom wyżej. Zobaczy czym u Ciebie jest "*wsk". Jak to kompilator widzi. Ty widzisz 3 literki. A to jest struktura.

2

zapamiętaj po prostu te poniższe równoważne konstrukcje i tyle. Jak chcesz to możesz pisać bardziej obrazowo i testować z nullptr, ale to będzie to samo.

if (wsk) { /* wskaźnik wskazuje prawdopodobnie na jakieś dane */}
if (wsk != nullptr) { /* j.w. */}
if (!wsk) { /* wskaźnik jest null/pusty/etc. Odczyt/zapis spod tego adresu powinien wywalić program */}
if (wsk == nullptr) { /* j.w. */ }

Gdyby nullptr był np. 0xFFFF to wtedy CPU musiałby zaprzęgnąć do pracy komparator i sprawdzać wynik porównania. Więcej roboty dla CPU niż testowanie zera, bo w każdym procesorze jest bramka OR, do której podłączone są wszystkie bity wybranego rejestru i ona pokazuje czy coś jest 0x0000 (false), czy różne od zera 0x0001 .. 0xFFFF (true). Z tej bramki OR wynik może być zapisany do specjalnego rejestru statusu, żeby potem instrukcje warunkowe mogły z tego korzystać. Jest to bardziej energoszczędne i szybsze niż użycie komparatora.

"Azarien" wspomniał, że standard nie wymaga żeby to było zerem. Jeżeli np. nullptr by miał wartość np. 0xFFFF to instrukcja if (wsk) przez kompilator powinna być dalej równoważna if (wsk != nullptr). W asemblerze będzie zrealizowane porównanie z 0xFFFF (komparator), ale my się tym nie musimy przejmować bo od tego jest kompilator C/C++, żeby takie fakty ukrywać przed nami. Kompilator powinien umieć zrzutować wskaźnik na typ 'bool' nieważne czy nullptr to same zera czy jakaś inna wartość.

1
zkubinski napisał(a):

Rozważmy pewien kawałek kodu

int *wsk = nullptr; //cleowo nie ustawiam na coś wskaźnika

if(wsk)
{
  cout << "wskaźnik NIE zawiera adresu" << endl;
}
else{
  cout << "wskaźnik zawiera adres" << endl;
}

Czytałem, że wskaźnik podawany w argumencie jest niejawnie konwertowany na typ BOOL.

Teraz celowo uczepię się fragmentu kodu if(wsk) przy tak postawionym warunku wynik mam następujący

wskaźnik NIE jest pusty

Czy ty w ogóle czytasz co piszesz? Wygląda mi to na kompletnie bezmyślne przeklejanie. W jaki sposób powyższy fragment miałby móc wydrukować to, co przedstawiłeś jako jego wyjście? Działasz na innym kodzie niż nam pokazujesz i na jego podstawie wyciągasz bzdurne wnioski.

0
kq napisał(a):

Czy ty w ogóle czytasz co piszesz? Wygląda mi to na kompletnie bezmyślne przeklejanie. W jaki sposób powyższy fragment miałby móc wydrukować to, co przedstawiłeś jako jego wyjście? Działasz na innym kodzie niż nam pokazujesz i na jego podstawie wyciągasz bzdurne wnioski.

@kq możesz dać focha i iść do kąta ale mnie się wydaje, że ty nie wiesz co piszesz

  1. WYNIKIEM obliczenia wyrażenia if(warunek) jest wartość logiczna TYPU -> BOOL
  2. WYNIKIEM obliczenia wyrażenia while(warunek) lub for( ;warunek; ) lub do ... while(warunek) - jest wartość logiczna TYPU -> BOOL

jeżeli nie widzisz analogii jednego z drugim, to ja nie mam już więcej pytań do ciebie - bo zakułeś, zaliczyłeś, zapomniałeś i ... dostałeś robotę i ... masz się całkiem dobrze

  1. mnie chodziło o rozpatrzenie JEDNEGO KONKRETNEGO przypadku (co przerosło wasze "wielkie" mózgownice) - konkretnie chodzi o przypadek if(wskaźnik) lub if(obiekt)

  2. NIE PYTAŁEM O JEDEN Z PONIŻSZYCH PRZYPADKÓW (mnie interesuje przypadek z pkt.3)

if(warunek < coś)
if(warunek > coś)
if(warunek != coś)
if(warunek == coś)
if(warunek <= coś)
if(warunek >= coś) - w tych przypadkach jest jasne co jest grane

więc jak wygląda przypadek z pkt 3 ? Przykłady niżej

int *wsk;

if(wsk) //porównanie warunku jest niejednoznaczne i miałem problem ze zrozumieniem jaki będzie wynik logiczny

w tym przypadku warunek zwróci false - ponieważ zmienna wsk NIE ZAWIERA ADERSU - konkretniej jest domyślnie traktowana jako NULL, ZERO - zwał jak zwał - może być tam śmieć ale kompilator traktuje to jako zmienną NIEZAINICJALIZOWANĄ

lub

int *wsk;
int zmienna;

wsk = &zmienna;

if(wsk) //porównanie warunku jest niejednoznaczne i miałem problem ze zrozumieniem jaki będzie wynik logiczny

w tym przypadku warunek zwróci true - ponieważ zmienna wsk WSKAZUJE NA ADRES

int i;

if(i) 

//tutaj otrzymam FALSE ponieważ zmienna jest NIEZAINICJALIZOWANA i kompilator traktuje to jakby tam było ZERO mimo iż formalnie tam nic nie ma, może być tam jakiś śmieć np 123123123

inny wariant

int i=5;

if(i) //tutaj otrzymam TRUE ponieważ zmienna jest już ZAINICJALIZOWANA a w zasadzie RÓŻNA OD ZERA

inaczej wygląda przypadek

int *wsk;

if(wsk == nullptr) 

//tutaj jasno widać CO jest elementem sprawdzenia DO CZEGOŚ i intuicyjnie jestem w stanie przewidzieć wynik
//czego nie można powiedzieć tym co napisałem powyżej

nie chce mi się pisać dalej ale tą sprawę już z kimś przedyskutowałem. Tak się zastanawiam, jeżeli wy to rozumiecie, to czemu nie wyjaśnicie w ten sposób ? Wniosek mam tylko taki, że owszem programujecie ale chyba nie do końca rozumiecie jak to działa. Jak chcesz sprawdzić czy to rozumiesz, to weź to komuś zrozumiale wytłumacz :)

0
zkubinski napisał(a):

mnie się wydaje, że ty nie wiesz co piszesz

Ano wydaje ci się. Jeszcze raz:

wskaźnik NIE jest pusty

Które z poniższych może wydrukować tego stringa?

cout << "wskaźnik NIE zawiera adresu" << endl;
cout << "wskaźnik zawiera adres" << endl;

Poprawna odpowiedź to "ojejku, ale wtopa, po raz kolejny wydałem błędną ocenę na podstawie błędnych danych!"

  1. WYNIKIEM obliczenia wyrażenia if(warunek) jest wartość logiczna TYPU -> BOOL
  2. WYNIKIEM obliczenia wyrażenia while(warunek) lub for( ;warunek; ) lub do ... while(warunek) - jest wartość logiczna TYPU -> BOOL

Tu znowu jest problem z niepotrzebnym użyciem języka polskiego. if/while/for itd w C++ to są statements, nie expressions, choć oba można tłumaczyć jako wyrażenia. W C++ nie mają one wartości.

jeżeli nie widzisz analogii jednego z drugim, to ja nie mam już więcej pytań do ciebie - bo zakułeś, zaliczyłeś, zapomniałeś i ... dostałeś robotę i ... masz się całkiem dobrze

Analogii czego z czym?

  1. mnie chodziło o rozpatrzenie JEDNEGO KONKRETNEGO przypadku (co przerosło wasze "wielkie" mózgownice) - konkretnie chodzi o przypadek if(wskaźnik) lub if(obiekt)

Przecież nie byłeś w stanie go rozpatrzyć, bo działałeś na innym kodzie?

  1. NIE PYTAŁEM O JEDEN Z PONIŻSZYCH PRZYPADKÓW (mnie interesuje przypadek z pkt.3)

if(warunek < coś)
if(warunek > coś)
if(warunek != coś)
if(warunek == coś)
if(warunek <= coś)
if(warunek >= coś) - w tych przypadkach jest jasne co jest grane

więc jak wygląda przypadek z pkt 3 ? Przykłady niżej

Poniższe to dokładnie to samo

if (warunek)
if (static_cast<bool>(warunek) == true)
if (static_cast<bool>(static_cast<bool>(warunek) == true) == true)
if (static_cast<bool>(static_cast<bool>(static_cast<bool>(warunek) == true) == true) == true)
// itd
int *wsk;

if(wsk) //porównanie warunku jest niejednoznaczne i miałem problem ze zrozumieniem jaki będzie wynik logiczny

Nie jest niejednoznaczne, tylko masz UB.

w tym przypadku warunek zwróci false - ponieważ zmienna wsk NIE ZAWIERA ADERSU - konkretniej jest domyślnie traktowana jako NULL, ZERO - zwał jak zwał - może być tam śmieć ale kompilator traktuje to jako zmienną NIEZAINICJALIZOWANĄ

Masz UB.

lub

int *wsk;
int zmienna;

wsk = &zmienna;

if(wsk) //porównanie warunku jest niejednoznaczne i miałem problem ze zrozumieniem jaki będzie wynik logiczny

Nie jest niejednoznaczne. Gdybyś jednak zdecydował się chwycić kiedyś za jakąś książkę/kurs, to pewnie by ci o tym tam wspomnieli.

w tym przypadku warunek zwróci true - ponieważ zmienna wsk WSKAZUJE NA ADRES

Konkretniej: ponieważ jest różna od nullptr

int i;

if(i) 

//tutaj otrzymam FALSE ponieważ zmienna jest NIEZAINICJALIZOWANA i kompilator traktuje to jakby tam było ZERO mimo iż formalnie tam nic nie ma, może być tam jakiś śmieć np 123123123

Bzdura. To jest UB.

inny wariant

int i=5;

if(i) //tutaj otrzymam TRUE ponieważ zmienna jest już ZAINICJALIZOWANA a w zasadzie RÓŻNA OD ZERA

Ponieważ jest różna od zera.

inaczej wygląda przypadek

int *wsk;

if(wsk == nullptr) 

//tutaj jasno widać CO jest elementem sprawdzenia DO CZEGOŚ i intuicyjnie jestem w stanie przewidzieć wynik
//czego nie można powiedzieć tym co napisałem powyżej

To niedobrze, że "jesteś w stanie przewidzieć wynik", bo to jest UB. Masz niezainicjalizowaną wartość.

nie chce mi się pisać dalej ale tą sprawę już z kimś przedyskutowałem. Tak się zastanawiam, jeżeli wy to rozumiecie, to czemu nie wyjaśnicie w ten sposób ? Wniosek mam tylko taki, że owszem programujecie ale chyba nie do końca rozumiecie jak to działa. Jak chcesz sprawdzić czy to rozumiesz, to weź to komuś zrozumiale wytłumacz :)

1

@zkubinski:

zkubinski napisał(a):

@kq możesz dać focha i iść do kąta ale mnie się wydaje, że ty nie wiesz co piszesz

  1. WYNIKIEM obliczenia wyrażenia if(warunek) jest wartość logiczna TYPU -> BOOL
  2. WYNIKIEM obliczenia wyrażenia while(warunek) lub for( ;warunek; ) lub do ... while(warunek) - jest wartość logiczna TYPU -> BOOL

jeżeli nie widzisz analogii jednego z drugim, to ja nie mam już więcej pytań do ciebie - bo zakułeś, zaliczyłeś, zapomniałeś i ... dostałeś robotę i ... masz się całkiem dobrze

  1. mnie chodziło o rozpatrzenie JEDNEGO KONKRETNEGO przypadku (co przerosło wasze "wielkie" mózgownice) - konkretnie chodzi o przypadek if(wskaźnik) lub if(obiekt)

Jak zrobiłeś krok ku abstrahowaniu części wspólnych, to zrób go konsekwentnie do końca
Dla jezyków C i C++ (a odmieniie od Javy i C#) if(obiekt) to jest if(warunek) a zasady wielokrotnie w tym wątku miałeś tłumaczone.

Nie ma potzreby zrozumienia siedmiu oddzielnych przypadków (i wyzywania całej wioski), ale wystarczy zrozumienie faktu bazowego.

Co więcej, ten kod (nad czym ja ubolewam i uważam za syf), jest w C++ legalny

#include <iostream>
class AlaMaKota {
};

int main()
{
    bool x = new AlaMaKota();

    std::cout << "Hello World!\n";
}

1 użytkowników online, w tym zalogowanych: 0, gości: 1