Void, const, static - Pontosan mikor használjuk ezeket c++ban?

Címkék
Void, const, static - Pontosan mikor használjuk ezeket c++ban?
2021-08-22T13:50:50+02:00
2021-08-27T17:08:15+02:00
2022-10-17T08:20:32+02:00
  • Más nyelven nem is tudnád fejlesztésként eladni az alábbit:
    - int a=10; + int a(10);
    Aztán kicsit késöbb:
    - int a(10); + int a{10};
    Mutasd a teljes hozzászólást!
  • A bébimotort is könnyebb megtanulni vezetni mint sportmotort, de az elõbbivel nemigen fogsz motorversenyt nyerni.
    Mutasd a teljes hozzászólást!
  • Úgy tűnik, ez az a nyelv, ahol egyszerű kérdésre bonyolult válasz jár.
    Mutasd a teljes hozzászólást!
  • Szerintem ugyanezt mondjuk, hogy az indentálásra egyébként is kell (formális vagy informális nekem nyolc) szabály attól függetlenül, hogy mi a bracing style - csak adtam rá példákat is.
    Mutasd a teljes hozzászólást!
  • Bármilyen valamire való C++ projekt tartalmaz .clang-format fájlt, bármilyen valamire való C++ programozó lokálisan saját .clang-formatot használ, egyszóval identálási probléma elő se fordulhat. Úgyszintén a kódot minden warning engedélyezésével fordítja és static analyzert is használ.

    "warning: range-based for loop has empty body [-Wempty-body] for (auto& e : elements);"
    Mutasd a teljes hozzászólást!
  • De mutatok egy jobbat - ahogy a te példádnál egy plusz billentyű leütés kellett a "galibához" itt is csak egy kell ha az angol bill kiosztást nézzük:

    if (kulakva) { for (auto &e : elements); { for (...) { // ... } } }
    De ezek szerintem a #define true (rand() < 10) kategóriás dolgok azért egy kódbázisban tényleg
    Mutasd a teljes hozzászólást!
  • if (kulakva) { for (auto &e : elements) jo_rovid_muvelet(); { for (...) { // ... } } }
    ^^De azért ez is jó, amikor a kódban ilyet látsz

    Azt mondod a zárójelezés tart egyedül vissza, hogy összevissza indentálj / kódolj? Akkor ez mi?

    if(kulakva) { for (auto &e : elements) { jó hosszú sor... } for (...) { // Jó sok sor van itt } }
    Ilyenkor is keresgetheted a zárójeleket, de se ezeket, se a példádat rendes ember nem írja le, meg ezek ellen vannak ám más stilisztikai szabályok jó esetben... Ilyet is láttam még pár éve egyébként, valszeg egy véletlen backspace okozta, mert az indentáció is ott volt a sor végén. De khm. a gány kódokról, meg ahol semmi kontroll nincs azért beszélgetni lehet napestig sajnos.

    Szóval "direkt csúnyaságokat" én is tudok írni ebben a stílusban is

    De hogy pontosabb legyen az indentáció fontosságára vonatkozó hasonlat:

    if(kulakva) { for (auto &e : elements) { // j // ó // // s // o // k // // k // ó // d } // r // o // s // s // z // u // l for (...) { // b // e // h // ú // z // v // a } }

    Ha nem mész le a legaljáig és számolod meg a bezáró kapcsosokat ott akkor ez is ugyanúgy galibát okoz, mert simán beágyazott ciklusnak látod (és mondjuk annak kéne lennie és így elmész a bug mellett). Azért ez is az a kategória ahol a space-eket, tabokat és pixeleket számolod, de normális review mellett ilyenek nem szabad, hogy kialakuljanak.
    Mutasd a teljes hozzászólást!
  • Ez valóban személyes preferencia. Adott kódbázisban nyilvánvalóan az adott style guide szerint kell commitolni.

    Személy szerint a külön sor a nyitó-brace-t tartom olvashatóbbnak.
    Ha már konkrét példákat írtunk:

    if(kulakva) { for (auto &e : elements) { jó hosszú sor... } for (...) { // hibás behúzás galibát okozhat és lehet jó sokat szívni miatta.. } }
    Mutasd a teljes hozzászólást!
  • TL;DR: Szerintem a két stílus hívei azon vitatkoznak, hogy a záró brace a nyitó brace-el legyen logikai párban, vagy az if-for-while-class stb. kulcsszóval. Számomra a záró brace az ifet zárja le közvetlenül amikor így nézem, nem gondolkozok rajta, hogy "lezár egy nyitó brace-t, az mihez is tartozik? egy ifhez, oké" - mert ezt felesleges időpocsékolésnak érzem.

    Más meg valószínűleg máshogy gondolkozik.
    Mutasd a teljes hozzászólást!
  • Ráadásul kimondottan rontja az olvashatóságot, mert több brace után rohadt nehéz összenézni hogy ki kivel van.

    Miért lenne nehéz összenézni? Kimondottan javítja az olvashatóságot az egyik vélemény szerint és kimondottan rontja a másik szerint és fordítva - ebből vannak a hitviták :D 

    De amúgy a záró brace-t mentálisan nem a nyitóval nézed össze, hanem azzal ami miatt bevezetted a blokk-utasítást.

    if(kulakva) { for(auto &e : elements) { // ... } }
    ^^Ennél mondjuk egyből látod, hogy a külső záró brace az ifet zárja le, a belső meg egy for ciklust.

    if (kulakva) { for (auto &e : elements) { // ... } }
    ^^Ha így van kiírva, akkor van egy felesleges "nézz egy sorral feljebb" mire kideríted fejben, hogy az adott záró brace mit is zár le. Ez miatt rontja az olvashatóságot. De ahogy mondtam, ezek ilyen hitviták és vallásháborúk, felesleges nagyon mélyen belemenni, csak gondoltam leírom mi zajlik mentális modell szerűen a fejemben ha a kódot olvasom, mert hátha jobban megérthető miért preferálja valaki az egyiket és a másikat

    Hogyan van egyébként is a szintaxisfa valószínűleg? Nem tudom, de én tuti így definiálnám, hogy ezen három dolog egy szintre esik - tehát az "if" része:

    if <condition> <body>
    Tehát mint if(need_action) do_action(); ugyebár. Ezt is egy sorba írnád jó esetben le, logikai szint ugrás lefele csak a body tovább lebontását követően van - itt a rövidebb példában konkrétan egy function_call-ra mondjuk vagy feljebb a blokk-utasításre.  Már ezért is eleve ott kezdődik egy sorban. Az előbbi a "praktikus" érvek közül való, az utóbbi az ilyen "OCD-d van ezért rendet akarsz és úgy akarod írni a programot, hogy a logikai szerkezetét jobban kifejezze" érvek közül és van egy tonnányi másik...

    Igazából azt tartom jónak, ha az embernek kialakul a saját stílusát tekintve mi is a megfelelőbb neki és el is tudod mondani miért és melyiket preferálod. Azt is jónak tartom, ha nem "kinézet" alapján és "szépészeti" hanem praktikus szempontok alapján alakítod a véleményed és természetesen nem csak csordaösztönök alapján, vagy "ez a kóder is azt használja" - hanem ha ez is vitt rá, de megérted a filozófiáját, logikáját mi is zajlik. Ezek mellett meg persze tudj dolgozni az összes ilyen hitvita szerűen eldöntött közegben normálisan anélkül, hogy folyamatosan szidnád a kódot - vagy ha szidod is ez ne hátráltasson a munkában
    Mutasd a teljes hozzászólást!
  • Viszont a C++11-el a C++ jo iranyt vett es komolyan javult a hasznalhatosaga kevesebb szivas mellett.

    Tudom és egyetértek, hogy a C++11 marha jó irányt vett. Igazából a C++03-at nem gyűlöltem, de igazából a C++ nyelvet a 11-es óta "kedvelem" úgy igazából.

    Ha legacy es/vagy C kod akkor tuti static-kal talalkozik, ha uj kod akkor valoszinu inline namespace.

    Ahogy jeleztem ez tökre nincs így. Nem csak az LLVM-hez kapcsolódó új kódokban fognak static-ot írni hanem komoly érvek szólnak mellette és ellene is. Én magam is írok tök nem-legacy új kódot és mindegyikben így fogom írni kivéve ahol valami megkezdett kódban a másik stílus már alapvetően jelen van, mert ugyebár az alapszabály hogy a létező style guide-hoz alkalmazkodsz a projekten. Van közelemben C++17 kód például, ami ground-up projekt és ilyen a stílusa már előttem is.

    Egyébként azt is leírtam, hogy a C++11 óta igazából jóval több új C++ kód készül ezzel a stílussal, mert mivel a C++11 "jó irányt vett és komolyan javult a használhatósága" ezt azonnal ki is szedték a deprecated státuszból. Herb bácsi meg amikhez hozzáfér ott erőlteti még a dolgot aztán vagy úgy használják ahogy ő szeretné, vagy nem. De ilyen szemmel nézve sokkal jellemzőbb, hogy C++03 kódokban nem fogsz ilyen static használatot annyit látni, mint C++11 utáni kódokban.

    AmugyA C++20 es 23 ujabb lepes es lenyegeben a modulok az alabbi beszelgetest is ertelmetlenne teszik

    Hát azért nem teszik lényegtelenné a linkage kérdéskört semelyik formájában... A fordítási sebesség a modulok miatt amúgy is jobb lesz emiatt lehet hogy nem akkora majd a dolog "értéke", de azért biztos vagyok benne, hogy marad még használati eset.

    viszont az szerintem meg evek mig projektekben is visszakoszon. 

    Hát igen. Átlagosan lehet egy 2-3 éves csússzással számolni a szabványban lévő év száma és a jelenlegi között, hogy biztonságosnak érezd a használatát komoly projekten. Az is beleszól a dologba, ha multiplatform dologról van szó és több fordítót akarsz támogatni - bár ez max egy évet ha beleszól - és a komoly probléma inkább az szokott lenni, hogy mondjuk valami nagy SDK vagy gigakódbázis nem fordul, vagy csak hibázik kivéve valami egyetlen adott ósdi fordítóval, fordítva mert általában már a régi szabvánnyal se volt szabványos, csak "ment"...
    Mutasd a teljes hozzászólást!
  • Ezt a brace-t odaírjuk az if vagy a ciklus mögé, a zárót pedig az utolsó sor után dolgot soha nem értettem. Mi ebben a logika? Ráadásul kimondottan rontja az olvashatóságot, mert több brace után rohadt nehéz összenézni hogy ki kivel van.
    Mutasd a teljes hozzászólást!
  • Igen
    Editors:• Herb Sutter

    Ott is van akit mondtam, hogy tolja ezt a dolgot és már a 03-as standardban deprekálni is akarta :D 

    egyértelműen az unnamed namespace-t preferálom (megvannak annak is az előnyei). Kód olvashatóságára nagyon sokat adok, számomra még nem okozott gondott ez a feature ezen a területen.

    Igen megvannak az előnyei. Például egységes módon tudod a class-oknál és a függvényeknél/változóknál csinálni ezt a dolgot a névtelen névtérrel és egyesek úgy gondolják ez azért is "egyszerűbb", mert a static túl sok mindent jelent a kód környezetétől függően tehát érthetőbb ez így.

    Aki meg nem preferálja, az olyanokat mond, mint amit korábban én is leírtam, meg hogy egy függvény linkage tulajdonsága nem a közegének, hanem a függvénynek az attribútuma logikailag ezért zavaró, ha nem ahhoz írod oda az ezt a jelentést kifejező dolgot stb. stb.

    Sok olyan embert is ismerek, aki a brace-eket külön sorba írja, pedig logikailag egy blokk-utasítás jelentése van a dolognak és ha módom van rá én például mindig egy sorba is írom a feltétellel, ciklussal stb. - mégis mind én mind az ilyen illető figyelhet és adhat a kód olvashatóságára, csak más részletkérdésekben más a stílusa. Ezeknél lehet felhasználói teszteléses jellegű vizsgálatokat is csinálni némely esetben - némely esetben meg nem igazán lehet. Továbbá ha tesztelni próbálsz ilyen UX-szerűen az is félrevihet, mert ha programozókat választasz alanynak, akkor az se azt mutatja meg hogy mi optimális, hiszen belejátszik, hogy ki mihez van hozzászokva (például itt nem sokkal lejjebb találtál embert, aki nem is ismerte a névtelen névteret, de a static-ot például igen - tök függetlenül melyik jobb a teszten kihozná, hogy a static-ot érti meg hamarább egy kódból) - ha meg nem programozót választasz teszt alanynak arra kell figyelni, hogy könnyen lehet, hogy csak beginner-barát tulajdonságokat fogsz mérni és nem szakmabelire nézve hatékonyságot... 

    Az is belejátszik a dolgokba, hogy ki mennyire OCD-style vagy poroszos. Az még olyan dolgokba is belejátszik, hogy auto-t írsz, vagy az illető kiírja-e a pontos típust. Van aki meg csak akkor írja ki, ha ezzel információt akar átadni. Szerintem ahhoz görcsösen ragaszkodni, hogy minden "egységes" legyen például én nálam nem érv. Főleg, hogy tudott interop okokból sose lesz egységes, sőt így kétféleképpen lehet "kvázi ugyanazt" elérni.


    A chromium style guide amúgy annyiből meglepő, hogy tudok róla, hogy nagy cégeken belül is vannak viták erről, hogy a static-ot ki kell-e rekeszteni vagy az LLVM-es stílus a jobb és a google alap style guide-ja konkrétan jelenleg úgy fogalmaz, hogy mind a kettőt elfogadja (már ha egyik stílust se használod header fájlban). A chromiumnak a chrome miatt vannak azért google-s kapcsolódásai erősen, így érdekes, hogy itt viszont letették a voksot az egyik mellett ennyire.
    Mutasd a teljes hozzászólást!
  • C-ben lattam es hasznaltam. Ott egyertelmuen van letjogosultsaga ha valamit el akarsz zarni. Viszont a C++11-el a C++ jo iranyt vett es komolyan javult a hasznalhatosaga kevesebb szivas mellett. Viszont **G**-al ertek egyet hogy ez egy egysegesebb stilust kovetel meg legalabbis informalisan. Modernebb nyelvi elemek hasznalata mellett. AmugyA C++20 es 23 ujabb lepes es lenyegeben a modulok az alabbi beszelgetest is ertelmetlenne teszik, viszont az erintem meg evek meg projektekben is visszakoszon. 
    C++-nal problema a visszafele kompatibilitas -mashol meg elony. Egy kezdo C++-nal mindent akar, nehez megertenie hogy mukodik a nyelv es sokan ezert is szidjak. Ugyis a projekt es a lead dev, team dont. Ha legacy es/vagy C kod akkor tuti static-kal talalkozik, ha uj kod akkor valoszinu inline namespace.
    Amugy maga Stroustrup jelentette ki hogy ne akarja senki az egesz nyelvet tudni, hasznalja azt amit kell :D
    Mutasd a teljes hozzászólást!
  • Gondolom olyat is találni ami meg javasolja

    Igen :)

    C++ Core Guidelines
    Chromium C++ style guide - Unnamed namespaces

    Nyilvánvalóan ismerni kell a static kulcsszó ilyen használatát is, viszont ahogy írtam én egyértelműen az unnamed namespace-t preferálom (megvannak annak is az előnyei).

    Kód olvashatóságára nagyon sokat adok, számomra még nem okozott gondott ez a feature ezen a területen.
    Mutasd a teljes hozzászólást!
  • Használnom szerencsére soha nem kellett és kódban sem találkoztam vele

    Igazából nagyobb projekten valamelyik emlegetett megoldással jó esetben találkozol és jó esetben írsz is ilyet. Egy nagyon jó példa, hogy helyettesítheted ilyen internal linkelésű dolgokkal némely esetben a class-od privát metódusait!

    Miért jobb ez mint egy private metódus? Gondolj bele: A private-ot deklarálnod kell a header fájlban, amely header fájlra ezermillió-csillió másik fordítási egység hivatkozik. Privát, tehát elvileg csak te hívogatod egyébként is, de ennek ellenére a függőségeket is szépen build-elheted a következő make-nél, csak mert egy osztályra nézve helyi és privát függvény paraméter listáját átírtad.

    Mi történik ha ez egy statikus, vagy más módon belső linkage-el ellátott függvény? Azt simán deklarálod a .cpp fájlodban (abban ami a class header-jéhez tartozik). A header-en semmit az ég világon nem módosítas és semmi ami attól függ nem fog újra lefordulni - tehát így gyakorlatilag egyetlen .cpp fájlt kell újra build-elned csupán.

    Ez ilyen apróságnak tűnik, de attól függően, hogy mennyire nagy a projekt maga, vagy akár ha nem is nagy, de mennyire vannak benne egyébként fordítási idő igényes trükközések (template-makró mágiák, header-only third party libek, vagy akármi) közepes projektnél is jó tud lenni ez a dolog.

    Az más kérdés, hogy ha unit tesztelni akarsz, akkor meg néha nagyon is jó ötlet privát helyett protected metódusokat csinálni amennyiben teszt alá kéne venned őket - mondjuk a bonyolultságuk okán. Olyankor csinálhatsz leszármazott osztályt és abban ugyebár legalább eléred és kiajánlod a protected-et csak a tesztnek (Connector és TestConnector osztályok például). Ha van annyira trükkös, vagy nagy a privát függvény kódja, hogy megérje teszt alá húzni azt önmagában is, akkor persze metódusra leszel kárhoztatva.

    Ezek is - mint sok más említett dolog - azért általában pro-kontra elvek mentén dőlnek el (jobb esetben - más esetben vallási fanatizmus mentén).
    Mutasd a teljes hozzászólást!
  • Hát ebben nem értünk egyet. Az LLVM coding standard érvei számomra így első blikkre és a saját kód-olvasási stílusomat részletesebben megfigyelve is sokkal meggyőzőbbek voltak mindig is:

    The problem with anonymous namespaces is that they naturally want to encourage indentation of their body, and they reduce locality of reference: if you see a random function definition in a C++ file, it is easy to see if it is marked static, but seeing if it is in an anonymous namespace requires scanning a big chunk of the file.

    Because of this, we have a simple guideline: make anonymous namespaces as small as possible, and only use them for class declarations.

    Sajnos amint elkezdtek átállni erre a static-ról, a legtöbben nem akarják függvényenként és típusonként minimális namespace-be csomagolni azokat, hanem a fájlon belül szép nagy blokkokat csinálnak (láttam(tm)). Ez marhára zavaró, mert egy sima vim-es keresés, jump to definition egy IDE-ben, vagy akármi amivel odamész brutálisan elrejti előled, hogy igazából ez egy fájl-lokális függvény.

    A másik dolog, hogy a static ilyen használatát jó esetben a C-interop miatt nem fogják soha az életbe kivenni. A C++03 időkben a Herb Sutter nyomására ha jól tudom hivatalosan is deprecated-ezték ha névtelen névtér helyett használtad, de hála Istennek a C++11 óta leszedték ezt a deprecated jelzőt is már, szóval szépen vissza is vonták és már nem deprecated. Lényeg a lényeg: mindenképp úgyis ismerni kell ezt a fajta értelmezését a static-nak, mert új kódok is fognak folyamatosan készülni ezzel - ha másért nem hát azért mert mondjuk beraksz egy C-vel is együttműködő minilibet és akarod érteni mi történik benne. Nem fog sose eltűnni.

    Külön bonyolítja még a helyzetet, hogy egy jó ideig szerintem nem inline namespace-ként viselkedett a névtelen névtér és jó ideig az internal linkelés se volt ott feltétel szóval még a szimbólumtáblát is feleslegesen szemetelted. Az is okoz még egy kis különbséget, hogy beljebb fogod indentálni azt, ami fájl-lokális és így egybe fog olvadni a nevesített névtereiddel. A static-nál nem csak a kulcsszó ami jellemzően jobban kiszúrja a szemed, de könnyen kiteszed a névteredből felülre fájl-lokális helpernek ami vizuálisan már az indentálásból látszik (ha valaki használ minimapot talán már azon is látszik - nekem nem annyira szokásom, hacsak nem default ahol ülök).

    Igazából azt is megértem, aki mindenre névtelen névteret akar használni, csak arra akarok rávilágítani, hogy azért ez egy pró-kontra, gittrágós kérdés, nem ennyire "előre eldöntött". Az LLVM guideline ahogy látod például nem is javasolja pedig 2021-ben frissített guideline ez. Gondolom olyat is találni ami meg javasolja, meg olyat is ami szerint meg tök mindegy, csak igényes legyen a kód és könnyen karbantartható.
    Mutasd a teljes hozzászólást!
  • Azért nagy szó a C++11, mert a legtöbb rendszert úgy fejlesztik, hogy ami már működik, ahhoz nem szabad nyúlni. Pedig szerintem újragondolni/frissíteni/átírni kellene fejlesztés közben, különben elmegy a project felett az idő, nemcsak a nyelv és a fordító.
    Mutasd a teljes hozzászólást!
  • A modulok szépek és jók, csak a baj velük, hogy C++20 -tól vannak, plusz a fordítók nagy része csak partial supportot ad (GCC 11, Clang 8,  bár ha jól tudom az MSVC egész jól áll), ezen felül az STL nem legjobb barátja még. **G** -nek igaza van a névtelen névterek nagyon sokat segítenek a szervezésben, ezenfelül fontos a program logikailag megfelelő felépítése. Amúgy ha egy projekt C++17 -et használ az nagy szó, C++11 a többség, szerintem, de mint mondtam nem mostanában volt  a nyelvhez közöm, pedig szerettem.

    A modulok majd a header fájlok eltűnését elősegíti, de szerintem a tisztán moduklokat alkalmazó projektek még messze.
    Mutasd a teljes hozzászólást!
  • Források közötti láthatóságot a module  oldja meg.  A const meg egy külön fejezet főleg a pointereknél el lehet bonyolítani.
    Mutasd a teljes hozzászólást!
  • Ahogy **G** írta nem nagyon ésszerű mostanában. Ha jól tudom igazából C-s örökség. Használnom szerencsére soha nem kellett és kódban sem találkoztam vele, csak tudom, hogy az elvi lehetősége megvan.
    Mutasd a teljes hozzászólást!
  • Ebben igazad van: ha nem a forrásfájlok közötti, hanem az osztályok (class) közötti láthatóságról van szó, akkor az általad említett kulcsszavak relevánsak.
    Mutasd a teljes hozzászólást!
  • Ezzel még nem találkoztam - mondjuk az is igaz, hogy úgy 20 éve C++-oztam komolyabban  utoljára.
    Mutasd a teljes hozzászólást!
  • Erre a célra célszerűbb az unnamed namespace-t használni!

    Legacy okok miatt működik, friss kódban nem engedném a használatát a 'static' kulcsszónak ebben a kontextusban.
    Mutasd a teljes hozzászólást!
  • Osztályon belül igen, ahogy írtad. De a static kulcsszó használt még máshol is. pl ha egy fordítási egységben egy függvénynek static kulcsszót megadod akkor az csak abban lesz elérhető nagyvonalakban.

    több részlet innen:

    Storage class specifiers - cppreference.com
    Mutasd a teljes hozzászólást!
  • Ilyenkor felmerül a kérdés: itt most definiálok egy függvényt vagy változót, akarom-e, hogy másik forrásfájlból is elérhető legyen?

    Az szerintem a láthatóság (private, public, internal, friend, stb).
    Mutasd a teljes hozzászólást!
  • const = konstans. Nem akarod hogy változtatni lehessen az értékét.

    static - ez lehet függvénynél vagy osztálynál. Az osztálynál az egyszerûbb: azt jelenti, hogy az adott változó az osztály minden példányára nézve közöss. Azaz csinálsz egy osztály benne egy statikus int változóval, majd csinálsz egy A objektumot az osztály példányosításával, és egy B objektumot is. Ha A objektumban változtatod a statikus változód tartalmát, akkor az B-ben is változni fog.

    Függvényben azt jelenti, hogy az adott változó a függvényen belül lesz statikus.
    Pl. void alma(void) { static int a = 1; printf("%d\n",a++); }

    Ha kétszer hívod meg egymás után, akkor azt írja ki hogy 1, 2 ...

    A void azt jelenti, hogy a függvény nem kap / nem fogad értéket. A void* pedig olyan pointert jelent, ami bármilyen típusra mutathat.
    Mutasd a teljes hozzászólást!
  • Értem.Nagyon szépen köszönöm a válaszod,így nagyon érthető volt minden!
    Mutasd a teljes hozzászólást!
  • Meta: Ez a topik hamarosan átkerül a Társalgóba, ha még nem történt meg.
    On:
    > Ha egy függvényt szeretnék megírni, akkor mitől függ hogy éppen voidot írok a függvény elé vagy éppen egy típusváltozót?

    Attól, hogy akarsz-e értéket visszaadni. Ha igen, akkor annak az értéknek a típusát írd ide.

    > A const használatánál szintén bajban vagyok egy kicsit,nem tudom hogy mikor illetve miért kell használni.

    Kelleni nem kell, de jelzed vele a fordítónak illetve az emberi olvasónak, hogy azt az értéket nem szándékozol megváltoztatni, illetve hogy a fordító is figyelmeztessen, ha mégis megpróbálnád (mondjuk tévedésből), pl.:

    const char Hello[] = "Hello, vilag"; Hello[0]= 'X'; /* ez itt hiba */

    > A staticnál úgyszintén ez a problémám.

    Később majd találkozol olyan programokkal, ami több forrásfájlból állnak össze. Ilyenkor felmerül a kérdés: itt most definiálok egy függvényt vagy változót, akarom-e, hogy másik forrásfájlból is elérhető legyen?

    Az alapértelmezés az "igen", az ellenkezőjét a 'static' kulcsszóval lehet jelezni.
    Mutasd a teljes hozzászólást!
  • Már egy ideje elkezdtem c++ al foglalkozni,azonban ezek még mindig nem teljesen világosak.Ha egy függvényt szerertnék megírni akkor mitől függ hogy éppen voidot írok a függvény elé vagy éppen egy típusváltozót? A const használatánál szintén bajban vagyok egy kicsit,nem tudom hogy mikor illetve miért kell használni.A staticnál úgyszintén ez a problémám.
    Mutasd a teljes hozzászólást!
Címkék
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd