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

Some C habits I employ for the modern day

unix.dog

Post reply on HN
Print view View original

101–110 of 162 posts

Re: Some C habits I employ for the modern day

#101

Post by flohofwoe »

lionkor wrote: post #88
lelanthran wrote: post #74

Earlier quoted context omitted.

> When you strlen() a UTF8 string, you don't get the length of the string, but instead the size in bytes. Yes, and? > What am I missing? A use-case? Where, in your C code, is it reasonable to get the number of multibyte characters instead of the number of bytes in the string? What are you going to use "number of unicode codepoints" for? Any usage that amounts to "I need the number of unicode codepoints in this string…

For example splitting, cutting and inserting strings into each other

That works just fine on UTF-8 encoded strings with C stdlib functions if your delimiters are 7-bit ASCII characters (/,.:; etc...).

Re: Some C habits I employ for the modern day

#102

Post by publicdebates »

WalterBright wrote: post #34
publicdebates wrote: post #28

Earlier quoted context omitted.

It might be the language he is looking for, but it might not, and more likely than not is not. D is one of those odd languages which most likely ought to have gotten a lot more popular than it did, but for one reason or another, never quite caught on. Perhaps one reason is because it lacks a sense of eccentricity and novelty that other languages in its weight class have. Or perhaps it's just too unfamiliar in all the…

D is an elegant re-imagine of C and C++. For a trivial example, typedef struct S { int a; } S; becomes simply: struct S { int a; } and unlike C: extern int foo(); int bar() { return foo(); } int foo() { return 6; } you have: int bar() { return foo(); } int foo() { return 6; } For more complex things: #include becomes: import foo;

Smoe of these are definitely nice-to-haves*, but when you're evaluating a C++ alternative, there are higher priority features to research first.

How are the build times? What does its package system(s) look like, and how populated are they? What are all its memory management options? How does it do error handling and what does that look like in real world code? Does it have any memory safety features, and what are their devtime/comptime/runtime costs? Does it let me participate in compile time optimizations or computations?

Don't get me wrong, we're on the same page about wanting to find a language that fills the C++ niche, even if it will never be as ideal as C++ in some areas (since C++ is significantly worse in other areas, so it's a fair trade off). But just like dating, I'm imagining the fights I'll have with the compiler 3 months into a full time project, not the benefits I'll get in the first 3 days.

* (a) I've been using structs without typedef without issue lately, which has its own benefits such as clarifying whether the type is simple or aggregate in param lists, while auto removes the noise in function bodies. (b) Not needing forward declarations is convenient, but afaik it can't not increase compile times at least somewhat. (c) I like the consistency here, but that's merely a principle; I don't see any practical benefit.

Re: Some C habits I employ for the modern day

#103

Post by flohofwoe »

wavemode wrote: post #37
apaprocki wrote: post #32

Earlier quoted context omitted.

> > typedef struct { ... } String > I avoid doing this. Just use `struct string { ... };'. It makes it clear what you're handling. Well then imagine if Gtk made you write `struct GtkLabel`, etc. and you saw hundreds of `struct` on the screen taking up space in heavy UI code. Sometimes abstractions are worthwhile.

The main thing I dislike about typedefs is that you can't forward declare them. If I know for sure I'm never going to need to do that then OK.

The usual solution for this is:

    typedef struct bla_s { ... } bla_t;
Now you have a struct named 'bla_s' and a type alias 'bla_t'. For the forward declaration you'd use 'bla_s'.

Using the same name also works just fine, since structs and type aliases live in different namespaces:

    typedef struct bla_t { ... } bla_t;
...also before that topic comes up again: the _t postfix is not reserved in the C standard :)

Re: Some C habits I employ for the modern day

#105

Post by raincole »

lelanthran wrote: post #95
raincole wrote: post #91

Earlier quoted context omitted.

> I think, when you are building a system, restricting all (human language) input to be UTF-8 is a fair and reasonable design decision, and then you can use strlen to your hearts content. It makes no sense. If you only need the byte count then you can use strlen no matter what the encoding is. If you need any other kind of counting then you don't use strlen no matter what the encoding is (except in ASCII only environ…

> If you only need the byte count then even you can use strlen no matter what the encoding is. No, strlen won't give you the byte count on UTF16 encodings. > If you need character count then you don't use strlen no matter what the encoding is (except in ASCII only environment). What use-case requires the character count without also requiring a unicode glyph library?

> strlen won't give you the byte count on UTF16 encodings.

You're right. I stand corrected.

Re: Some C habits I employ for the modern day

#106

Post by publicdebates »

tom_ wrote: post #17

If you really insist on not having a distinction between "u8"/"i8" and "unsigned char"/"signed char", and you've gone to the trouble of refusing to accept CHAR_BIT!=8, I'm pretty sure it'd be safer to typedef unsigned char u8 and typedef signed char i8. uint8_t/int8_t are not necessarily character types (see 6.2.5.20 and 7.22.1.1) and there are ramifications (see, e.g., 6.2.6.1, 6.3.2.3, 6.5.1).

Could you clarify an example of the ramifications?

I tried looking through the C2Y standard draft to figure it out, but it's too complicated for me.

Re: Some C habits I employ for the modern day

#107

Post by bArray »

> I don’t personally do things that require dynamic memory management in C often, so I don’t have many practices for it. I know that wellons & co. Have been really liking the arena, and I’d probably like it too if I actually used the heap often. But I don’t, so I have nothing to say.

> If I find myself needing a bunch of dynamic memory allocations and lifetime management, I will simply start using another language–usually rust or C#.

I'm not sure what the modern standards are, but if you are writing in C, pre-allocate as much as possible. Any kind of garbage collection is just extra processing time and ideally you don't want to run out of memory during an allocation mid-execution.

People may frown at C, but nothing beats getting your inner loops into CPU cache. If you can avoid extra fetches into RAM, you can really crank some processing power. Example projects have included computer vision, servers a custom neural network - all of which had no business being so fast.

Re: Some C habits I employ for the modern day

#109

Post by glouwbug »

canpan wrote: post #6

Regarding memory, I recently changed to try to not use dynamic memory, or if I need to, to do it once at startup. Often static memory on startup is sufficient. Instead use the stack much more and have a limit on how much data the program can handle fixed on startup. It adds the need to think what happens if your system runs out of memory. Like OP said, it's not a solution for all types of programs. But it makes for v…

Dynamic memory allocation solves the problem of dynamic business requirements.

If you know your requirements up front, static memory initialisation is the way.

For instance, indexing a typed array with an enum is no different then an unordered map of string to int, IF you have all your business requirements up front

Re: Some C habits I employ for the modern day

#110

Post by convolvatron »

adrianN wrote: post #42
convolvatron wrote: post #13

Earlier quoted context omitted.

you can certainly wrap the array with a structure which provides either bounds information to be checked with generic runtime functions, or specific function pointers (methods) to get and set. you can paper over _alot_ of Cs faults. ultimately its not really worth it, but its not nearly as fragile and arduous as you make it out to be

You can do such things until you have to interface with other code, eg the operating system.

So that’s an interesting case. I’d really like to keep language neutrality, because I don’t think we’re finished evolving yet. So this is a place where we need an abi. The first things we try to do is be simple…except for a terrible mistake with select, we don’t send arrays across that interface, sadly, we send c structs sometimes and I think that’s pretty horrible, because we have to try to lay them out in a compatible way, which is pretty fragile. The other sad bit is that we need to verify the addresses before we can operate on them, and that’s hugely prone to error.

Im curious if you have a suggestion about how to fix both of those. The structure thing can clearly be a more robust serialization. Addresses? Idk

Post reply on HN