Common libraries and data structures for C • Hacker News Board

Re: Common libraries and data structures for C

#141

Post by bsder » Tue, May 17, 2022, 11:05 PM UTC

cozzyd wrote: post #140

bsder wrote: post #139

Earlier quoted context omitted.

> Wait you ssh into a BeagleBoneBlack and compile C on the device? Exactly how am I supposed to access the hardware that only exists on the Beaglebone Black itself, otherwise? You can cross-compile all day, but, in the end, I need to code to be running over there to toggle those GPIOs. I need the debugging to be over there . I need VSCode to be running over there . Not all programming is web programming.

I mean, theoretically it's possible to set up a cross-compilation environment (which would require mirroring basically the entire /usr of the BBB) and copy over compiled files for running / debugging. But it's only worth it if compiling takes a long time (or I suppose if you were to use templaty C++ or rust or something, you may not have enough memory on the BBB to actually compile things... but maybe don't do that?)…

rust actually does okay on the BBB unless you activate heavy macros at which point the memory blows up, and it grinds to a halt.

rust-analyzer, for example, could be built (slowly) on the BBB until recently. The last refactoring of it ... ooof ... did something to macros and now the memory footprint is gargantuan.

Re: Common libraries and data structures for C

#142

Post by somerando7 » Wed, May 18, 2022, 1:30 AM UTC

lelanthran wrote: post #68

somerando7 wrote: post #21

The lengths people will go to not use C++ is staggering.

> The lengths people will go to not use C++ is staggering. Every C thread on every forum always has some C++ proponent jumping in to bemoan that people prefer one of the simplest languages over, literally, the most complex (from a programmer PoV) language in existence. Is it really such a stretch to believe that people prefer readability and maintainability over expressive power? The "lengths" in this case is small -…

Every single time there are some people who love C (in my experience for the reason they haven't worked professionally in C++) that claim that they're actually WAY more productive and readable when working in C.

C++ is basically almost a perfect super-set of C. Use the parts of C++ that are useful to you, don't use the parts that aren't. Clearly std::vector, std::string, std::unordered_map would be ultra useful to anyone. Especially because they are easier to use, more optimized, not as prone to errors as their C equivalents.

I blame Jonathan Blow and Muratori for this. They somehow got the entire gamedev community to worship the idea of writing things in C. People grow out of it really fast though, as soon as they actually learn C++.

Re: Common libraries and data structures for C

#143

Post by pjmlp » Wed, May 18, 2022, 7:03 AM UTC

scoutt wrote: post #116

pjmlp wrote: post #115

Earlier quoted context omitted.

In the history of C++, RAII predates exceptions by several years. When I got introduced to C++, via Turbo C++ 1.0 for MS-DOS in 1993, I decided that there was hardly a reason to use C other than being forced to use it by external reasons. Thankfully there are plenty of places that have moved beyond running on C. :)

> beyond running on C Can we agree that for at least the past 25 years, 99% of devices runs on C and/or depends on C and/or relies on C, or its development ran/relied/depended on C? From Windows/MacOS/Linux kernels up to the FW in your mouse, keyboard, monitor and HDD controllers. It's difficult to escape C :)

Using C compilers written in C++, yeah really difficult to escape C.

Windows has been migrating into C++ since Windows Vista, when VC++ introduced kernel support. Its C universal runtime is written in C++ with extern "C" entry points. Ah and then there is COM/WinRT, also mostly about C++ and .NET, even if the ABI is compatible with C (for masochists).

macOS uses C++ for drivers, a kernel without drivers isn't of much use.

Speaking of which, in Android all drivers written using Project Treble (required as of Android 8) are either C++ or Java based, and now Rust is also into the picture. The only C is the "classical" Linux upstream stuff.

Re: Common libraries and data structures for C

#144

Post by quickthrower2 » Wed, May 18, 2022, 8:42 AM UTC

glouwbug wrote: post #131

cestith wrote: post #118

Earlier quoted context omitted.

I thought "glouw" in the username here and in the username in the link was pretty obvious myself.

I mean, it’s not like I’m plugging retail source ;)

Yeah like I’m not gonna complain to my ad blocker :-)

Re: Common libraries and data structures for C

#145

Post by kazinator » Wed, May 18, 2022, 7:12 PM UTC

My old kazlib has the basics: hashing, red-black-tree, lists, exception handling.

https://www.kylheku.com/~kaz/kazlib.html

Used in e2fsck, Ethereal and others.

There is even C++ support hidden in there: the dict.h contains a C++ template wrapper (which keeps the container intrusive).

Re: Common libraries and data structures for C

#146

Post by l-albertovich » Thu, May 19, 2022, 2:16 PM UTC

unwind wrote: post #77

Okay, I love C so of course I had to take a look. The buzzwords are impressive, with all the testing and CI and so on, really nice, modern and ambitious. I dove into the code, literally looking at the first true part of the implementation in array/sc_array.h. Two observations, from probably less than tree minutes of reading: 1. The nomenclature with "sc_array_term()" as the destructor (the opposite of sc_array_init()…

Glanced over it, it doesn't look like a bug, just wasteful.

The way I see it, because sc_array_clear resets cap and size to zero, the next call to sc_array_add will issue a realloc call to the default minimum size (8) and it won't leak because sc_array_clear doesn't overwrite elems.

So yeah, not cool but doesn't look like a bug either.

Re: Common libraries and data structures for C

#147

Post by xigoi » Fri, May 20, 2022, 10:53 AM UTC

lelanthran wrote: post #114

xigoi wrote: post #51

Earlier quoted context omitted.

If you trust the compiler, why wouldn't you trust the standard library? They're usually made by the same people.

> If you trust the compiler, why wouldn't you trust the standard library? They're usually made by the same people. That sounds like a different way of saying "they're sometimes made by different people", which is why you won't trust it.

By different people that have been approved by the compiler developers.

Re: Common libraries and data structures for C

#148

Post by OskarS » Sat, May 21, 2022, 12:23 PM UTC

scoutt wrote: post #138

OskarS wrote: post #133

Earlier quoted context omitted.

It's that amount of lines UNCOMPILED. Of course uncompiled code wouldn't fit in 64kb of flash (the compiler wouldn't fit either, you know). Compiled, std::optional takes up essentially no overhead, basically the same as if you're returning a single bool along with your object. > This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?…

Just chill, OskarS. I know the difference between compiled code and source code. Regarding std::optional , I even admitted " I don't know the overhead of possibly duplicating...". 30KB was a ballpark about exceptions plus std in general, by including things you expect to use when using std (like std::string ). The patterns I knew and saw with std::optional usually returned "new something" , but yeah, you can return a…

> The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.

Oh, fer crying out loud... It DOES NOT return a copy, it constructs it directly in place. This is called "copy elision" (also known as "return value optimization", or RVO), and has been done by compilers for three decades, and is actually mandated behaviour in modern C++. I don't know where you saw these examples, but you would never use operator new with std::optional: it takes a value, not a pointer.

You have a very annoying style of being wrong about absolutely everything you say, and then acting superior about it when people call you on your bullshit.