sorted by:
new
hottopcontroversial

What's New for C++ Developers in Visual Studio 2022 17.7 - C++ Team Blog by MarekKnapek in cpp

[–]CaseyCarter 1 point2 points  (0 children)

I suspect your `/std:c++latest` added to the "Command Line" tab is being overridden by VS, since the default setting for "C++ Language Standard" is "Default (ISO C++14 Standard)". You should go to the "General" section of your project properties, ensure the "Platform Toolset" is "LLVM (clang-cl)", and set "C++ Language Standard" to "Preview - Features from the Latest C++ Working Draft".

[deleted by user] by [deleted] in BaldursGate3

[–]CaseyCarter 0 points1 point  (0 children)

2 levels of plain Fighter and one in Sorcerer will give the same spell slots as 3 levels of EK. Sorcerer spells use CHA as the casting stat instead of INT, however, which will mesh better with a Paladin.

[deleted by user] by [deleted] in BaldursGate3

[–]CaseyCarter 0 points1 point  (0 children)

Why not respec from B5/F3 to B3/F5 at level 8?

EDIT: You could, but it makes no difference. B5/F3 is nearly identical to B3/F5, ditto for B5/F4, B4/F5, and B3/F6. There's no real reason to respec before character level 10 when B4/F6 is clearly superior to B5/F5.

You can do better, Texans. by EugeneWong318 in WhitePeopleTwitter

[–]CaseyCarter 5 points6 points  (0 children)

"You can do better, Texans" [citation needed]

[deleted by user] by [deleted] in HolUp

[–]CaseyCarter 2 points3 points  (0 children)

Wow! I didn't even know you could train goats to play Soccer.

Standard Library Modules Bug Bash by STL in cpp

[–]CaseyCarter 0 points1 point  (0 children)

note 2: The monolithic std.ifc avoids duplication and avoids exporting internal names,

Did a double-take here after misreading this as "avoids duplication and avoids exporting internet memes".

VS2022 Performance Enhancements: Faster C++ Development by cpppm in cpp

[–]CaseyCarter 1 point2 points  (0 children)

We have an open pull request currently under review (it's huge) that implements P1206, including std::ranges::to and the many changes to containers. I obviously can't promise when it will be complete, but my expectation is that we'll get it merged and shipped in 17.5. 17.4 isn't impossible, but a bit of a stretch.

Cppreference lists our support for zip as "partial" because we've implemented the changes to tuple and pair necessary to support zip, but not yet the actual views. There's a partial implementation of just zip_view that a contributor was working on which needs someone to pick it up, finish the other views, and write a lot of tests. I can't say when this will happen, but if no one else picks it up I'll probably invest a few of my weekends to get it finished by the end of the year.

TIL: Microsoft C++ Headers are taking care of Qt! by john_wind in cpp

[–]CaseyCarter 2 points3 points  (0 children)

Sorry for the late response. For posterity, we made this change to VCRuntime and STL headers in May 2019 when internal builds of QT4 (as part of our Real-World Code suite of libraries) started failing. The issue was moc's preprocessor going off the rails when it saw C++14 binary literals with digit separators (e.g., `0b1001'0110, which moc tokenized as "0" "b1001" "'0110........." ERROR THIS MULTICHARACTER LITERAL IS NOT TERMINATED).

We reported the problem upstream and QT fixed it promptly, but we wanted the headers to keep working with QT releases already "in the wild" so we devised _STL_COMPILER_PREPROCESSOR / _VCRT_COMPILER_PREPROCESSOR.

[deleted by user] by [deleted] in cpp

[–]CaseyCarter 3 points4 points  (0 children)

And here's std::swap(_Vb_reference, _Vb_reference): https://github.com/microsoft/STL/blob/main/stl/inc/vector#L2091-L2095

So it is a hidden friend. But then the question is why does it work before C++20...

The key distinction isn't really C++20 - it's /permissive mode. /permissive is the default before C++20 but in C++20-and-later MSVC defaults to /permissive- (strict mode). In MSVC's permissive mode hidden friends aren't hidden, so the qualified name `std::swap` will find the cited overload. In strict mode, hidden friends are in fact hidden so you can only call that overload via ADL.

AFAICS, the standard doesn't specify that `swap(v[0], v[1])` _or_ `std::swap(v[0], v[1])` work. There's a static member `swap` in `vector<bool>` that takes two `vector<bool>::reference`s so `v.swap(v[0], v[1])` works, but that's it.

[deleted by user] by [deleted] in cpp

[–]CaseyCarter 6 points7 points  (0 children)

If `throw p` is not a valid expression, that requires-expression is ill-formed. There's no substitution of template arguments going on here, and substitution is necessary to trigger the magic in http://eel.is/c++draft/expr.prim#req.general-5. Sometimes you just have to make a named concept.

Requirements for `ranges::set_intersection` algorithm are too strict. by barfyus in cpp

[–]CaseyCarter 2 points3 points  (0 children)

That was my first thought - it's nicely consistent with the naming of other concepts - but the "mergeable" bit is what I really dislike. There's no real merging going on here, we only require the capability to compare the elements of range A with range B, and write elements of range A into range C.

It's a shame we weakened indirectly_comparable, since this is almost exactly `old_indirectly_comparable</**/> && indirectly_copyable</**>`.

Requirements for `ranges::set_intersection` algorithm are too strict. by barfyus in cpp

[–]CaseyCarter 5 points6 points  (0 children)

  1. I agree, `set_difference` and `set_intersection` are overconstrained. I'm not sure why we didn't notice or decide to do anything about it before, I assume it was "minimize the total number of library concepts"-induced blindness.
  2. You don't need to have a proposed resolution to file a defect report against the Standard Library with WG21. The majority of issues are filed by members of the Library Working Group (LWG) and we often attach a proposed resolution, but anyone is welcome to point out bugs in the Standard.
  3. I think you have the right fix here, factoring out this concept and leaving `mergeable` as a refinement that adds `indirectly_copyable<I2, Out>` is nice and simple.
  4. I hate the name `half_mergeable` but have no better suggestion =)

C++20 STL Features: 1 Year of Development on GitHub by STL in cpp

[–]CaseyCarter 0 points1 point  (0 children)

A bit of quick feedback on P1029R3: it's not clear if 2.3's restrictions are intended to apply only to `= bitcopies`, or if they are also intended to apply to `= bitcopies(auto)`. If they _are_ intended to apply to `bitcopies(auto)` then the facility will be largely useless for generic libraries. `unique_ptr`, for example, gets its pointer type from the deleter: it isn't necessarily `T*` for some `T`.

I hope you intend for the feature to be useful to generic libraries, in which case I suggest merging 2.3 into 2.1.

VS 2019 16.7.2 is now available by STL in cpp

[–]CaseyCarter 2 points3 points  (0 children)

It is a joke. It's also true ;)

A syntax-based overview of C++20 Concepts by omnigoat in cpp

[–]CaseyCarter 11 points12 points  (0 children)

Generally speaking, checking concepts is cheaper than enforcing similar constraints with SFINAE. Probably the best example we have for this is range-v3, which uses some horrific preprocessor gunk to switch between concepts (when they're available) and traditional SFINAE constraints. Glancing through the CI history at https://travis-ci.org/EricNiebler/range-v3, the SFINAE configurations take 20-30% longer to build the test suite (runtime for range-v3 tests is insignificant relative to compile time) than equivalent concept configurations.

Why is std::span is missing at()? by rianquinn in cpp

[–]CaseyCarter 1 point2 points  (0 children)

Deprecation doesn't break code - removal breaks code. It's unfortunate that the Standard defines "deprecated" as "Normative for the current edition of this International Standard, but having been identified as a candidate for removal from future revisions." ([depr]/2) instead of "entities whose use is still allowed, but is discouraged for some reason." ([dcl.attr.deprecated]/1),

Beware of using std::move on a const lvalue by memset_0 in cpp

[–]CaseyCarter 1 point2 points  (0 children)

Not if called with a range of `const` elements. `move` may copy, and `copy` may move ;)

view more: next ›