111–120 of 334 posts
However, I'm a my own kind of weird. I cannot watch a documentary that's made out of people saying short sentences. I get that it's made to 'have them tell the story', but I need a narrator to tell me what to think because I get distracted.
Still lots of love to the creators, of course.
Earlier quoted context omitted.
If this is a rhetorical question I genuinely don't know what's the implied answer. Why would AI specifically make C++ grow?
A few reasons: 1. Header files make C++ verbose. Header files are well within LLM's ability 2. LLMs can handle setting up cmake for you 3. C++ is very well documented relative to (most) newer languages 4. LLMs can port modern features like websockets and build API wrappers easily, reducing the disadvantage against web (since most documentation is for JS/python/go) Coding languages have been developing for speed of (m…
My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.
Try Java
isn't kotlin supposed to be the future for JVM?
Earlier quoted context omitted.
C+ Standard Template Library is the best designed part of C++ library. It was designed by Alexander Stepanov. https://en.wikipedia.org/wiki/Alexander_Stepanov
So, a few things (aside from the whole nomenclature argument already in another reply) 1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea. 2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++)…
Case in point: list::sort. You don't want to try running quicksort on a linked list. Or remove_if: great we've abstracted the difficult task of removing things without erasing them, except we can't do it on maps. (C++20 seems to add an erase_if, apparently admitting that the two-step remove/erase is silly).
Then there's the fact that C++ iterators are basically pointers into the data structure, where for vectors (your common case) you'd do much better with index/container pairs, both for stability and bounds checking.
Earlier quoted context omitted.
I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze. There's basically dozens of very nice languages inside C++. That can be a blessing or a curse. I'm anxious for Herb Sutter's CPP2/CPPFront to become a stand…
What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.
My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.
That's how you emulate language features that aren't there originally. I've "impelemented" a static code block, like in Java:
https://stackoverflow.com/a/34321324/1593077
and that's all in C++98. The implementation is a bit ugly but the use is terse and self-expalantory.
Earlier quoted context omitted.
> There's a single "I guess I would use this" container type, std::vector. About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy. Agree with your takes on most of the c…
What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.
* APIs/function signatures explain more clearly what are the intended uses of the structure that's passed.
* More potential for compiler optimization
* Some potential for having these on the stack (if the compiler deduces the size already at compile-time)
* More convenient for static analysis
* No plethora of confusing constructors (including the infernal two-element ctors which can be misinterpreted super-easily)
etc.
Earlier quoted context omitted.
That's your opinion, others won't agree and would much rather not pay the price at all.
Those asserts probably saved a lot of development costs and increased the robustness of the software, which is worth a lot more than a few percent on a benchmark. I personally am more conservative on those things. I'll pick the fastest thing that is reliable.
Earlier quoted context omitted.
> Usually poorly. On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger. A specialized dynamic array class in a few hundred lines (at most!) and with ju…
Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'…
Most of the rest of us STL is good enough.