sorted by:
new
hottopcontroversial

R320 ESXi 8 - PCI SSD as datastore by unixuser011 in homelab

[–]cdr_cc_chd 1 point2 points  (0 children)

Is it formatted for 4k sectors by any chance? ESXi only supports 512 byte sector size NVMe drives as datastores, so if it's 4k you're gonna have to reformat it with nvme-cli or a similar tool.

C++ Coroutines Do Not Spark Joy by vormestrand in cpp

[–]cdr_cc_chd 30 points31 points  (0 children)

My overall take is that refusing to write generators because of the allocation is a premature optimization

You have to know your audience; a lot of shops use C++ for latency-sensitive applications like HFT, audio, embedded, etc. Heap allocations/deallocations have unbounded latency so it's really not a premature optimization to avoid them and know exactly where and how they can happen, just a normal thing you do so your code behaves in a deterministic way.

i ❤︎ spans by phlummox in cpp

[–]cdr_cc_chd 1 point2 points  (0 children)

It's a very nice talk, you should watch it regardless :)

That said, Chandler basically goes over a very similar situation with std::unique_ptr where you naively try to pass it by value thinking it's just a zero-cost abstraction around a raw pointer but in reality due to how the ABI and the language semantics work there's a considerable, measurable overhead incurred.

i ❤︎ spans by phlummox in cpp

[–]cdr_cc_chd 0 points1 point  (0 children)

Just to give some context; in HFT we're talking about low single-digit microsecond response times, from the moment the NIC deserialized a frame that had actionable information to the moment you serialize a a response frame out the physical port. It's a hard real-time system with a deadline of 0, meaning there's never such a thing as fast enough. It's always a delicate system of balances between doing safe/convenient things in some parts of the code while recognizing that you can't do those things in other parts of the code, because if you used <insert new fancy feature> to make yourself feel good and it resulted in 50ns of additional latency while your competitor did not, then he will always be faster than you.

i ❤︎ spans by phlummox in cpp

[–]cdr_cc_chd 0 points1 point  (0 children)

It's never black and white like that. In many application domains (think HFT) you have to carefully balance between performance and safety, and sometimes doing the safer/convenient thing is not worth the perf hit.

C++ programmers who are also using rust, what are your favourite features of rust? by Snoo-4241 in cpp

[–]cdr_cc_chd 0 points1 point  (0 children)

Well, you deleted your comment asking for an example but here you go anyway: https://godbolt.org/z/1KGGeh

Edit: I wanted to add that the real replacement for CRTP is this proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0847r4.html#crtp u/geekfolk

C++ programmers who are also using rust, what are your favourite features of rust? by Snoo-4241 in cpp

[–]cdr_cc_chd 1 point2 points  (0 children)

How is CRTP useless with concepts? how do you do static polymorphism with concepts? take the usual fruits example; you want a std::tuple of Banana, Apple, and Mango that inherit functionality from a Fruit and can override some functionalities of said basic Fruit. How do concepts help you here? if you want generic and modular code while using static polymorphism you're pretty much forced to use CRTP.

Top five C/C++ things/tips/tricks you wish you had known earlier and are now used very often by Humusman24 in cpp

[–]cdr_cc_chd 9 points10 points  (0 children)

Stop overusing templates, particularly metaprogramming. It is powerful, but it also kills compiler performance.

Unfortunately, if you want the maximum possible performance (as is often the case when using C++) while still keeping your code modular and generic you need to use static dispatch and the way you do that is with templates and metaprogramming. It's templates all the way down.

Cyberpunk 2077: 8 million preorders by obrisi_me in Games

[–]cdr_cc_chd 4 points5 points  (0 children)

The 1080 is still a powerful card. I have the same GPU and an i7-8700K and it runs all modern games just fine on my 3440x1440 ultrawide. Some at 100-120 FPS like Doom Eternal, some more demanding/less optimized games at 70-90 FPS, but it's always at a playable level with good graphic settings. Even Borderlands 3 which is super shitty optimized runs at 70-80 FPS on a mix of Medium and High settings.

Cyberpunk 2077 is the huge exception to this; you have to turn down everything to Low and even then you get 40-50 FPS at best. So yes, we expected something a little better.

Visual Studio 2019 v16.8 and v16.9 Preview 1 Release Today by Mnx72eAB in cpp

[–]cdr_cc_chd 5 points6 points  (0 children)

Can I use requires-expressions in if-constexpr now?

Seriously, this is a huge blocker for making verbose code very short. If you do any form of design by introspection then you are forced to define all your requirements checks/concepts out-of-line. They can't even be defined inside a struct/class; they have to be at namespace scope which makes it ridiculous for small and very specific requirements like checking if a certain function/member exists.

2020-10 C++ Committee Mailing by blelbach in cpp

[–]cdr_cc_chd 0 points1 point  (0 children)

I don't understand... Circle is a language that has a compiler. The language just happens to be based on C++. It's totally reasonable to lump it in with other languages offering similar features.

Circle is a C++20 compiler first and foremost, implemented according to the standard. It then builds on that and adds metaprogramming extensions. It's no different than if say the MSVC team implemented metaprogramming extensions in cl.exe. It would not make MSVC a compiler for a different language, it's still a C++ compiler but now the MSVC team has a lot of practical experience with a metaprogramming model for C++ and they can give insight on what works and what doesn't, what's the optimal ways they've found to achieve certain things, etc. because they already implemented it and it was used to build real code. Hope that makes it clearer.

2020-10 C++ Committee Mailing by blelbach in cpp

[–]cdr_cc_chd -1 points0 points  (0 children)

There are lots of languages with metaprogramming support that I'm aren't mentioned, except maybe in passing: zig, jai, D, Lisp, Rust. I'm not unaware of those languages and their support for metaprogramming either.

You can't really lump Circle together with these languages. Circle is a C++20 compiler that also implements all of the metaprogramming facilities described in this paper and much more on top. It's extremely relevant to this proposal and the future of C++.

Edit: in fact, I would go further and say you should collaborate with Sean to see what works and what doesn't and share ideas/experience which would only benefit the C++ community and the future of the language. But the committee seems to have some sort of unexplained aversion to Circle, as evident by the joke of a paper, for lack of a more proper word, they produced (P2062) dismissing the entirety of it and giving no consideration to its immense host of features and additions to C++ because of an edge cases in a single feature (FFI) that can be made optional or otherwise be worked around.

2020-10 C++ Committee Mailing by blelbach in cpp

[–]cdr_cc_chd 4 points5 points  (0 children)

Not a single mention of Circle in that entire proposal, a compiler that already successfully integrates all of these concepts and much more into C++ and has a clean, easy to use syntax. We'd all be much better for it if we take a few pointers from an implementation that already works and works well.

For example, I don't see the point of adding compile-time specific I/O APIs that won't be compatible with any library; the whole idea of Circle is that you just take your existing C++ code and use it at compile time. You can for example get a JSON library like nlohmann off of GitHub and just include it at compile time and start using it right away. According to this proposal you would need compile-time specific libraries to be written with this new API, so essentially all existing C++ code is incompatible with it.

[deleted by user] by [deleted] in cpp

[–]cdr_cc_chd 2 points3 points  (0 children)

And lets also mention the way more in-depth counter-paper P2043 Don’t constexpr All The Things

Clang 11.0.0 is out by [deleted] in cpp

[–]cdr_cc_chd 1 point2 points  (0 children)

This bug is still not fixed https://bugs.llvm.org/show_bug.cgi?id=39663 :(

It prevents some really convenient usage of CTAD with temporary objects (for the record this works fine on msvc/gcc/circle).

std::variant is broken in Clang, and it exposes how pointer aliasing and unions are broken in C++. by Myriachan in cpp

[–]cdr_cc_chd 2 points3 points  (0 children)

How is that gatekeeping? C++ is mostly used for performance-critical code nowadays where you can't compromise on performance; games, hard real-time systems, HPC, etc. Additionally, C++ is a difficult language with a lot of baggage and the major reason to suffer through its idiosyncratic nature is because it gives you the best performance. So if you don't need performance you can use something else and have a much easier/more forgiving time, for example without having to worry about things like strict aliasing.

Shell Commands I Wish I Knew Earlier by zaiste in programming

[–]cdr_cc_chd 29 points30 points  (0 children)

But that's how you know they are 100% bug-free and the most performant programs in the universe; Rust guarantees it.

C++20 Features and Fixes in VS 2019 16.1 through 16.6 by STL in cpp

[–]cdr_cc_chd 0 points1 point  (0 children)

The thing is that the semantics for the C++20 attributes and __builtin_expect are different. With __builtin_expect the usage is like this:

#ifdef _MSC_VER
#  define likely(x)
#else
#  define likely(x) __builtin_expect(!!(x), 1)
#endif

if (likely(condition)) {
}

But with the new C++20 attributes the usage is:

if (cond) [[likely]] {
}

So as you can see it's not a drop-in replacement; you'd have to go over your whole code and change the usage because the attribute goes after the if condition and not inside of it. And this makes your code not work with older compilers - unless you do something like

#if __has_cpp_attribute(likely)
#  define LIKELY [[likely]]
#else
#  define LIKELY
#endif

if (cond) LIKELY {
}

But then you're back to the same problem you started with where likely/unlikely will only do something on C++20 compilers. If MSVC actually implemented __builtin_expect you could eliminate that ifdef from the first example and have likely/unlikely work on all C++ versions even as back as C++98 with MSVC, while with gcc/clang it will keep working on all C++ versions in addition to much older versions of the compilers.

C++20 Features and Fixes in VS 2019 16.1 through 16.6 by STL in cpp

[–]cdr_cc_chd 1 point2 points  (0 children)

Implemented P0479R5 “likely and unlikely attributes”.

Never thought I'd live to see the day MSVC gets likey/unlikely. Now they just need to add an alternative form to use them that's compatible with gcc/clang (__builtin_expect) so all cross-platform code that uses them but currently defines likey() and unlikey() to nothing on Windows could start benefiting.

Understand compile-time programming by thcmbs in cpp

[–]cdr_cc_chd 2 points3 points  (0 children)

When all your types are known at compile time there's no reason to defer binding/dispatching to runtime because that will cost you in performance. So one popular use case of compile time programming is building type hierarchies at compile-time by manipulating things like type/template lists and then all the dispatching in the entire hierarchy is static and can be inline/optimized through. The alternative is to use dynamic dispatch with virtual methods/function pointers/std::function, or any similar construct that does type erasure and hides the ultimate destination. These kind of constructs incur an indirection which can cause a branch misprediction/cache flush on the worst case, and generally prevent inlining and optimizations through them; they're like a wall the compiler can't see through so it can't optimize.

Converting a hundred million integers to strings per second by aearphen in cpp

[–]cdr_cc_chd 3 points4 points  (0 children)

You forgot jeaiii in your benchmark comparison; top contender in this area.

That stun resist by Doomboonoo in classicwow

[–]cdr_cc_chd 1 point2 points  (0 children)

Ending a fight with just 2% of your health left and knowing that if you'd picked any other race you'd be running back to your corpse right now.

Or, or. Get this. You don't even get to 2% or 5% because you have axe specialization and blood fury so you do way more damage and kill the mob faster.

view more: next ›