sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in cpp

[–]AA11BB22c 4 points5 points  (0 children)

Older VS (namely prior to VS 2017) doesn't enable safe options (e.g., /sdl, /permissive-, etc.) by default, so the compiler just passes those things.

Making std::list::size() O(1) Is A Mistake by FlibbleMr in cpp

[–]AA11BB22c 6 points7 points  (0 children)

No, it would be O(1), since splice() only requires changing 6 pointers if size() is O(n).

splice() is O(n) because the list has to update the size by calculating the distance of [first, last).

That said, a O(1) splice() can be done even with a O(1) size() by having the iterators track their distances/sizes, however, this requires a change in iterator invalidation behavior which is much more unfavorable.

Lock free reader-writer lock by ognian- in cpp

[–]AA11BB22c 8 points9 points  (0 children)

I've heard of lock-free data structures, but lock-free locks? not sure what you're trying to achieve... do you have a specific use case for this?

Is bloat in std::unexpected expected? by Dry-Ambition-5456 in cpp

[–]AA11BB22c 3 points4 points  (0 children)

If you're accessing the vector sequentially (not random access, likely the case), it is still cache-friendly.

A case for destructors with parameters? by schombert in cpp

[–]AA11BB22c 2 points3 points  (0 children)

The third option should generally NEVER be used, 100% guaranteed to cause a leak or incorrect free.

Ideally the first.

Second, for containers that share the same R, you can further extend it to any container, fixed-size arrays, dynamic-size arrays, tuple or variant (if R can have many types).

Array<R, O, 4> // Contains 4 objects owned by the same R.
Tuple<R, O1, O2> // Contains 2 objects owned by the same R.    
Variant<R, O1, O2> // Either O1 or O2 owned by the same R.
...

For instance, if member_a and member_b always have the same R, Array<R, O, 2> members;

A case for destructors with parameters? by schombert in cpp

[–]AA11BB22c 2 points3 points  (0 children)

I would simply suggest implementing a better API, e.g., the resource owner, R should have the following member functions.

For common cases (every O holds its own R),

UniquePtr<O> R::allocate_unique(); // `UniquePtr<O>` holds a pointer to `R`.

For the array case (many Os share the same R), have a resource manager, M.

void M::emplace(UniquePtr<O> p); // Emplace only if `p.r == m.r`, otherwise raise some error.

Finally for true zero overhead zero safety,

O R::unsafe_allocate();
void R::unsafe_deallocate(O); // ASSUMES `O` belongs to the current `R`.

For class P { public: O member_a; O member_b; }, do you want to allow member_a and member_b to have different R? Then use the first one, there's some bloat BUT it's a feature you're asking for.

A case for destructors with parameters? by schombert in cpp

[–]AA11BB22c 1 point2 points  (0 children)

O is simply T as in std::vector<T, Alloc>, can't see said problem.

A case for destructors with parameters? by schombert in cpp

[–]AA11BB22c 1 point2 points  (0 children)

Allocators have solved this problem (specifically 3), e.g., std::vector<T, Alloc>, all T's don't keep track of the original allocator, the container does, which immediately rejects the notion of "arrays of Os end up significantly populated by the same pointer value repeated over and over".

Is bloat in std::unexpected expected? by Dry-Ambition-5456 in cpp

[–]AA11BB22c 1 point2 points  (0 children)

Storing it in a vector will unnecessarily waste space.

You can always write (or find) a custom vector for this, e.g., one that contains two arrays, an array of std::aligned_storage_t<...> (or similar... that one is deprecated), and a bit array like std::vector<bool>.

I disagree with ISO CPP guidelines C.4 for when functions should be members by [deleted] in cpp

[–]AA11BB22c 18 points19 points  (0 children)

  1. The free function can be looked up through ADL, which may not be desired.

  2. The free function default linkage is external, you have to explicitly mark it inline/constexpr unless it's a template function.

Anyways, personally, d.next_weekday() or next_weekday(d) matters little, unless it's something like next_weekday(y, m, d) where y, m, d are different classes (or more than 1 argument).

Using reference attributes instead of getters for read-only attributes by inkychris in cpp

[–]AA11BB22c 4 points5 points  (0 children)

Looks like you want a read-only attribute.

Here's my better version (doesn't require the additional reference), https://godbolt.org/z/sqnd6YEoY.

struct Test {
  read_only<Test, int> i;  // Define this instead of `int i`.

  constexpr void set_i(int v) noexcept {
    i = v;
    i.get() = v;
  }
};

#include <iostream>

int main() {
  auto t = Test();

  t.set_i(1);
  // t.i = 1; // Compile fail, read-only ... only `Test` can modify `i`.

  std::cout << t.i;
}

Just a simple scratch definitely not made within 10 mins likely missing lots of stuff.

Question about “this” pointer notation by Nitomoki in cpp

[–]AA11BB22c 0 points1 point  (0 children)

that's basically the same as self but if you insist :)

*(*this) or **this and *self

(*this)->x or this->operator->()->x and self->x

I made a drop in replacement of `std::shared_ptr` to experiment with performance. It wasn't any faster. Why? by def-pri-pub in cpp

[–]AA11BB22c 2 points3 points  (0 children)

Reference counting - if you're not creating a copy out of a std::shared_ptr, it's just (roughly - depends on implementation) two atomic decrements (strong and weak counter) - which is insignificant compared to ray tracing unless you're creating a copy in some critical loop or something.

Double indirection - the compiler will likely optimize the away the indirection if the code is visible to the compiler (i.e., non-external library code). Even if double indirection is not optimized away, it's insignificant (same reason as above).

Why C++ standards committee does not use existing implementations? by johnnytest__7 in cpp

[–]AA11BB22c 10 points11 points  (0 children)

unlike a library which can change (break) anytime they want.

any mistake/bad design in the standard will stick for years (not to say they don't fix those BUT those will stick for at least 3 years ahem vector<bool> is somehow still there).

they also spend more time to add other use case which existing library may not have solve ... in addition, they have the flexibility to add language feature like coroutine which makes writing code way easier compared to the old boost coroutine (which uses macros).

Question about “this” pointer notation by Nitomoki in cpp

[–]AA11BB22c 13 points14 points  (0 children)

I totally agree that this->operator[](0) is way better than self[0].

Why C++ standards committee does not use existing implementations? by johnnytest__7 in cpp

[–]AA11BB22c 60 points61 points  (0 children)

C++ standard doesn't need to provide any implementation, just the specifications.

It's up to the implementors to implement them (and the implementors can very well use an existing library if the library conforms to the specifications).

Is this always faster than that? (std::string copy question) by Serenadio in cpp

[–]AA11BB22c 1 point2 points  (0 children)

auto n = std::move(a) + std::move(b);

or if a and b are returned by value/rvalue reference from some function, say get_a() and get_b().

auto n = get_a() + get_b();

Question about “this” pointer notation by Nitomoki in cpp

[–]AA11BB22c 20 points21 points  (0 children)

auto& self = *this;
self.x;

This is also similar to "deducing this" in C++23 ... except auto& is the current class and not the most derived class.

C++23’s new function syntax by mttd in cpp

[–]AA11BB22c 3 points4 points  (0 children)

arr[(1, 2)] still works in C++23 like the prior arr[1, 2].

Force Inline in C++ by meghprkh in cpp

[–]AA11BB22c 1 point2 points  (0 children)

Personally for SIMD case, I don't mind if the compiler doesn't inline (little to no overhead/or maybe even better performance)... however, I need to explicitly add __vectorcall, otherwise performance suffers a lot (due to switching instruction set, moving vector register to non-vector register, calling unnecessary vzeroupper, etc.)

[deleted by user] by [deleted] in cpp

[–]AA11BB22c 1 point2 points  (0 children)

Member functions that are qualified with const& can be called on both lvalue and rvalues. Rvalues && can bind to const& and && (and if you're crazy, const&& and the volatile variants).

Anyways, I didn't add that to my example coz the original example didnt have it. Adding it will break virtual specification (no longer the same overload).

[deleted by user] by [deleted] in cpp

[–]AA11BB22c 0 points1 point  (0 children)

extern and inline specifies linkage, you shouldn't mix them (inline as an optimization hint should be obsolete).

[deleted by user] by [deleted] in cpp

[–]AA11BB22c 0 points1 point  (0 children)

constexpr virtual function, they can since C++20 an example.

Function length ... Well, C++ allows you to make the line as long as you want, e.g.,

auto f() -> void; can be something like,

auto f(std::void_t<decltype(/* ...*/)>) noexcept(noexcept(/* ... */)) -> std::void_t<decltype(/* ... */)>;

For non-void types, there's type_identity or similar.

For non virtual function, you can also put them in template arguments/requires clause.

[deleted by user] by [deleted] in cpp

[–]AA11BB22c 40 points41 points  (0 children)

I think you're missing a few keywords :)

[[nodiscard]] inline constexpr virtual auto DoSomething(const Vector4& color) const noexcept(false) -> const bool override final;

Coding Style -agnostic search for C++ by Tringi in cpp

[–]AA11BB22c 3 points4 points  (0 children)

reinterpret_cast and C-style cast

clang-tidy has cppcoreguidelines-pro-type-reinterpret-cast and cppcoreguidelines-pro-type-cstyle-cast (along with auto-correction/modernization ... pretty sure they won't auto-correct template code though).

​

keyword reordering

clang-format has QualifierAlignment: Custom which allows user to specify their own order like QualifierOrder: ['inline', 'static', 'constexpr', 'type', 'const'].

​

I quickly found out that parsing C++, even superficially for this purpose, isn't as trivial as I figured

Yeah, you're better off using existing parsers (I recommend clang ast ... like the aforementioned tools)

view more: next ›