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

A header-only C implementation of C++

github.com

Post reply on HN
Print view View original

11–20 of 94 posts

Re: A header-only C implementation of C++ <algorithm>

#11

Post by [deleted] »

lelanthran wrote: post #5
tw1984 wrote: post #4

I feel sick everything time when I see C++ related stuff, simple & fun programming got so complicated just because some big name "committee members" who insist to spend 30 years to standardize networking/filesystem/reflection refuse to simplify their craps. yes, they haven't got that completed yet. I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking?

> I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking? You don't really need to wait if you're willing to use Objective C with the GnuStep framework. You'll get reflection, and a lot of other nice addons[1]. [1] Dunno about network support; ISTR it being part of the GnuStep framework, but could be wrong.

[deleted]

Re: A header-only C implementation of C++ <algorithm>

#12

Post by [deleted] »

lelanthran wrote: post #5
tw1984 wrote: post #4

I feel sick everything time when I see C++ related stuff, simple & fun programming got so complicated just because some big name "committee members" who insist to spend 30 years to standardize networking/filesystem/reflection refuse to simplify their craps. yes, they haven't got that completed yet. I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking?

> I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking? You don't really need to wait if you're willing to use Objective C with the GnuStep framework. You'll get reflection, and a lot of other nice addons[1]. [1] Dunno about network support; ISTR it being part of the GnuStep framework, but could be wrong.

[deleted]

Re: A header-only C implementation of C++ <algorithm>

#13

Post by kzrdude »

lionkor wrote: post #10

Isn't this a use-case for _Generic[1]? [1]: https://en.cppreference.com/w/c/language/generic

With _Generic, the original library implementor has to accommodate your type. If it's a “template”, the user can insert their type. Also a type that's created long after the original library author has finished their work.

Re: A header-only C implementation of C++ <algorithm>

#14

Post by jb1991 »

physicsguy wrote: post #6
tw1984 wrote: post #4

I feel sick everything time when I see C++ related stuff, simple & fun programming got so complicated just because some big name "committee members" who insist to spend 30 years to standardize networking/filesystem/reflection refuse to simplify their craps. yes, they haven't got that completed yet. I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking?

You can always just use Boost. I don't think I've ever worked on a C++ project that didn't use it! std::filesystem = boost::filesystem - 1.30.0, 2003 std::optional = boost::optional - 1.30.0, 2003

Keep in mind that when boost features are eventually adopted into the C++ standard library, it is often only after their implementation has been strictly defined in ways that diverge from the boost implementations, which are often inefficient. Boost contains a lot of full-featured but inefficient code; for example, some Boost tools allow for arbitrary memory allocation which is often undesirable and their standard library versions do not allow for it. There are other design issues as well, such as how to consistently handle exceptions in edge cases, etc. Boost versions of some of these don't as comprehensively consider those situations.

Re: A header-only C implementation of C++ <algorithm>

#15

Post by iamyemeth »

I'm always a fan of 80% solutions implemented in C. I think the library is pretty nice, and as someone who's experimented with trying to add quality of life features to C99 with macros I think the implementation is actually pretty clean and readable as far as these kind of implementations go.

That being said, I think the ergonomics of the approach taken by Sean Barrett in stb_ds is much nicer than the #define ALG_TYPE, #define ALG_PREFIX approach, although I'm sure it wouldn't be a big stretch to make something similar that was compatible with it.

My feeling is that you could get pretty far with something like Sean Barrett's stb_ds + Salvatore Sanfilippo's sds and then a generic algorithm library like this one

Re: A header-only C implementation of C++ <algorithm>

#18

Post by kzrdude »

iamyemeth wrote: post #15

I'm always a fan of 80% solutions implemented in C. I think the library is pretty nice, and as someone who's experimented with trying to add quality of life features to C99 with macros I think the implementation is actually pretty clean and readable as far as these kind of implementations go. That being said, I think the ergonomics of the approach taken by Sean Barrett in stb_ds is much nicer than the #define ALG_TYP…

I think the difference is that stb_ds is a datastructures library and this is for algorithms. This algorithm library will also look like a completely regular C library if you just use separate .h and .c files to instantiate declarations and the implementation, I think it's very clean.

Re: A header-only C implementation of C++ <algorithm>

#19

Post by cornel_io »

lelanthran wrote: post #5
tw1984 wrote: post #4

I feel sick everything time when I see C++ related stuff, simple & fun programming got so complicated just because some big name "committee members" who insist to spend 30 years to standardize networking/filesystem/reflection refuse to simplify their craps. yes, they haven't got that completed yet. I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking?

> I guess we can wait another 30 years and there will be a C implementation of the C++ reflection or networking? You don't really need to wait if you're willing to use Objective C with the GnuStep framework. You'll get reflection, and a lot of other nice addons[1]. [1] Dunno about network support; ISTR it being part of the GnuStep framework, but could be wrong.

"Stop trying to make 'Objective C' happen"

...is what all non-Apple programmers have been begging ever since the iPhone came out.

Re: A header-only C implementation of C++ <algorithm>

#20

Post by lelanthran »

lionkor wrote: post #10

Isn't this a use-case for _Generic[1]? [1]: https://en.cppreference.com/w/c/language/generic

_Generic is a little bit broken[1].

It's a lot like some of the other decisions by the standards committee; they see demand for a particular feature $FOO, then add in support for something not quite like $FOO, which maybe addresses part of what was wanted but turns out useless in practice so that few use it.

They added `const` (which, admittedly, does get a lot of use in practice) which is subtly different from what already existed in C++ at the time.

They added VLAs, then had to walk that back because, like `gets()`, there was no practical way to use it safely.

The added _Generic, which requires the typenames to be known in advance.

They added threads, but without wide enough functionality to use it for anything but the most trivial of programs.

All in all, they've been doing a poor job of steering the language in the last 20-odd years since C99. What users have been clamouring for was "less UB, please? Make it IB where you can", but instead they have been adding UB.

In the words of Linus Torvalds: "Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster."

Original K&R C had no reference to undefined behaviour. The worst you could say about C at that point in time was that some things were defined by the implementation.

[1] Some might say more than a little bit :-/ You can't use it to write type-safe generic libraries.

Post reply on HN