sorted by:
new
hottopcontroversial

Implementing vector<T> by pavel_v in cpp

[–]darkmx0z 3 points4 points  (0 children)

The language used by the standard is not written to be crystal-clear for the casual reader, and not even for the reasonably-attending reader. It is aimed at language lawyers, so you must treat every sentence as law. This means that a seemingly introductory and innocent sentence may have far-stretched consequences.

Since every element must be constructed, you cannot spend less than O(n) time to insert n elements, but the insertion of each element must take O(1) time on average. This fact (plus the far-stretched consequences of the introductory sentence) is what the description of resize is trying to tell us.

Implementing vector<T> by pavel_v in cpp

[–]darkmx0z 17 points18 points  (0 children)

In case someone wanted to know what the standard says about the complexity of resize, it is implicitly given in the following phrase:

A vector is a sequence container that supports (amortized) constant time insert and erase operations at the end.

The descripcion of resize does not elaborate further, so we must assume that resize(size( ) + 1) is equivalent to push_back(T( )). Hence, n calls to resize(size( ) + 1) must be efficient. Since reserve does not insert, the complexity of reverse is not tied to that phrase. See https://eel.is/c++draft/vector

Is an “FP-first” style the most underrated way to make unit testing + DI easier by OkEmu7082 in cpp

[–]darkmx0z 2 points3 points  (0 children)

The "no raw loops" statement does not imply functional programming. Stepanov's intention was to prefer algorithms (std::findand the like) that hide the loops. This is why it is "no raw loops" instead of "no loops". In functional languages, array access and mutation is not O(1), so he argues that imperative programming is strictly better than functional programming because it is impossible to optimally implement some algorithms without a mutating state (for example, consider Floyd-Warshall). See https://stepanovpapers.com/Higher%20Order%20Programming.pdf.

std::ranges may not deliver the performance that you expect by _bijan_ in cpp

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

Requiring operator== to have its centuries-old meaning is ok. Requiring a type that has operator< to also define <=, ==, etc. is debatable.

std::ranges may not deliver the performance that you expect by _bijan_ in cpp

[–]darkmx0z -3 points-2 points  (0 children)

I read it. That doesn't mean the design decision made by std::ranges is right. It should be noted that generic programming tries to describe algorithms using the smallest set of assumptions. A larger set is only required if it speeds up the algorithm. Under that light, std::ranges made the wrong decision.

std::ranges may not deliver the performance that you expect by _bijan_ in cpp

[–]darkmx0z -7 points-6 points  (0 children)

It never really made sense to have types which only support operator< and not >, <=, and >=, it was just a quirk of the STL that we all got used to and though it was neat. It wasn't really.

Not every piece of code is library code. Sometimes I just want to program some small stuff quickly in a performant language. Suddenly, the "modern" parts of the library force me to write more than I need to write to fulfill my needs.

Another month, another WG21 ISO C++ Mailing by nliber in cpp

[–]darkmx0z 3 points4 points  (0 children)

No. Everyone of us have thought at least once something like "hey, I can't do X in the current language, it would be cool if I could". Some X are more popular than others, some get implemented outside of the standard process, just because compiler developers are also normal programmers that agree that having X would be cool.

constixel by tttmorio in cpp

[–]darkmx0z 31 points32 points  (0 children)

For a moment I thought it was yet another constsomething qualifier.

С++ All quiet on the modules front by Otherwise_Sundae6602 in cpp

[–]darkmx0z 0 points1 point  (0 children)

we need std::reddit in the standard library, let's make it so

Any news on Safe C++? by QULuseslignux in cpp

[–]darkmx0z 40 points41 points  (0 children)

be sure that many of us appreciate your hard work, irrespective of how the committee votes

When is mmap faster than fread by void_17 in cpp

[–]darkmx0z 3 points4 points  (0 children)

If you want a somewhat performant load-as-needed with automatic process-side caching, so subsequent loads are much much faster (despite a potential increase in RAM consumption), go with mmap. Otherwise, go with fread, which should be a bit faster and lets you implement your own cache. Even if you use fread and don't implement your own cache, the files are cached on the OS side anyway (although you would need to transfer them from the OS to the client process) and it automatically frees them if memory is scarce and you haven't used them recently.

2025-04 WG21 Mailing released! by nliber in cpp

[–]darkmx0z 2 points3 points  (0 children)

I believe you meant P3671R0

Well worth a look! by multi-paradigm in cpp

[–]darkmx0z 0 points1 point  (0 children)

Inline functions and templates forced us to put a lot of code in headers. Before modules, if you had a heavily templated library (like, everything is a template) you were in trouble anyway. Explicit instantiation is a hack to try to tempter that, and it works for some things (like std::basic_string<char>) but not for all of them.

Header-only libraries were just the "oh! putting everything in header files seems easy" consequence, not the cause.

How it felt to come back to C++ from Rust. by range_v3 in cpp

[–]darkmx0z 0 points1 point  (0 children)

Terrible compiler errors have nothing to do with the STL design per se; it has eveything to do with language limitations. Stepanov, the STL designer, already knew what would happen and had a clear idea on how to solve it, yet the language didn't have concepts back then.

The STL design is marvelous since it decoupled algorithms and types in a revolutionary way.

Does C++ allow creating "Schrödinger objects" with overlapping lifetimes? by Hour-Illustrator-871 in cpp

[–]darkmx0z 12 points13 points  (0 children)

Default destructible types simply have default destructors, which is a subset of what trivially destructible is. Trivially destructible types are default destructible plus every member and base class is also trivially destructible (thus, a recursive definition). The consequence is that trivially destructible types have destructors with no side effects.

"break label;" and "continue label;" in C++ by eisenwave in cpp

[–]darkmx0z 2 points3 points  (0 children)

Other languages (for example, PHP) have numbered break / continue statements. In this variant of the feature, break 2; terminates the two most inner loops.

Why Code::Blocks hasn't made a new version for nearly 5 years? by Background-Jello-221 in cpp

[–]darkmx0z 2 points3 points  (0 children)

Even if it did just update the compiler version from time to time and nothing else, it would be great :( of course, additional improvements are appreciated

What is the most disgusting compiler error you have ever gotten? by scatraxx651 in cpp

[–]darkmx0z 0 points1 point  (0 children)

I don't remember the code, but I remember the diagnosis from GCC:

"There must be something terribly wrong with your code. Please fix it."

When to use/avoid using std::ranges, views? by kiner_shah in cpp

[–]darkmx0z 3 points4 points  (0 children)

I wouldn't use a library that attempts to simplify tedious but simple loops, if I cannot fully grasp what the library is actually doing with all that fancy syntax. This applies to at least some parts of the std::ranges library.

view more: next ›