Live data from Hacker News

Some C habits I employ for the modern day

unix.dog

81–90 of 162 posts

Re: Some C habits I employ for the modern day

#81

> I’ve long been employing the length+data string struct. If there was one thing I could go back and time to change about the C language, it would be removal of the null-terminated string. It's not necessary to go back in time. I proposed a way to do it in modern C - no existing code would break: https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple, and easy to implement.

Even simpler, you can do something like this to have length-delimited AND null-terminated strings (written from memory, no guarantees of correctness etc.):

    char *lenstrdup(char *s) {
       int n = strlen(s);
       char *p = malloc(n + sizeof(int) + 1);
       if(p) {
          strcpy(p + sizeof(int), s);
          *(int*)p = n;
          p += sizeof(int);
       }
       return p;
    }

    void lenstrfree(char *s) {
        free(s-sizeof(int));
    }

Re: Some C habits I employ for the modern day

#82

> I’ve long been employing the length+data string struct. If there was one thing I could go back and time to change about the C language, it would be removal of the null-terminated string. It's not necessary to go back in time. I proposed a way to do it in modern C - no existing code would break: https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple, and easy to implement.

> the fatal error was not combining the array dimension with the array pointer; all it needs is a little new syntax a[...]; this won’t fix any existing code. Over time, the syntax a[] can be deprecated by convention and by compilers. You're thinking in decades. C standard committee is slower than that. This could have worked in practice, but probably never will happen in practice. Maybe people should start considerin…

As I see it, the problem with languages trying to replace C is that they not only try to fix fundamental flaws, but feel compelled to add unneeded features and break C's simplicity.

Re: Some C habits I employ for the modern day

#83
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…

I've been looking into Ada recently and it has cool safety mechanisms to encourage this same kind of thing. It even allows you to dynamically allocate on the stack for many cases.

You can allocate dynamically on the stack in C as well. Every compiler will give you some form of alloca().

Re: Some C habits I employ for the modern day

#84
post #65

Earlier quoted context omitted.

Where do you think the first generations from C++ programmers come from? There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual. Mostly learnt K&R C, assume the world is simple, until the code gets ported into another platform or compiler. Yet in such a simple language, I keep waiting to meet the magical d…

> There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual. And yet you know from previous discussion with folks like Uecker and myself have done all those things, and still walked away from C++. In my case, I stepped back even after having a decade of work experience in it. Anything needing more abstraction…

People that contribute to WG14 are naturally biased against C++, especially with gimmicks like _Generic.

Internet is full of people asserting CVEs in C are only caused by not skilled enough devs.

Re: Some C habits I employ for the modern day

#85

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;

Everything except the import looks like standard c++ since at least 98.

Re: Some C habits I employ for the modern day

#86
post #46

Earlier quoted context omitted.

The C standard committee even refused Dennis Ritchie proposal for fat pointers. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > The…

> Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > I doubt most C advocates ever reflect on this. What would be the conclusion of this reflection? Assuming you have reflected on this, what was you…

That the language authors concluded C was done, there was no point collaborating with WG14, and there were better tools to do their operating systems research on.

Re: Some C habits I employ for the modern day

#87
post #73

Earlier quoted context omitted.

Am I missing something here? UTF8 has multibyte characters, they're just spread across multiple bytes. When you strlen() a UTF8 string, you don't get the length of the string, but instead the size in bytes. Same with indices. If you Index at [1] in a string with a flag emoji, you don't get a valid UTF8 code point, but instead some part of the flag emoji. This applies with any UTF8 code points larger than 1 byte, whic…

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

Indeed. If you have output considerations then the number of Unicode codepoints isn't what you wanted anyway, you care about how many output glyphs there will be, that codepoint might result in zero glyphs, it might modify an adjacent glyph, or it might be best rendered as multiple glyphs.

If you're doing some sort of searching you want a normalization and probably pre-processing step, but again you won't care about trying to count Unicode code points.

Re: Some C habits I employ for the modern day

#88
post #73

Earlier quoted context omitted.

Am I missing something here? UTF8 has multibyte characters, they're just spread across multiple bytes. When you strlen() a UTF8 string, you don't get the length of the string, but instead the size in bytes. Same with indices. If you Index at [1] in a string with a flag emoji, you don't get a valid UTF8 code point, but instead some part of the flag emoji. This applies with any UTF8 code points larger than 1 byte, whic…

> 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

Re: Some C habits I employ for the modern day

#89
post #67

I'm a huge fan of the 'parse, don't validate' idiom, but it feels like a bit of a hurdle to use it in C - in order to really encapsulate and avoid errors, you'd need to use opaque pointers to hidden types, which requires the use of malloc (or an object pool per-type or some other scaffolding, that would get quite repetitive after a while, but I digress). You basically have to trade performance for correctness, wherea…

> But then anyone could just instantiate an invalid Name without calling the parse_name function and pass it around wherever This is nothing new in C. This problem has always existed by virtue of all struct members being public. Generally, programmers know to search the header file / documentation for constructor functions, instead of doing raw struct instantiation. Don‘t underestimate how good documentation can driv…

In C++ you can do: struct Foo { private: int val = 0; Foo(int newVal) : val(newVal) {} public: static optional CreateFoo(int newVal) { if (newVal != SENTINEL_VALUE) { return Foo(newVal); } return {}; } };

    int main(int argc, char* argv[]) {
      if (auto f = CreateFoo(argc)) {
        cout 

Re: Some C habits I employ for the modern day

#90
post #84

Earlier quoted context omitted.

> There is this urban myth C is simple, from folks that never read either ISO C manual, can't read legalese, never spent much time browsing the compiler reference manual. And yet you know from previous discussion with folks like Uecker and myself have done all those things, and still walked away from C++. In my case, I stepped back even after having a decade of work experience in it. Anything needing more abstraction…

People that contribute to WG14 are naturally biased against C++, especially with gimmicks like _Generic. Internet is full of people asserting CVEs in C are only caused by not skilled enough devs.

> Internet is full of people asserting CVEs in C are only caused by not skilled enough devs.

Sure, but those people are not here, and usually aren't on HN anyway.

The internet is also full of people asserting that CVEs in C++ are only caused by not skilled enough devs, but I consider those people irrelevant too.

The reasons for rejecting C++ in this forum have been repeated often enough that you should have seen them by now: C++ has major systemic problems that don't exist in many other languages, including C.

It should be no surprise to you, at this point, that people choose almost anything over C++. The fact that "anything" also includes "C" is mostly incidental.

No one is asserting that they reject C++ because C is better, they typically reject it for concrete reasons, like the ones I pointed out upthread.

Post reply on HN