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

Common libraries and data structures for C

github.com

Post reply on HN
Print view View original

111–120 of 148 posts

Re: Common libraries and data structures for C

#111

Post by jcelerier »

lelanthran wrote: post #66
jcelerier wrote: post #56

Earlier quoted context omitted.

Arduino is entirely C++ though

> Arduino is entirely C++ though No, it's C++ without exceptions (so constructors are useless). On Arduino you will almost certainly program in a C-with-classes manner; lack of exceptions make almost everything that C++ brings to the table useless[1].

> lack of exceptions make almost everything that C++ brings to the table useless[1].

sorry what ? constexpr (https://github.com/arduino-libraries/Arduino_EdgeControl/blo...), templates (https://github.com/arduino-libraries/Temboo/blob/dcce3007eb5...), etc. are all widely used in the Arduino community. I've recently done some work involving C++20 coroutines on an RP2040. etc etc...

And even without exceptions, RAII can still help ensuring a large amount of invariants automatically.

Re: Common libraries and data structures for C

#112

Post by danielEM »

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()…

I see just one GH issue and it is none of yours above, why?

As for someone claiming so much appreciation for C it seem like your love is a bit toxic ;-) (no offense here).

Re: Common libraries and data structures for C

#113

Post by lelanthran »

unwind wrote: post #89
antirez wrote: post #82

Earlier quoted context omitted.

The macro does not look (necessarily) as a bug, it simply does a counter intuitive thing of zeroing everything, including the capacity. Maybe the way it is used, the capacity is saved, then the array cleared, then it is set back; or more likely it is used only after the allocation of the object, when everything requires to be zeroed (but if this is the case it should be called "_init" and not "_clear", for clarity).…

If the way it is used requires the user to break the abstraction/encapsulation and manually buffer some fields in order not to break the data structure and leak memory, I would call that a bug. There is one use of sc_array_clear() in the test code [1] which really makes it look as if it is being used in a way that I think (again, I haven't single-stepped this code, only read it) leaks memory. I agree on the pain of e…

I'm too lazy to look at the code that does the alloc, but if this came my way in a PR I'd ask if the code doing the allocation is using malloc or realloc.

If all allocations are performed using realloc[1] then I have no problem with that macro.

[1] Sometimes it's just easier. Why conditionally call malloc/realloc when you can simply call realloc all the time? Realloc(NULL, size) is equivalent to malloc(size).

Re: Common libraries and data structures for C

#114

Post by lelanthran »

xigoi wrote: post #51
cowtools wrote: post #42

Earlier quoted context omitted.

>Go and Rust are similar in that aspect. I think this poses a subtle security risk about namespacing. Who authorizes these packages? Who audits these repositories? When you use a C/C++ library, there is obvious accountability. You know who maintains the repository (usually your distribution) or you explicitly copy someone elses code as a subrepository.

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.

Re: Common libraries and data structures for C

#115

Post by pjmlp »

scoutt wrote: post #110
pjmlp wrote: post #96

Earlier quoted context omitted.

The same subsets are available in C++ as well, with stronger type checking and RAII for closing those handles. Yeah, safety and IoT unfortunately aren't something that go together. Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming. The same reason you give for using macros.

> RAII C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool . Now every function entry has: if (!m_bValid) return; I hate it. > Yeah, safety and IoT unfortunately aren't something that go together. Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priori…

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

Re: Common libraries and data structures for C

#116

Post by scoutt »

pjmlp wrote: post #115
scoutt wrote: post #110

Earlier quoted context omitted.

> RAII C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool . Now every function entry has: if (!m_bValid) return; I hate it. > Yeah, safety and IoT unfortunately aren't something that go together. Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priori…

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 :)

Re: Common libraries and data structures for C

#117

Post by cozzyd »

NavinF wrote: post #73
cozzyd wrote: post #35

Earlier quoted context omitted.

When working on some platforms (e.g. BeagleBoneBlack), the compilation time of C++ is a huge turnoff. Sure, you can cross-compile, but that feels like even more friction.

Wait you ssh into a BeagleBoneBlack and compile C on the device? I’ve seen some janky envs in my life but this is pretty high up. Do you never enable LTO when linking deps? These devices are literally 1000x slower than a typical 8 core desktop.

Yes, and edit/debug code in the device too. Setting up an identical cross compilation environment with all the same shared libraries (it's a full Linux system after all) and such is non-trivial and C compiles fast enough it's fine... (1000 times is a bit of an exaggeration anyway...)

Now maybe if I were an emacs user this setup wouldn't work...

Re: Common libraries and data structures for C

#118

Post by cestith »

metadat wrote: post #10
glouwbug wrote: post #7

Good stuff. void* in itself is great for generics. C does support a templating system, like C++, with a little (reasonable) preprocessor abuse. It gives great cache contiguous results: https://www.github.com/glouw/ctl

Probably best to disclose you're pitching your own baby to us. What do you feel this content adds in context of the article? I can't tell.

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

Re: Common libraries and data structures for C

#119

Post by huhtenberg »

einpoklum wrote: post #105
huhtenberg wrote: post #80

Earlier quoted context omitted.

That's the thing with C and C++. C is light and simple, but don't use it much, because it can get too verbose. C++ allows for succinct code, but it's neither light or simple. Nor does it have any concern for the elegance of its design. Hence the common practice of using a small subset C++ and pretending it's just C with Extras.

> Nor does it have any concern for the elegance of its design. It has a lot of inelegant facilities, which, when used under the hood, allow you to express your elegant abstractions. > Hence the common practice of using a small subset C++ and pretending it's just C with Extras. That's mostly failure to use C++. Since C++11, and especially with later updates to the standard, idiomatic C++ is very different from C - eve…

> That's mostly failure to use C++.

How is it a failure when people just find idiomatic C++ undesirable, exactly because it's very different from C.

Basically, the best C++ feature by a very long mile is that it can in fact be used as an extension of C. That's what made it popular in the first place and that's still "what people want".

If it's a failure, then it's that of the C++ committee evolving the language in an echo chamber.

Post reply on HN