I don't understand why so many functions are implemented as macros when C99 has the inline keyword.
Common libraries and data structures for C
101–110 of 148 posts
Re: Common libraries and data structures for C
#102Why not use GObject?
GObject's object model is insanely overcomplicated. It's more or less an implementation of C++ in C. It's overkill if you just want resizable arrays, hash tables, and maybe some trees.
Re: Common libraries and data structures for C
#103The 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 -…
Yeah, having to define all vector functions as macros is definitely the epitome of readability and maintainability.
Re: Common libraries and data structures for C
#104Earlier quoted context omitted.
> 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 -…
Yeah, having to define all vector functions as macros is definitely the epitome of readability and maintainability.
In this specific case I think we have to agree with your point. When code have to go all-.h, it’s already reasonable to go [a subset of] C++.
Re: Common libraries and data structures for C
#105I work in C++ daily and there is something about the simple-ness of C that I love. You get out of magical hell that is templates and return to simple flat-functions and macros.
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 - even if you're not using a lot of the standard library. I'll link to a talk already linked-to in another comment in this discussion:
Rich code for tiny computers / Jason Turner, CppCon 2016 https://www.youtube.com/watch?v=zBkNBP00wJE
Re: Common libraries and data structures for C
#106Why not use GObject?
GObject's object model is insanely overcomplicated. It's more or less an implementation of C++ in C. It's overkill if you just want resizable arrays, hash tables, and maybe some trees.
I think gp confused gobject with glib. Glib has no object model, it’s a collection of functions and data structures, including “managed” strings. Just a better version of libc, if you don’t mind the size.
Re: Common libraries and data structures for C
#107No post body was provided.
Re: Common libraries and data structures for C
#108There's the Clib initiative at https://github.com/clibs . I don't know how much they curate/review their entries. As often said, apt install foo is also a bit of a package manager for C. Maybe we should establish a sort of expert-led central archive of rock-solid, battle-tested C libs/functions/snippets that one can trust ?
Maybe we should establish a sort of expert-led central archive of rock-solid, battle-tested C libs/functions/snippets that one can trust ? GNUlib [1], albeit marketed as a "portability library", in fact shares a lot of that goal and includes data structure implementation, OS interfaces, etc. A couple of excerpts from the docs: * "Gnulib is intended to be the canonical source for most of the important “portability” an…
Well.. that'll do it ! I wonder how I never stumbled upon that massive trove.
Re: Common libraries and data structures for C
#109Earlier 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++.
Isn't this the no true Scotsman fallacy? It looks like you're agreeing with the parent poster that a lot of people use a small subset of C++ to pretend that it's C with extras. If this is true, it's not a failure of all these people because they don't _really_ understand C++. It's a failure of the language designers because they have made something that nobody can agree on how to use.
Re: Common libraries and data structures for C
#110Earlier quoted context omitted.
> You cannot also use stdio and most stdlib, so what? You can still use a subset of stdio and stdlib. Newlib also provides hooks you can use to implement fopen and the like, if you want. > better safety options Safety is not always the utmost priority. At least, not that kind of safety. It seems people forget this concept from time to time. > templates instead of undebuggable macros This is if you use complex macros,…
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;
> 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 priority.
> Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming.
So we agree. But I think you should be considering the possibility that there might be something going on between you and C, and that it could be possible that not every C developer out there is out of their mind (considering the quantity of past, present and future C projects).
Make peace with C, because the world runs on C and we'll be long gone by the time C will be replaced by something else :)