A header-only C implementation of C++ • Hacker News Board

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

#21

Post by iamyemeth » Tue, Jul 04, 2023, 8:35 AM UTC

kzrdude wrote: post #18

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.

I meant more from the perspective that stb_ds achieves type safe generics in C using macros but without using defines.

It would be interesting to see if something similar could be achieved for an algorithm library.

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

#22

Post by tw1984 » Tue, Jul 04, 2023, 8:51 AM UTC

PhilipRoman wrote: post #7

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?

God I wish everything was done in this way. Even the C standards committee moves too fast and adds features that have no place in the standard.

Well, there are people who choose to stay away from social and technical progress. I totally respect that desire.

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

#23

Post by kzrdude » Tue, Jul 04, 2023, 9:42 AM UTC

iamyemeth wrote: post #21

kzrdude wrote: post #18

Earlier quoted context omitted.

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.

I meant more from the perspective that stb_ds achieves type safe generics in C using macros but without using defines. It would be interesting to see if something similar could be achieved for an algorithm library.

It would be interesting but I prefer the approach in this post - because the templating macros are isolated out into a "module" and it does not great spread across the user code.

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

#24

Post by wsc981 » Tue, Jul 04, 2023, 9:56 AM UTC

cornel_io wrote: post #19

lelanthran wrote: post #5

Earlier quoted context omitted.

> 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.

I thought (and still think) Objective-C is quite nice. Kinda hoping my employer wants to port (wrap) it’s C++ based library to Objective-C (and Swift) in the coming year. I’d be the primary guy doing the work and I’d enjoy it :)

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

#25

Post by lelanthran » Tue, Jul 04, 2023, 9:57 AM UTC

cornel_io wrote: post #19

lelanthran wrote: post #5

Earlier quoted context omitted.

> 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.

FWIW, I'm a non-Apple developer: never wrote a single line of code for any Apple device for production. Ported some of my libraries over to Mac OS about a decade back, but that was it.

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

#26

Post by physicsguy » Tue, Jul 04, 2023, 10:03 AM UTC

jb1991 wrote: post #14

physicsguy wrote: post #6

Earlier quoted context omitted.

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 li…

Of course, but aside from standardisation defined details, it also depends on your compiler's standard library implementation, and those are not all made equal, especially if you've got to build something both for Windows and Linux.

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

#27

Post by planede » Tue, Jul 04, 2023, 10:18 AM UTC

lelanthran wrote: post #20

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…

> Original K&R C had no reference to undefined behaviour.

You don't have to explicitly refer to undefined behavior to have it. If you just merely omit defining the behavior of certain programs then that's enough.

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

#28

Post by lelanthran » Tue, Jul 04, 2023, 10:31 AM UTC

planede wrote: post #27

lelanthran wrote: post #20

Earlier quoted context omitted.

_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…

> Original K&R C had no reference to undefined behaviour. You don't have to explicitly refer to undefined behavior to have it. If you just merely omit defining the behavior of certain programs then that's enough.

> You don't have to explicitly refer to undefined behavior to have it. If you just merely omit defining the behavior of certain programs then that's enough.

I respectfully disagree. It can be implementation defined, as in all other languages.

In fact, when I started with C, I did not use a C89 one, if we weren't certain what a certain construct did, we;d try it on a compiler and use the result as a definition for what that construct did on that compiler!

On another compiler it might do something else, but that didn't bother us until it was time to port the code to another compiler.

With undefined behaviour being added, that no longer holds: you try something out, get a particular result, but the next time you compile that construct you could get a completely different result.

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

#29

Post by aifusenno1 » Tue, Jul 04, 2023, 10:33 AM UTC

lelanthran wrote: post #3

This looks like a good implementation for common array operations in a type-safe manner. Not a bad approach, but the source (header file) is not very readable (so I guess "just like the STL" applies :-))

I found it fairly straightforward and readable compared to many libraries out there.

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

#30

Post by planede » Tue, Jul 04, 2023, 10:47 AM UTC

lelanthran wrote: post #28

planede wrote: post #27

Earlier quoted context omitted.

> Original K&R C had no reference to undefined behaviour. You don't have to explicitly refer to undefined behavior to have it. If you just merely omit defining the behavior of certain programs then that's enough.

> You don't have to explicitly refer to undefined behavior to have it. If you just merely omit defining the behavior of certain programs then that's enough. I respectfully disagree. It can be implementation defined, as in all other languages. In fact, when I started with C, I did not use a C89 one, if we weren't certain what a certain construct did, we;d try it on a compiler and use the result as a definition for wha…

> In fact, when I started with C, I did not use a C89 one, if we weren't certain what a certain construct did, we'd try it on a compiler and use the result as a definition for what that construct did on that compiler!

This still doesn't mean that the behavior was implementation defined. Implementation defined requires the compiler vendor to document the behavior. However implementers are allowed to define and even document the behavior for operations that the standard leaves undefined. These are called extensions. It's common practice to have some extensions even now, sometimes behind specific compiler flags, or just being documented.

I think it's a mistake to infer the compiler's behavior through trying a few examples, even for simple compilers. If you want to have guarantees for the behavior for otherwise undefined constructs then get it in writing from the compiler vendors. Even if you check the source code, the behavior might change in a future version.