A C lett az év nyelve - hamarosan lenyomhatja a Java-t is

A C lett az év nyelve - hamarosan lenyomhatja a Java-t is
2020-01-08T08:50:09+01:00
2020-02-17T09:32:29+01:00
2022-10-18T03:35:39+02:00
  • Ez most arra példa, hogy a C++ gyorsabb vagy lassabb mint a C? Mert a példád alapján mindkettő igaz. :)
    Mutasd a teljes hozzászólást!
  • Persze mert nem ugyanazt méred.. "sync_with_stdio"

    Using scanf() in C++ programs is faster than using cin?

    Így kb ugyanannak kell kijönnie..
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • A földönkívülieknek nem "matematikai okból" küldenek prím számokat, hanem fizikaiból :)
    Ugyanis a csillagok, bolygók keringése, mindenféle pulzálások olyan jelsorozatokat tudnak képezni, amiről komoly számítógép kapacitásokkal lehet csak eldönteni, hogy üzenet vagy zaj a jelsorozat.

    A prímszámok sorozata meg (fizikusok szerint) olyan jelsorozat, ami természetes módon nem jöhet létre.
    Mutasd a teljes hozzászólást!
  • Teljesen igaz! Eddig nem hozakodtam elő vele, mondhatni titkoltam, hogy a fogalom valóban szubjektív. De ha már ennyire megmártóztunk a filozófiában, akkor az valóban egy érdekes kérdés, hogy egy olyan, emberek lakta világban, ahol majdnem minden szubjektív, találhatunk-e mindenki számára egyformán nézhető, vagyis objektív dolgokat. Mostanában én a matematikában érzek ilyen erőt, hogy tud abszolút, objektív dolgokat felmutatni. A tökéletes test, tényleg szubjektív, de a prímszám már nem az. Nem véletlen, hogy a science-fiction művekben felmerült, hogy ezzel a fogalommal kellene indítani a földönkívüli civilizációkkal való kommunikációt. De ilyen a pi, az e, vagy a számomra legcsodálatosabb matematikai valami, az Euler-formula.

    Hogy hogyan lehet eljutni a C-nyelvtől az Euler-formuláig, azt külön érdekes lenne megvizsgálni. Remélem a hozzászólásam nem lesz off-topik, pedig valójában az, csak sajnálnám, ha háttérbe szorulna a hozzászólások között, mert szerintem nagyon érdekes témákat feszegettünk.
    Mutasd a teljes hozzászólást!
  • Milyen a tökéletes test?

    Hát az attól függ!

    Elsőre a gömböt választanám :)
    A legegyszerűbb, legtakarékosabb, a legtökéletesebb.

    Aztán esetleg a kockát, ha építő lennék, akkor mások a szempontjaim, a kockatest talán itt tökéletesebb, bár a téglatest nem vétletlenül az ősi építések alapja.
    Akkor lehet az a tökéletes.

    Persze ha matematikus vagyok, akkor megint mások a szempontjaim és lehet ezt választom:

    mese a kis Gömböcről...
    Mutasd a teljes hozzászólást!
  • Az a baj a "tökéletes" fogalommal, hogy elemi-primitív eseteken túl már szubjektív, vagyis ami az egyiknek tökéletes, az a másiknak egyáétalán nem biztos hogy az.

    Csak egy példa a fogalom furcsaságaira: "Nem az a tökéletes, amihez már nem tudsz hiozzátenni semmit, hanem az, amiből nem tudsz elvenni semmit."

    De hogy mekkora az az optimális komplexitás, na erre ezer választ fogsz kapni :)

    Tervezz egy "Tökéletes API"-t.... na majd meglátod s fogalom relativizmusát.
    Mutasd a teljes hozzászólást!
  • Most nem a matematikai fogalomról volt szó (a tökéletes számról), hanem egy sokkal általánosabb fogalomról, tulajdonságról, a tökéletességről. Ezt használtam a számok jellemzésére, nem azt mondtam, hogy az 1 tökéletes szám, hanem azt, hogy az 1 szám (mint minden más szám) tökéletes. Nem mint szám tökéletes, hanem mint bármi egyéb. Szerencsétlen módon ez a fogalmazás egybeesik egy már (teljesen helytelenül) használt matematikai fogalommal.
    Mutasd a teljes hozzászólást!
  • Csak egy példa: az 1 szám tökéletes, a 2 is. Miért? Mert nem lehet javítani rajta. A számok éppen azt tudják, amit tudniuk kell, ezért tökéletesek.

    Az 1 meg a 2 nem tökéletes számok, mert éppen nem tudják azt, amit a tökéletes számoknak tudniuk kell, ezért nem tökéletesek. Tökéletes számok – Wikipédia 
    De nekem végülis 987654321/123456789, pár tizedesig.
    Mutasd a teljes hozzászólást!
  • Szívesen kiszámolnám, mennyivel növeli a világ entrópiáját teljesen feleslegesen a C++-ban a "->", meg a "::", meg a "~". Mindig alapból utáltam az ilyen pazarló nyelveket, én már csak ilyen vagyok, lehet fikázni, de felesleges. Azt sem szeretem, ha a konstruktornak ugyanaz a neve, mint az osztálynak. Van egy Textin osztályom (egy olvasható szövegfile), miért legyen a konstruktora Textin, miért ne lehetne Open, ahogy az logikus? Ahogy az a Delphi-ben és a Free Pascal-ban lehetséges is!

    Attól is kész vagyok, hogy a main függvényben kell átvenni a program argumentumokat. Abban a nyelvben, amit én készítek, van egy argc() és egy arg() függvény, ezt bárhol, bármikor meghívhatom, visszaadja a kapott argumentumok számát, az az illető argumentumot. A "main" így néz ki:

    main {

    }

    És még a kapcsos zárójelek sem kötelezőek, csak ha több utasítás van a main-ben.

    Ehhez képest mennyit kell magyarázni a kezdőnek például a Java-ban a "public static void main(String[] args)" förmedvényt. Ez főleg akkor f..asza, ha a program nem is kap semmilyen argumentumot, akkor aztán feleslegesen írtuk oda hogy "String[] args" . Röhej!!!
    Mutasd a teljes hozzászólást!
  • Én nem azt mondtam, hogy tökéletes nem létezik! A következtetésed helytelen.

    Csak egy példa: az 1 szám tökéletes, a 2 is. Miért? Mert nem lehet javítani rajta. A számok éppen azt tudják, amit tudniuk kell, ezért tökéletesek. Egy másik példa: egy kátyús út nem tökéletes. Miért? mert nem tudja azt, amit tudnia kellene, vagyis, hogy simán lehessen rajta haladni.

    A megszámlálható végtelen tökéletes. Miért? Mert nem lehet jobb. Pontosan olyan, amilyennek lennie kell.

    Az emberi nyelv nem tökéletes. Miért? Mert amit mond, vagy ír az ember, az félreérthető. Példa: "Az úr ír." Levelet ír, vagy ír származású? Ki tudja? Majd a kontextusból kiderül. Csakhogy most kevés a kontextus is, mert én éppen így akartam.
    Mutasd a teljes hozzászólást!
  • Pedig de.

    Ha valaki mélyen, analitikusan, nagyon erősen a részletekre koncentrálva akar C++-ban dolgozni, az nagyon mélyen  ismerje az alapokat. A két gondolkodásmód közelít.
    Pont arról szólt az ASM,C,C++ vonal, hogy a C++ mély ismerete lehet egy cél, itt nem is kellene továbblépni C# vagy Java felé, a C++ önmagában elég nagy falat, mint végső cél, de pont ez a terület, ahol néha az ASM szintig is érdemes visszanézni.

    A C,C# vagy C,Java vonal egy másik cél. A C nem kihagyható, mert a figyelem, a precíz munka, az alapelvek (és a proci, memória működés) megismerésére innen indul.
    Aki nem érti az alloc/free lényehét, az a GC-vel megszivatja magát, az alapok hiánya megbosszulja magát. Aki nem tudja elképzelni, hogy egy class static vagy tagváltozója hogy helyezkedik el a memóriában, ha C-ben írná meg, ez hogy nézne ki, az is csak felületes tudással bír és bele fog futni előbb utóbb valami csapdába.
    Mutasd a teljes hozzászólást!
  • ASM --> C --> C++

    A fullos C++ tutira feleslegesen sok oda, ahol tényleg bitvadászkodni kéne assembly-vel. Ha meg csak egy részét tanulod meg, akkor nem tanultad meg.

    C ---> OOP (C# vagy Java)

    Itt meg az felesleges, hogy a C nagy része a memóriakezelésről szól. Ha kiveszed belőle, akkor marad a szintaxis, de csak ahhoz meg már felesleges külön megtanulni. És igen, olvastam a Perils of Java schools-t én is.
    Mutasd a teljes hozzászólást!
  • Szerintem ha valaki programozást tanul, akkor a tervezett céltől függően:

    ASM --> C --> C++

    vagy 

    C ---> OOP (C# vagy Java)

    Hiszek az alulról épitkező tudásban, de lefelé addig érdemes menni, amíg indokolt, felfelé meg a cél nyelv a legfontosabb döntési pont.
    Mutasd a teljes hozzászólást!
  • Kivéve a Bézik
    Mutasd a teljes hozzászólást!
  • A helyes programnyelv:

    ABC 

    Assembly, Basic, C.

    Más sorrend azért lehet, bár időrendben marad az abc, és ez örök lesz szerintem! (mármint a három nyelv marad örök)
    Mutasd a teljes hozzászólást!
  • az új szintaxissal tettem intbe egy double értéket, mert itt még ilyet is lehet.

    Erre mondom, hogy az hogy több szintaxissal lehet literal-okat kifejezni, az nem lesz többféle értékadás..
    Ez most mind különböző dolog?

    int n0 = 1; int n1 = 01; int n2 = 0x1; int n3 = 0b1;
    Ugyanígy ahol egy függvény visszatérési értékkel inicializálod.. Az most tényleg különbség, hogy lambda-ból jön az a függvény, egy nyelvbe beépített sizeof operator, vagy egy 'strlen' standard függvény?
    Mutasd a teljes hozzászólást!
  • Vagyis tökéletes nem létezik.
    Már csak a matematikai helyesség bizonyítás miatt is.
    Vagyis igenis nem bool, legföljebb fuzzy logic :)
    Mutasd a teljes hozzászólást!
  • Semmiben, valami vagy tökéletes, vagy nem az. Két értéke van, mint egy logikai változónak, true vagy false. Olyan nincs, hogy majdnem tökéletes, mert az nem tökéletes!
    Mutasd a teljes hozzászólást!
  • de az legyen tökéletes.

    Azt miben mérik?
    Mutasd a teljes hozzászólást!
  • A 14 arra volt példa, hogy már kappák is vannak. 15 kicsit túlzás, de meginiztem akkor is. 16-al sincs semmi probléma, miért ne lehetne egy size méret egy változóban? n17 teljesen korrekt, az új szintaxissal tettem intbe egy double értéket, mert itt még ilyet is lehet.
    Mutasd a teljes hozzászólást!
  • Hol van itt pointer? 
    Mutasd a teljes hozzászólást!
  • Szerinted mi van attól fontosabb, hogy egy memóriarekeszbe 1 kerül?
    Mutasd a teljes hozzászólást!
  • ugyanazt végtelenféleképpen lehet kifejezni

    Szerinted az itt felsoroltak ugyanazt eredményezik?

    Persze, valahol egy memóriarekeszbe 1 kerül... eddig azonos, és ezután?
    Mutasd a teljes hozzászólást!
  • Azért tegyük hozzá, hogy ezek nem mind ugyanazt jelentik..

    const-ness külön dolog, jelentése van, mint ahogy a constexpr-nek is..
    Ugyanúgy nem azonos az int, az int&-al, vagy egy r-value int-el.

    Tehát azért mert a 'cout' ugyanazt írja ki eredményül, attól még nem lesz ugyanaz a kód jelentése..

    n14, n15, n16, n17? Ne már :)

    Bármelyik nyelvben tudok ilyet, vagy hogy függvény visszatérési értékből inicializálom, stb..

    int n0 = 0; int n1 = 1; int n2 = 2;
    Mutasd a teljes hozzászólást!
  • Ez végre egy kedvemre való hozzászólás .
    Mutasd a teljes hozzászólást!
  • Kihagytad ezeket:

    const int&&& n = 1; const int&&&& n = 1; és így tovább... Szerény véleményem szerint nem előny, ha ugyanazt végtelenféleképpen lehet kifejezni, legyen egyfajta módszer, de az legyen tökéletes.
    Mutasd a teljes hozzászólást!
  • mivel c# is tud unsafe-et, ott is lehet pointerrel bohóckodni

    plusz a kettő tökugyanaz
    int i = 1;
    Int32 i = 1;

    szóval bármi, amit találok szorozva kettővel :) :)
    Mutasd a teljes hozzászólást!
  • A C# még mindig kispályás ezekhez képest:

    const int n6 = 1; const int& n7 = 1; const int&& n8 = 1; int&& n9 = 1; auto n10 = 1; auto&& n11 = 1; decltype(n11) n12 = 1; constexpr int n13 = 1; const int n14 = []() { return 1; }(); int n15 = std::move(n14); int n16 = sizeof(char); int n17 = 1.000'000'000; template<typename T> T n18 = T(1); int n19 = n18<int>; inline int n20 = int{ 321 };
    Eddig 20 féleképpen iniztem egy intet. Most te jössz. 
    Mutasd a teljes hozzászólást!
  • Gyorsan belenéztem egy mikrokontrollerre írt C++ kódomba..
    Néhány hasznos feature C++-ból:

    //! Use fold expressions to set the given indexed bits in compile time template <class ...Args> constexpr RegisterType bits(Args&&... args) { return ((1<<args) | ...); }

    Erre épülve set,clear, satöbbi bit művelet használata nagyon egyszerűen, tetszőleges számú bit-et állítva..

    ---
    CRTP hogy legyen egy kis struktúra

    template <class TimerImpl> class Timer { ... void start() { return static_cast<TimerImpl&>(*this).start_impl(); }
    ---
    constexpr / swtich case..

    // Use hash to easily select proper action switch (cmd->getCommand().hash()) { case XXX::hash('G', 0): ...
    Szóval nem rossz dolgok, 8 bites mikroprocesszorra..
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd