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

81–90 of 148 posts

Re: Common libraries and data structures for C

#81

Post by jandrewrogers »

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

It is remarkable how many large and modern C++ code bases somehow make thorough use of the language, including constructors, without exceptions. Unless the asserted need for exceptions is a gross mischaracterization.

Re: Common libraries and data structures for C

#82

Post by antirez »

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

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). Does not look as the most sounding interface of course. Also this is the kind of thing that should not be done as macro regardless of speed... and only turned into a macro in case of very aggressive profiler-drive optimization.

Re: Common libraries and data structures for C

#83

Post by rkagerer »

DeathArrow wrote: post #37

What I find frustrating when I use C instead of C# is that I have to hunt for libraries and include them in the project or write my own implementation, even for most popular things like data structures, search algorithms, sorting algorithms, serialization, http calls. Whereas in C# the framework will provide them for me. If something is not in the standard library, I can use a directive or just reference a method fro…

...the IDE will help to install the package

I wish I could love that feature, but I hate it. I don't like the way it obscures what's going on under the hood (I find myself taking snapshots and trying to figure out "what's changed" or reverse engineer the installer metadata), and many projects use it as a crutch instead of providing a simple drop-in file (or a few). So many projects don't even include a simple "download" button anymore.

Re: Common libraries and data structures for C

#84

Post by Tozen »

lelanthran wrote: post #64
pjmlp wrote: post #54

Earlier quoted context omitted.

Unless we are talking about something like Z80, 6502, PIC, AVR and similar low end CPUs, which hardly full support even C89, all modern CPUs have C++ compilers available. More often than not, it is a matter of not wanting to use C++ than it not being available.

> More often than not, it is a matter of not wanting to use C++ than it not being available. That's perfectly valid. I reach for C when I need to write fairly small programs. When C does not fill my needs anymore, I don't reach for C++. There are better high-level languages. C++ is not a replacement for C. When one of the worlds foremost experts on C++ complains that the language is too complex to understand[1], pass…

I agree with you. I'm a bit tired of C++ being imposed on those that rather just use C or as if C users can't turn to any other options besides C++. To include that C interop has become a thing for many newer programming languages now.

By the way, the D language (which has been with us for a while) has long positioned itself as a viable alternative to C++.

Re: Common libraries and data structures for C

#85

Post by j1elo »

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

> 1. The nomenclature with "sc_array_term()" as the destructor (the opposite of sc_array_init()) was new to me; I'm not saying that's a real problem but it's at least adding friction in a way.

I think there shouldn't be any need to innovate in the naming of these kinds of functions... GLib got it perfectly right [0] with the pair init / finalize. One might like the alternative init / deinit if the goal is to have some symmetry in the naming... but there are not many better choices.

free is to be used (always IMHO) typically as the opposite of new, make, or create.

"Naming things is difficult" and all that...

[0]: https://docs.gtk.org/gobject/concepts.html

Re: Common libraries and data structures for C

#86

Post by saagarjha »

DeathArrow wrote: post #46
optymizer wrote: post #32

Earlier quoted context omitted.

What do you mean by 'time drain'? Do you know how much time it would take you to port your assembly code from x86 to ARM? And then when a new CPU comes out, you've got to rewrite all that assembly code again. Now that's a time drain. You could write your code once in C, and compile it for any CPU at this point. That's massive amount of your time saved. Again, what do you mean by 'time drain'? Do you know how many hum…

>C exists to write fast programs, not to write programs fast. What if you want to write fast programs fast? Also, while not useful for command line tools or for small run once programs, if the software is running continuously or its size is past a certain threshold, it might pay off to use .NET or Java since the speed is not that far of from C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://b…

Most programs are not benchmarks.

Re: Common libraries and data structures for C

#87

Post by pjmlp »

scoutt wrote: post #74
pjmlp wrote: post #54

Earlier quoted context omitted.

Unless we are talking about something like Z80, 6502, PIC, AVR and similar low end CPUs, which hardly full support even C89, all modern CPUs have C++ compilers available. More often than not, it is a matter of not wanting to use C++ than it not being available.

On most embedded systems you cannot include std . You don't have a decent memory allocator. Bad use of templates will consume all of your flash space (code duplication). Yes, it can work for simple Arduino sketches, and I won't say that there are not complex embedded projects in C++. But... why should I want to use C++? For one, I use a small subset, like it's C with classes. I like function overloading and default a…

You cannot also use stdio and most stdlib, so what?

You would want to use C++ for stronger type safety, proper enumerations, templates instead of undebuggable macros, namespaces,....

https://news.ycombinator.com/item?id=31406942

"CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”"

https://www.youtube.com/watch?v=zBkNBP00wJE

MCUs also don't support full-blown C, and it isn't a show stopper to keep advocating it, so why should it be for a language with better safety options, even with constraints.

Re: Common libraries and data structures for C

#88

Post by saagarjha »

sylware wrote: post #22
hypeatei wrote: post #13

I'm not a C developer, nor have I ever been interested in developing with it. From my perspective, it seems like a massive time drain and non-productive use of my time. Just a few points: - Tooling seems all over the place (build system, package management) - Having to roll your own trivial functions / types (tooling may play into this) - Versioning is confusing (C99, C11, ???) The only advantage I see would be in em…

C is supposely a language which it is reasonable to write a compiler for and in order to get a reasonable hardware ISA abstraction. Don't worry, the ISO working groups are making sure that it won't last and soon writting a C compiler will become a nightmare like what they did for c++ (C23 is seriously scary). Instead they should fix it: remove _Generic, typeof, etc which have nothing to do there, and make sure writti…

> Instead they should fix it: remove _Generic, typeof, etc which have nothing to do there, and make sure writting a C compiler does keep requiring only a reasonable amount of developement efforts (not an army of devs for 20 years like c++).

Have you ever written a C compiler? These things are not difficult to support. You sound more interested in just removing things that are "new" that you don't really like than genuinely concerned about things that are complex to implement, like passing structs around while keeping the platform ABI in mind, and handling the intricacies of bitfields.

Re: Common libraries and data structures for C

#89

Post by unwind »

antirez wrote: post #82
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()…

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 everything being macros, it's more pain than it's worth I think and will likely lead to code duplication (and more pain in debugging, probably).

I would even go so far as to think that this kind of single-file design, where each file is independent of the others, makes it harder and more annoying to implement more complicated data structures.

[1]: https://github.com/tezc/sc/blob/master/array/array_test.c#L3...

Re: Common libraries and data structures for C

#90

Post by zambal »

slabity wrote: post #11
sbf501 wrote: post #4

Earlier quoted context omitted.

I think writing your own portable C functions is something every programmer wants to own at some point in their young career. Then you grow up and realize there are entire organizations that have spend tens of thousands of man-hours providing the same code, but done correctly and with intent (and consistent philosophy). GObject is that philosophy, but lots of people never hear about it until someone says "Why not use…

This is completely anecdotal, but when I was looking for something like this ~10 years ago (and was just beginning to learn about the wider Linux ecosystem outside of libc), I stumbled upon GObject and completely ignored it because of its association with GNOME. My initial thoughts was that GObject was only really useful if you were building things for the GNOME ecosystem and wrote it off completely. I also did the s…

Your comment could have been mine. Many years ago, I found GObject interesting, but was afraid using it would lead to friction when used outside GNOME's ecosystem.
Post reply on HN