Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three new utility functions in C++23

mariusbancila.ro

Post reply on HN
Print view View original

161–170 of 196 posts

Re: Three new utility functions in C++23

#161

Post by XCSme »

Koshkin wrote: post #155
XCSme wrote: post #137

Earlier quoted context omitted.

What do you mean? Sorting is done by swapping elements ( swap(a[i], a[j]) )

Well, first, whether swap() is used or not depends on the algorithm; second, the result of the sorting, as opposed to reversal, does not necessary look like the elements were swapped.

> whether swap() is used or not depends on the algorithm

I didn't mean the std::swap() function itself, but the swapping of two elements a[i] and a[j]. Is there any sorting algorithm that doesn't rely on swapping two elements (or two parts of the array)? I guess, only if the sort is not being done in-place and the result is stored in a different variable/memory.

> does not necessary look like the elements were swapped

The only way elements don't look like they are swapped is elements are changed, added or removed, which doesn't happen during sort.

Re: Three new utility functions in C++23

#162

Post by gpderetta »

grandmczeb wrote: post #149
nynx wrote: post #114

Earlier quoted context omitted.

I would’ve much rather have gotten span into C++11 than variadic templates, for instance. Definitely seems to me like a paper about span would’ve been a lot shorter and easier to write than one about variadic templates.

That’s a pretty surprising opinion. Variadic templates are extremely widely used and there’s no simple replacement (e.g. how would you implement something like emplace_back without them?) Span is trivial to replace with a third party library.

Very much. In many cases a single variadic replaces tens of thousands of lines of code, often machine generated, greatly simplifying code bases and speeding up compilation. It also immediately obsoleted the whole of boost.mpl. Together with lambda they are probably my favourite feature of c++11.

Span is nice especially as a vocabulary type, but it wasn't hard to implement something functionally similar and in practice most of codebases already did.

Re: Three new utility functions in C++23

#163

Post by pjmlp »

colanderman wrote: post #96
lvass wrote: post #75

Earlier quoted context omitted.

1. Isn't std inadequate in "embedded" programming?

Depends on what's you're targeting, but if you're coding for say, AVRs, you're not using C++, but rather C, in which case `unreachable` is your friend. [1] [1] https://en.cppreference.com/w/c/program/unreachable

In some cases not even C, just a tiny subset full of chip vendor extensions.

Re: Three new utility functions in C++23

#164

Post by pjmlp »

SeanLuke wrote: post #86

I think -- I hope? -- we're seeing the death spiral of this language. C++'s Biggest Problem: unbelievable, extraordinary, just mind-blowing levels of complexity. Solution: add more stuff!

While C++ is indeed a complex beast, mastering the whole of Java, C#, F#, Scala, Python, OCaml, Haskell in their latest versions, standard libraries and changes between major releases isn't any easier.

Re: Three new utility functions in C++23

#165

Post by kllrnohj »

Findecanor wrote: post #151
yrro wrote: post #6

Hmm. How often do people actaully want to std::byteswap as opposed to "convert this value from native byte order to big-endian" or "convert this value from little-endian to native byte order"? i.e., the functions documented in https://man7.org/linux/man-pages/man3/endian.3.html (why oh why are they not also documented in the GNU C Library Manual...)

I've always thought that it should have been possible in C and C++ to declare endian-ness as the property of a member variable's type , and that's it: the compiler would then automatically choose where to swap the byte-order to/from he native byte order. The benefits are obvious: Code is declarative, and there's no risk of a bug where you missed to call std::byteswap() or did it twice. Also, the compiler could automa…

Sounds like a pretty easy class you could write in C++. Template it for anything that's integral if you want to get fancy so you can do BigEndian or BigEndian and provide operators that convert to/from the "native" type transparently.

Is that generically useful enough to be part of the C++ standard? Seems like the type of thing that more belongs in a helper utility (aka, surely something like Boost already has this)

Re: Three new utility functions in C++23

#166

Post by TillE »

gpderetta wrote: post #162
grandmczeb wrote: post #149

Earlier quoted context omitted.

That’s a pretty surprising opinion. Variadic templates are extremely widely used and there’s no simple replacement (e.g. how would you implement something like emplace_back without them?) Span is trivial to replace with a third party library.

Very much. In many cases a single variadic replaces tens of thousands of lines of code, often machine generated, greatly simplifying code bases and speeding up compilation. It also immediately obsoleted the whole of boost.mpl. Together with lambda they are probably my favourite feature of c++11. Span is nice especially as a vocabulary type, but it wasn't hard to implement something functionally similar and in practic…

Heck I'm still using gsl::span, though that's mainly for compatibility with a C++17 compiler. It's great that std::span was standardized, maybe it was overdue, but it's just a drop-in replacement for stuff that already existed and worked fine.

Re: Three new utility functions in C++23

#167

Post by froh »

a2800276 wrote: post #68
s28l wrote: post #47

Earlier quoted context omitted.

1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is. From a compiler perspective, using a function makes the most sense, since that fits into the existing control…

> 3. `htonl` are not standardized, so they were not part of the C++ standard library. I was questioning the motivation of this to facilitate network-byte-order issues as stated in the blog post. The proposal[1] (that the post linked to) also confirmed that the motivation was to expose more machine code intrinsics rather than deal with network byte order like I expected. Concerning 1.) yeah, I guess I'd prefer a #prag…

one easily overlooked use of hton ntoh is portable binary persistent data. you want to read and write binary files in different cpu architecture hosts? mount a pluggable "disk" from different devices? use hton and ntoh to write/read binary data...

Re: Three new utility functions in C++23

#168

Post by SubjectToChange »

lvass wrote: post #75
colanderman wrote: post #48

Earlier quoted context omitted.

Longtime C, C++, and embedded programmer here. 1. Why "should" it be something different? It is semantically part of code flow; making it a pragma breaks that model. This replaces the nonstandard __builtin_unreachable(). 2. This doesn't exist to save typing. static_cast doesn't make sense to me (that reads like a no-op). static_cast introduces a new reserved word which is a big no-no. 3. This is not the same as htonl…

1. Isn't std inadequate in "embedded" programming?

A lot of it, sure. But there are a lot of header only types which do not dynamically allocate memory on their own. For instance , , , , , , etc.

Re: Three new utility functions in C++23

#169

Post by SubjectToChange »

SeanLuke wrote: post #86

I think -- I hope? -- we're seeing the death spiral of this language. C++'s Biggest Problem: unbelievable, extraordinary, just mind-blowing levels of complexity. Solution: add more stuff!

> I think -- I hope? -- we're seeing the death spiral of this language.

In a lot of metrics C++ has never been more popular. And given the direction of heterogeneous programming, C++ is here to stay.

> Solution: add more stuff!

In a lot of ways, yes, that is the solution.

Re: Three new utility functions in C++23

#170

Post by randomNumber7 »

addaon wrote: post #146
int_19h wrote: post #140

Earlier quoted context omitted.

What's bizarre about asserts being disabled if you explicitly ask for it?

I'm not asking for the assert to be disabled. I'm asking for debugging features to be disabled. (NDEBUG == "no debug.") The debugging feature of an assert statement is that it performs work to check if the assertion is true and provides diagnostics if not. Disabling the debugging feature of an assert would, in my mind, make it purely an assertion -- an assumption that the compiler can count on (since this is true by…

The D Programming language actually uses assert(0) in that way. Except its not undefined behaviour if the code is reached in release builds. The compiler will put in a special assembly instruction which chrashes the programm.
Post reply on HN