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

71–80 of 148 posts

Re: Common libraries and data structures for C

#71

Post by pjmlp »

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…

Same critic can be applied to any language of the same age as C++.

Try to do a pub quizz about a begginiers friendly language like Ruby or Python, that spans over all their versions.

Re: Common libraries and data structures for C

#72

Post by lifthrasiir »

ludocode wrote: post #49
lifthrasiir wrote: post #29

Earlier quoted context omitted.

I agree C23 is scary (1000+ new functions???), but your complaint seems a bit misplaced. For example `typeof` is a GNU extension, and removing `typedef` will instantly break virtually everything (which is not only used to remove `struct`/`union`/`enum` from the name). And a reasonable C compiler can only do a very limited amount of optimization, which precludes a majority of current C uses.

It looks like typeof() is being added it C23, so his complaint about it sort of makes sense. I say "sort of" because if he's truly concerned about the effort involved in creating independent implementations, then obviously he should be evaluating features by the difficulty involved in implementing them. typedef and typeof are absolutely trivial to implement [0] [1]. typedef just creates type aliases and typeof is ver…

> It looks like typeof() is being added it C23, so his complaint about it sort of makes sense.

To my knowledge typeof was discussed but not adopted to C23, but well, yeah, the proposal is still being updated as of February [1] so it's still on the table. Your argument with chibicc is actually great, though I personally think typeof is too much (in the same reason I think _Generic and is too much: they only solve overly specific problems).

> Also, I'm not sure what 1000 functions you're referring to, [...]

This one was my slight misunderstanding. I should have said 200+ functions, and they mostly come from the updated IEEE 754 standard and additional floating point and decimal types [2]. 1000 was the number of additional reserved identifiers. Still I feel uncomfortable about this sudden explosion in the single global namespace of C.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm

[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2426.pdf#p...

Re: Common libraries and data structures for C

#73

Post by NavinF »

cozzyd wrote: post #35
israrkhan wrote: post #24

For people advocating use of C++ instead of C, keep in mind there are several platforms (mostly embedded) that only support C and not C++. Also there are many projects that make use of C only. If C++ is available, I agree one should use it, however that is not always the choice.

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.

Re: Common libraries and data structures for C

#74

Post by scoutt »

pjmlp wrote: post #54
israrkhan wrote: post #24

For people advocating use of C++ instead of C, keep in mind there are several platforms (mostly embedded) that only support C and not C++. Also there are many projects that make use of C only. If C++ is available, I agree one should use it, however that is not always the choice.

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 argument values, initializing default values for some structs, not having to type typedef struct, the fact that for a time I could declare variables mid-function and using literal bool, true, false, etc.

But full-blown C++ on embedded (MCU)? I think I'll pass.

Re: Common libraries and data structures for C

#75

Post by lelanthran »

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…

> Can you write one file of C code and compile it easily for multiple platforms or is there a lot of caveats?

Target POSIX, and there's very few caveats. You're looking at portability as "how many processors can this run on". Think of it more as "how many places can use my library if I wrote it in C".

You're missing the major upside of writing in C: if you write your library in C, it is callable (with no changes) from Python, Ruby, Java, C++, C#, Lisp ... just about any language, really.

The language is so simple that an automated tool can be used to automatically generate bindings from your language of choice to C. I use Swig. Look into Swig.

You see C as an ancient dinosaur with no use, the reality is that it is usually the only real way to write reusable software[1].

[1] Sure, you can write in C++, but you'd still have to wrap it in C.

Re: Common libraries and data structures for C

#77

Post by unwind »

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()) was new to me; I'm not saying that's a real problem but it's at least adding friction in a way. I would have expected sc_array_free(), but that seems to be internally used as an alias for the standard function free(). Very confusing, since that name (sc_array_free()) then leaks into the source but it has the feeling of being meant for internal use.

2. I wonder if this has a bug:

    /**
     * Deletes items from the array without deallocating underlying memory
     * @param a array
     */
    #define sc_array_clear(a) \
    do {                                                                   \
      (a)->cap = 0;                                                  \
      (a)->size = 0;                                                 \
      (a)->oom = false;                                              \
    } while (0)
In my experience, when you want to clear a dynamic array but keep the allocated memory, the 'capacity' ('cap', here) field should not be cleared. I think this will leak memory if an array is grown, cleared, and then re-filled since the sc_array_add() function will see a zero capacity, and allocate new storage.

Just my inflation-devalued SEK 0.02, and I did not run the code, I just read it very quickly. Corrections welcome.

Re: Common libraries and data structures for C

#78

Post by sydthrowaway »

synergy20 wrote: post #31
bregma wrote: post #8

Earlier quoted context omitted.

GObject, the C++ implementation by a True C Believer.

tried to use it for embedded system in the past, pretty large in size and impossible to use there, it's in fact larger than c++ stdlib and I ended up going straight to c++ instead.

C++ probably put the smarts in the compiler

Re: Common libraries and data structures for C

#79

Post by lelanthran »

xxpor wrote: post #26
sylware wrote: post #22

Earlier quoted context omitted.

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…

Keeping it simple to write a compiler is not a serious use case these days. People aren't bootstrapping new platforms from scratch. GCC and Clang are anything but simple.

> Keeping it simple to write a compiler is not a serious use case these days.

The implication is that if it is simple to write a parser for a language, then the language is simple to read.

Re: Common libraries and data structures for C

#80

Post by huhtenberg »

darknavi wrote: post #28

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

Post reply on HN