C++ vs Java melyikre koncentráljak ?
2017-02-02T14:05:07+01:00
2017-02-07T21:06:36+01:00
2022-07-21T16:01:49+02:00
  • "Ami miatt a C++ még sokáig velünk marad, és amiért annyit gyurmáznak vele, az a már meglévő kódbázis."

    Ezzel nem igazán értek egyet. Folyamatosan indulnak új komoly projektek C++-ban írva (Ettől függetlenül igaz az óriási kódbázis, de nem az tartja életben a nyelvet). Megvan a maga területe és a helye a mai modern nyelvek között és nem azért mert legacy, hanem mert a C++-is egy modern nyelv. Még írtad valamikor hogy 65 éves szabvány.. Nem a c++14-es szabvány 2014 decemberi. A c++17 pedig idén/jövőre érkezik.
    Mutasd a teljes hozzászólást!
  • Az, hogy az aktuális 3D játékmotorok miben vannak írva, nagyjából lényegtelen. Már csak azért is, mert általában nem abból használod őket amiben írva vannak, legalábbis nem feltétlenül, lásd Pl. Unity3D amit általában C# alól használnak és C++-ban van fejlesztve.

    Ami miatt a C++ még sokáig velünk marad, és amiért annyit gyurmáznak vele, az a már meglévő kódbázis. Senki nem fogja újraírni a MS-SQL-t, a Visual Studio-t, a Postgresql-t, stb.
    Mutasd a teljes hozzászólást!
  • Pont ezek a cégek (Sony, MS, Nintendo, EA, Ubisoft stb) határozzák meg, hogy merre menjen a szekér és az átlagpolgárok meg követik és ezek a cégek eddig még nem nagyon mentek el a C/C++ irányából a D, Rust, Go irányába, így ezek mennek is majd a süllyesztőbe, ahogy a Delphi, VisualBasic, F#, meg a többi.
    Mutasd a teljes hozzászólást!
  • Különösebb jelentősége nincs. Van pár cég és opensource-os emberke aki ezzel foglalkozik (a unity, unreal, stb. illetve a godot, urhosharp, stb. opensource-os projektek környékén) de az átlagpolgár még akkor sem kerül szembe a vulkánnal ha épp játékfejlesztő.
    Mutasd a teljes hozzászólást!
  • Ilyen szempontbol tokmindegy hogy mi az anyanyelv, amig lehet overhead nelkul elerni a fuggvenyeit. Goban es Rustban pl lehet. Meg biztos halom masikban is.
    Mutasd a teljes hozzászólást!
  • Van auto bind Lua-hoz is, meg van VulkanSharp is LC kedvéért, nem is erről van szó, hanem, hogy az anyanyelv az mi, amit az ipar használ.
    Mutasd a teljes hozzászólást!
  • íme egy nagyon jó fejlesztési szabály -- multiboolean, happy debugging :)

    bool expectedValue = true; bool[] booleans ={true,true,true,true}; byte[] bytes = {1,2,3,4}; GCHandle handler = GCHandle.Alloc(booleans, GCHandleType.Pinned); IntPtr ptr = handler.AddrOfPinnedObject(); Marshal.Copy(bytes, 0, ptr, 4); for (int i = 0; i < 4; i++) { Console.Write(booleans
    == expectedValue ? $"equals: {i}" : $"not equals: {i}"); Console.WriteLine($" -- {booleans
    }"); } handler.Free();


    Mutasd a teljes hozzászólást!
  • En rustban kodolok vulkant. DX-et is minden gond nelkul lehetne vezerelni vele.

    Amugy a vulkan api pedig olyan megoldasokkal operal, amivel a legegyszerubb interfacelni mas nyelvekbol. Sok eloreforditott nyelv pedig kozvetlen tudja linkelni es betolteni (attol fugg linkeled, vagy kezzel toldot be az instance es device fuggvenyeket) a vulkan apit. Szoval, az hogy a vulkan.h az speciel C, nem jelent semmit sem.

    Sot tovabbmegyek, ha az egyik gyarto rustban irna meg a driveret, ami fullosan tamogatja a specet, eszre sem venned. ;)
    Mutasd a teljes hozzászólást!
  • Jó, majd, ha a DirectX és Vulkan API Rust/Go-val jelenik meg, akkor visszatérünk erre.
    Mutasd a teljes hozzászólást!
  • Igen, a C++ trónkövetelői inkább a Rust, és a Go, de ők nem igazán szimpatikusak. De szerencsére arra amire nekem kell, bőven jó a C# is.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Meg, hogy mire használható ugye. Nem az a bitforgató hardverközeli nyelv, inkább gyors prototípus/üzleti logika fejlesztésére való script.
    Mutasd a teljes hozzászólást!
  • Mi az a swift? És mire jó?
    Mutasd a teljes hozzászólást!
  • A swift alapvetően nem rossz, ha eltekintünk attól hogy kik is csinálták...
    Mutasd a teljes hozzászólást!
  • tudnék olyan 48-ast mutatni, akire azonnal ráugranál :)
    másfelől egy 20 éves dagadt, hájas zsírtól csöpögő pöfögő fin_gszagú triplavalagú kiherélt vaddisznóra nem gerjednék rá.

    Ez is igaz. De a C++-on sajna picit sok volt a plasztikai műtét.
    Mutasd a teljes hozzászólást!
  • Akkor használd a swift-et, az csak 3 éves és kevesebb az esély a lábonlövésre.
    Mutasd a teljes hozzászólást!
  • tudnék olyan 48-ast mutatni, akire azonnal ráugranál :)
    másfelől egy 20 éves dagadt, hájas zsírtól csöpögő pöfögő fin_gszagú triplavalagú kiherélt vaddisznóra nem gerjednék rá.

    ezzel csak azt akarom mondani, hogy pusztán kor alapján dönteni bizony elég nagy amatőrségre vall.

    ami pedig a lábonlövést illeti
    teljesen mindegy milyen nyelven fejlesztesz.
    amíg nem értesz hozzá, addig ugyanolyan gány-xar és nagyrendszerben működésképtelen/bugos/leakes/lefagyós/memóriazabálós stb lesz c#-ban is.
    Mutasd a teljes hozzászólást!
  • Az, hogy a nyelv teli van lábonlövési lehetőségekkel, bizony a nyelv hibája. Különösen azért, mert ezek igazából nemigen tesznek hozzá a produktumhoz semmit, csak a visszafelé kompatibilitást szolgálják.
    Mutasd a teljes hozzászólást!
  • Egy csajnál sem mindegy, hogy 20 éves vagy 48, egy programnyelvnél sem az.

    Amik kikényszerítik, azok a különféle code quality ellenőrző eszközök (SonarQube és társai). Másrészt az, hogy a C#-ban tizedannyi lehetőség nincs arra hogy lábon lődd magad, mint C++-ban.
    Mutasd a teljes hozzászólást!
  • lol, makrok mint a nyelv egyik legnagyobb elonye
    Mutasd a teljes hozzászólást!
  • Persze, miért ne lehetne? Egyik legnagyobb előnye a nyelvnek a makró.

    LC
    Nem az a kérdés hogy te el tudod-e hagyni, hanem az hogy meg tudod-e akadályozni, hogy mások használják. Picit próbálj távolabb látni annál, hogy a saját kis gépemen egyedül hegesztem a saját kis kódomat magamnak, és az van amit én csinálok...

    Az nem a nyelv hibája, hogy sokan nem tudják megfelelően használni, olyan helyen kell dolgozni ahol nem pótkerékkel bicikliznek a kollégáid.
    Mutasd a teljes hozzászólást!
  • Miért C#-ban (lassan 20 éves aggastyán nyelvben) ki akadályoz meg abban bárkit, hogy tele dynamic-ozza, reflection-önözze, unsafe-zze, object-ezze és castolja, string SQL-ezze a kódot, meg úgy egyáltalán semmilyen fejlesztési szabályt se tartson be? Ameddig otthon pötyögtök a haverral a kis gépeden addig ez elmegy, de komoly projectnél másnap már nem kell bejönni dolgozni és a kóddal együtt repül az ember is ilyen egyszerű.
    Mutasd a teljes hozzászólást!
  • Miért számít az bajnak, hogy számtalan hasznos könyvtárat közvetlenül el lehet érni?

    Ahhoz, hogy te használni tudj egy könyvtárat nem kell feltétlenül kompatibilisnek maradni az ezer éves C++ szabvánnyal.

    Milyen régi szerkezeteket kéne elhagyni a nyelvből, amit te magad nem tudsz a kódodban elhagyni?

    Nem az a kérdés hogy te el tudod-e hagyni, hanem az hogy meg tudod-e akadályozni, hogy mások használják. Picit próbálj távolabb látni annál, hogy a saját kis gépemen egyedül hegesztem a saját kis kódomat magamnak, és az van amit én csinálok...
    Mutasd a teljes hozzászólást!
  • Pár makróval lehet tisztítani a kód kinézetét vajon ?
    Mutasd a teljes hozzászólást!
  • A C++-szal alapvetően az a baj, hogy régi és visszafelé kompatibilis mindennel.

    Miért számít az bajnak, hogy számtalan hasznos könyvtárat közvetlenül el lehet érni?

    az összes régi szerkezet elhagyásával

    Milyen régi szerkezeteket kéne elhagyni a nyelvből, amit te magad nem tudsz a kódodban elhagyni?
    Mutasd a teljes hozzászólást!
  • A C++-szal az a baj, hogy régi. Értsd, kb. a 60-as évek végén született K&R-féle C óta kb. minden benne maradt amit azóta kitaláltak. Így lett belőle egy hatalmas, sok területen nem annyira nagyon szép, és nagyjából végtelen mennyiségű lábonlövési lehetőséget tartalmazó nyelv.
    Mutasd a teljes hozzászólást!
  • Réginek nem mondanám, egész ütemesen fejlődik. Sokan hátránynak tekintik még a kevés az std által támogatott könyvtárakat, de ezt személy szerint előnynek tartom. A nyelv csak a CORE elemeket adja, nem mondja meg hogy mi az XML és hogyan parseoljuk..

    Igen az biztos, hogy túl nagy szabadságot hagy a nyelv. Ami akár a nyelv előnye is lehetne, de sajnos nagyon sokan lábon lövik magukat.

    "és csinálnának valami korszerű rendszerközeli nyelvet"
    Ez pont a C++. Azért mert lehet legacy, vagy akár C kódot is írni, amit lefordít a fordító, attól még nem kell úgy tenni.
    Mutasd a teljes hozzászólást!
  • A C++-szal alapvetően az a baj, hogy régi és visszafelé kompatibilis mindennel. Na most, ha van egy szép nagy megrendelőd, és egy szép nagy, több száz emberéves megrendelésed, de a megrendelődnek vannak kód minőségi elvárásai (ami azt jelenti, hogy ha bizonyos, Pl. régi szerkezeteket használsz, akkor fizetned kell) akkor azt egy C++ esetén nem annyira könnyű kikényszeríteni, és pláne ellenőrizni.

    A C++-szal az lenne a legjobb ami történhetne, hogy kidobnák a francba az egészet, és csinálnának valami korszerű rendszerközeli nyelvet, az összes régi szerkezet elhagyásával. Csak hát van egy rakás legacy kód ami miatt nem lehet kidobni a jó öreg C++-t és lecserélni mondjuk a D-re.
    Mutasd a teljes hozzászólást!
  • C++17 -ben már elég szépen lehet írni template kódokat is, amik könnyedén átláthatók. 60 sorban már meglehet oldani, hogy több streamre írj egyszerre.

    // Már osztálynál sem kell manuálisan megadni a típust sablonoknál, tehát létrehozni is könnyű Logger log{std::cout, std::ofstream{"log.txt"}}; log << "bla-bla\n"; log.writeln("Window ID: %d\tPos x: %d\tMouse Pos y: %d", e.motion.windowID, e.motion.x, e.motion.y); // A pár soros implementációka #include <iostream> #include <boost/format.hpp> template<int i = 0, typename T, typename Func, int j = std::tuple_size_v<T>> void tuple_foreach(T& tup, Func func) { if constexpr(i == j) { (void)func; return; } else { func(std::get<i>(tup)); return tuple_foreach<i + 1>(tup, func); } } template<typename... Streams> class Logger { public: template<typename... Args> explicit Logger(Args&&... args) : m_streams{std::forward<Args>(args)...} {} template<typename T> void write(const T& value) { tuple_foreach(m_streams, [&](auto& stream){stream << value;}); } template<typename Format, typename... Args> void write(const Format& format, const Args&... args) { tuple_foreach(m_streams, [&](auto& stream){stream << (boost::basic_format{format} % ... % args);}); } template<typename T> void writeln(const T& value) { tuple_foreach(m_streams, [&](auto& stream){stream << value << '\n';}); } template<typename Format, typename... Args> void writeln(const Format& format, const Args&... args) { tuple_foreach(m_streams, [&](auto& stream){stream << (boost::basic_format{format} % ... % args) << '\n';}); } private: std::tuple<Streams...> m_streams; }; template<typename... Args> Logger(Args&&...) -> Logger<Args...>; template<typename... Streams, typename T> Logger<Streams...>& operator<<(Logger<Streams...>& logger, const T& value) { logger.write(value); return logger; }
    Tehát egyre egyszerűbb lesz a C++ is, és kevesebb sorból, átláthatóbban meg lehet ugyan azt írni, anélkül, hogy nőne a futásidő.
    Mutasd a teljes hozzászólást!
  • yelv választása alapvetően inkább ne attól függjön, hogy melyiknek a szintaktikája szimpatikusabb

    Hát pedig én pont ezért dobtam anno a JAVA-t. (jó, volt más oka is, mint pl. mindenki javázni akart....)
    Mutasd a teljes hozzászólást!
abcd