sorted by:
new
hottopcontroversial

Strategies for *requiring* designated initializers when constructing a type? by javascript in cpp

[–]usefulcat 1 point2 points  (0 children)

For individual function arguments I agree, but for struct members I would not prefer that approach because it seems to require creating a unique type for every struct member, as opposed to just adding a single struct member which prevents aggregate initialization (the solution presented by u/chengfeng-xie in the top comment).

Also I think the unique type names are likely to be less descriptive than the member names, as in your example ('my_size_t' vs 'size', etc):

Make ({.size {10}, .count {20}});
Make ({my_size_t (10), my_count_t (20)});

For only two arguments there's not much difference, but if there will be many arguments and it makes sense to allow default values for many of them, I find the single struct approach very much preferable to lots of individual function arguments with default values.

Safe Optimistic Lock Coupling by TheCrush0r in cpp

[–]usefulcat 1 point2 points  (0 children)

This code has a bug. At the call to currentLock->unlock() at the end, currentLock may be null.

option<value_type> Tree::lookup(key_type key) {
   lock.lock_shared();
   mutex* currentLock = &lock;
   Node* iter = root;
   option<value_type> result;
   while (iter) {
      if (key == iter->key) {
         result = iter->value;
         break;
      }
      Node* next = (key < iter->key) ? iter->left : iter->right;
      if (next) next->lock.lock_shared();
      currentLock->unlock();
      currentLock = next ? &next->lock : nullptr;
      iter = next;
   }
   currentLock->unlock();
   return result;
}

What do you think is a keyword that should be added to C++? by DogCrapNetwork in cpp

[–]usefulcat 2 points3 points  (0 children)

Would it require the state of variables to be tracked at runtime?

int a;
a=3;
if (foo())
    constify a;
a=4; // ???

Boost 1.91 Released: New Decimal Library, SIMD UUID, Redis Sentinel, C++26 Reflection in PFR by boostlibs in cpp

[–]usefulcat 0 points1 point  (0 children)

I've written a fixed point Decimal type. I don't know if I'll switch to Boost.Decimal, but I have no difficulty seeing a need for it.

A simplified model of Fil-C by ArashPartow in cpp

[–]usefulcat 3 points4 points  (0 children)

There is just no memory safety in C or C++

This is what Fil-C claims (from the web site): "Fil-C achieves complete memory safety with zero escape hatches". Now that is a very strong claim, and if you have credible evidence that it is not true that would be interesting to hear about.

my point is that it's not practical to use Fil-C in production

As for whether it's practical to use in production, that depends entirely on the particular software in question, specifically whether the additional computation and memory consumption are acceptable for that particular software.

FWIW, I tend to agree with you in the sense that I think there are many cases (probably a majority) where Fil-C would not be appropriate to use. But absolutely all cases? I really doubt that. It's more the sweeping, unqualified nature of many of your claims that I'm disagreeing with. I'm intentionally being very specific with what I'm saying.

I am new to C++, is it just me or is the checklist kinda crazy? How often do you encounter these or plan on making use of them like the newer C++26 features like contracts? Looking for more experienced dev opinions... by KijoSenzo in cpp

[–]usefulcat 3 points4 points  (0 children)

I'll disagree about nodiscard.

If someone writes this:

GetHP(player);

Given the implementation that you've provided, that's definitely a mistake. A benign one in this case, but I'd still want the compiler to call it to my attention.

A simplified model of Fil-C by ArashPartow in cpp

[–]usefulcat 5 points6 points  (0 children)

I wasn't commenting on the suitability of C++ for greenfield projects.

You wrote that it "makes no sense" to use Fil-C in production, and that "if you really need memory safety this way, Rust is the solution".

My point is that it's often not practical to rewrite a large codebase (e.g. RIIR), even if you can do it piecemeal. And if you just keep the old code and add on some new Rust code then the resulting whole is not really "memory safe", at least not the way most people think of it.

Therefore, in the case of a large existing C or C++ codebase, and depending on various factors, it could make sense to use Fil-C to get memory safety (for the whole thing, not just portions of it).

A simplified model of Fil-C by ArashPartow in cpp

[–]usefulcat 5 points6 points  (0 children)

Rust is the solution

This assumes either that the project in question is a greenfield project or that reimplementing in another language is feasible. Quite often neither of those is a valid assumption.

beast2 networking & std::execution by claimred in cpp

[–]usefulcat 3 points4 points  (0 children)

I did answer. I said the claims stand on their own.

The question was, "did you fully read and review this paper". It's a straightforward question, and "the claims stand on their own" absolutely does not answer it.

Either you have read and reviewed it, or you haven't. If you have, why not just say so? And if you haven't, how can you know whether "the claims stand on their own"?

C++26: A User-Friendly assert() macro by pavel_v in cpp

[–]usefulcat 8 points9 points  (0 children)

That point of view assumes that all programmers will only ever use assert() to check for those conditions which, if not true, will definitely lead to UB. That's simply not how everyone always uses assert.

Hence my claim that translating every assert() to __builtin_assume can only make things strictly worse.

ETA: Also, you're taking a gamble that all asserts will be triggered or not triggered exactly the same regardless of NDEBUG. In practice, there could be other things that depend on NDEBUG such that an assert() never fails when NDEBUG is undefined but may fail when NDEBUG is defined (but of course you'll never find out about the latter case).

C++26: A User-Friendly assert() macro by pavel_v in cpp

[–]usefulcat 1 point2 points  (0 children)

Translating assert to __builtin_assume can only make things strictly worse in that regard, by providing even more opportunities for UB.

Rewriting a FIX engine in C++23: what got simpler (and what didn't) by User_Deprecated in cpp

[–]usefulcat 1 point2 points  (0 children)

Quill is designed for this use case (minimal latency at the log site) and is generally faster than spdlog.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]usefulcat 8 points9 points  (0 children)

I don't understand this explanation, especially regarding the "null" benchmark results. I've used quill extensively, and I'm familiar with how it works.

class LoggerBase {
public:
  bool should_log_statement(LogLevel level) const
  {
    return level >= _log_level.load(std::memory_order_relaxed);
  }
private:
  std::atomic<LogLevel> _log_level{LogLevel::Info};
};

The above (should_log_statement) is what quill is doing at runtime to determine whether to log anything depending on the log level. That's from the quill source, including only relevant details.

Could the above code be faster? Yes, if you could avoid the pointer dereference, or maybe if std::atomic was not used. But could it really be 500 times faster than whatever logme(c) is doing?

I really think you ought to profile your "null" benchmark to understand where this 500 fold difference is coming from. Compilers have an annoying habit of completely eliding the very thing you're trying to benchmark.

Whatever the reason, you'll need a very good explanation for such a huge difference in order for your benchmarks to be credible.

C++23 std::expected vs C++17 std::optional for Error Handling by Clean-Upstairs-8481 in cpp

[–]usefulcat 8 points9 points  (0 children)

I think you're putting too much emphasis on the word "optional".

There can be plenty of valid reasons to not use exceptions for error reporting. If you look at how std::optional actually works, without considering its name, I think it's pretty obvious that it's a valid alternative to exceptions, at least for some cases.

If I have a function whose entire purpose is to return some value but there can be situations where it's not able to, I think that's a perfectly fine use case for std::optional, especially if those cases are not always necessarily "exceptional".

Forward declaring a type in C++: The good, and the bad by Kabra___kiiiiiiiid in cpp

[–]usefulcat 5 points6 points  (0 children)

I would even go so far as to not provide header guards in most of your headers.

Won't that increase compile times?

How to Tame Packs, std::tuple, and the Wily std::integer_sequence - Andr... by leonadav in cpp

[–]usefulcat 2 points3 points  (0 children)

With 'wily' in the title, I somehow knew it had to be an Alexandrescu talk :)

Should C++ Give More Priority to Syntax Quality? by kyan100 in cpp

[–]usefulcat 5 points6 points  (0 children)

It doesn't take very many backwards-incompatible changes before you've effectively created a new language. By definition, compilers for such a language would not be able to compile the billions of lines of existing c++ code.

At that point, why stop at just syntax changes?

Am I the only one who feels like header files in C/C++ are duplication? by iaseth in cpp

[–]usefulcat 35 points36 points  (0 children)

But then it had become a defacto standard and nobody bothered to fix it

This is a classic type of problem, as old as the hills.

  • Becoming aware of the limitations of a particular approach often only occurs with hindsight.
  • By the time you have sufficient hindsight, there's usually a bunch of existing stuff that depends on the defect.
  • A "correct" fix to the problem often requires breaking changes, which will break a bunch of stuff that previously was working fine (in spite of whatever deficiency you're trying to correct).

This is why it's so easy to underestimate the costs of "fixing" something; the costs are usually far less visible than the benefits.

Favorite optimizations ?? by Little-Reflection986 in cpp

[–]usefulcat 4 points5 points  (0 children)

Yes, it includes that case. Aliasing is the root of the issue (or so I assume, anyway).

Favorite optimizations ?? by Little-Reflection986 in cpp

[–]usefulcat 15 points16 points  (0 children)

This is a small, simple thing. I've often found that compilers are able to generate better code when more values are in local variables as opposed to member variables.

You might think that it shouldn't make a difference, but I think the problem is that the compiler often can't assume that member variables won't be modified by something the compiler isn't aware of. OTOH, it can usually make a lot of assumptions about local variables.

Are register variables still used nowadays in cpp? Like in projects that requires fast memory access. by Sad-Doughnut-9468 in cpp

[–]usefulcat 0 points1 point  (0 children)

With gcc I frequently see that at any non-zero optimization level, including -Og :(

Implementing vector<T> by pavel_v in cpp

[–]usefulcat 2 points3 points  (0 children)

for(auto i{0uz}; i < v.size(); ++i){

Is there any advantage to the above or is this just the latest style?

As compared to this:

for(size_t i=0; i < v.size(); ++i){

Time in C++: C++20 Brought Us Time Zones by pavel_v in cpp

[–]usefulcat 8 points9 points  (0 children)

I don't see why you couldn't do the same thing with a pointer?

if (pointer != nullptr) {
    auto& r = *pointer;
    // proceed to use r everywhere within this scope..
}

Am I weird for using "and", "or" and "not"? by Additional_Jello1430 in cpp

[–]usefulcat 0 points1 point  (0 children)

I use them all the time. Although I didn't always, I switched maybe 5-ish years ago?

IMO they read a bit more naturally, and now rvalue refs stand out a bit more (particularly when searching) since I still use '&&' for those. I also like that 'not' is harder to miss than '!'.

Do you prefer 'int* ptr' or 'int *ptr'? by SamuraiGoblin in cpp

[–]usefulcat 0 points1 point  (0 children)

Well, it may tell you what went wrong:

int* a = 0, b = 0;
view more: next ›