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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

291–300 of 396 posts

Re: Modern C [pdf]

#291

Post by uabstraction »

FrancoDiaz wrote: post #208
chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

I don't hate C. I'd rather program in C than C++. There's a "uniformity" and simplicity about C that makes it beautiful. You've got structs, functions, and pointers...that's it. I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on. With C++ and other OO languages, it's much harder. Don't get me wrong, I'm not going to write my next web app in C, and there's some…

I think this says more about John Carmack's devine software engineering talent than it does about C++. I've seen some slick looking C++, and I've seen some flat out atrocious C (and vice-versa). Even Carmack decided to switch to C++ for iD Tech 5.

Re: Modern C [pdf]

#292

Post by jstimpfle »

baka wrote: post #286
FrancoDiaz wrote: post #208

Earlier quoted context omitted.

I don't hate C. I'd rather program in C than C++. There's a "uniformity" and simplicity about C that makes it beautiful. You've got structs, functions, and pointers...that's it. I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on. With C++ and other OO languages, it's much harder. Don't get me wrong, I'm not going to write my next web app in C, and there's some…

"I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on." Npte though that id hasn't really created an influential game in 15 years and arguably the game of the century (Minecraft) was programmed, badly from what I hear, in Java. People often say that "you can write good C code" without considering what you're giving up in terms of architecture and creativity.

Writing good C code also means knowing when to use another language on top. Scripting languages such as Lua are commonly used in the games industry.

Re: Modern C [pdf]

#293

Post by clarkcox3 »

renlo wrote: post #283
imron wrote: post #185

Earlier quoted context omitted.

> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)

Your for loop works, whereas the one in the parent comment would run forever, correct? Is there something I'm missing here? edit: Ok, looking at it again the parent example is probably going to overflow or something right?

The example with ">= 0" is an infinite loop, a size_t will always be greater than or equal to zero; it's unsigned.

Re: Modern C [pdf]

#294

Post by pjmlp »

clarry wrote: post #265
paulmd wrote: post #237

Earlier quoted context omitted.

It's not just that HN does a lot of webdev. It's that even in its element as a "systems language" it's virtually impossible to write 100% safe C/C++ code and guarantee that it will remain safe into the future, even for experts who are making every effort to do it right. There are just too many gotchas with "undefined behavior" and too many clever compilers out there waiting for you to make a mistake. One only needs t…

I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. Sure, you can always find people who don't know how to write a proper safety check. That doesn't mean nobody knows. You can always find people who ignore or don't know about best practices, but that doesn't mean everyone's like them. And you can find people who write goto fail; and ignore the warnings about unreachable cod…

Well, I guess you missed the Linux Security Summit:

http://arstechnica.com/security/2016/09/linux-kernel-securit...

Re: Modern C [pdf]

#295

Post by pjmlp »

clarry wrote: post #271
sqeaky wrote: post #270

Earlier quoted context omitted.

I think that you have the formulation backwards. You claim that people can just write better, and should attain perfection. > I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. I think most people come at the other way. Most people are aware that they are fallible and wants tools to help with that. Most people strive for perfection and none will ever actually attain it. >…

> which then results in every caller ignoring the return value And a whole load of compiler warnings. Worse yet, people who ignore warnings might ignore them. > Now imagine the advances in error detection moving to languages that catch additional classes of errors. Languages don't catch errors, tools do. The C tooling has been and still is constantly improving.

Lint was created for C in 1979 as the language authors saw how easy it was to make errors, static analysis is still largely ignored by the majority of C developers nowadays.

https://www.bell-labs.com/usr/dmr/www/chist.html

I am yet to see it being use in enterprise C code.

Re: Modern C [pdf]

#296

Post by int_19h »

ape4 wrote: post #238
72deluxe wrote: post #226

Earlier quoted context omitted.

Are you looking for "return"? With C++ you can ensure that you have your destructors do the tidy up, e.g. a messy example struct cleaner { cleaner(string *toCleanup) : m_x(toCleanup) { } ~cleaner() { delete m_x; m_x = nullptr; } };

Yup, C++ has autocleanup. Of course if you are using fopen() instead something more modern you'll need to fclose(). Adding a new keywords to C is a long shot. Perhaps compilers could detect non-cleanup use of goto and give it a warning.

A typical C++ codebase I'm working on these days would have scope guards implemented via macros, such that you can do e.g.:

    FILE* f = fopen(...);
    SCOPE_GUARD({ fclose(f); });
This is mainly used for one-off calls to some native API, where writing a proper RAII wrapper for the managed resource is not worth it.

Re: Modern C [pdf]

#297

Post by ____nope »

ticviking wrote: post #279
Longhanks wrote: post #262

Earlier quoted context omitted.

Then why start teaching programming with Java in the first place when understanding those concepts involves an at least mediocre understanding of object orientation? There are many more languages that implement a "Hello, world!" with one line of code. If explaining "public static void main" is too hard, maybe one is using the wrong tool.

This is an idea that many people resist. I think they mistakenly believe that programming languages are genuinely difficult to learn, and students must start on one that is marketable.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

Re: Modern C [pdf]

#298

Post by int_19h »

nurettin wrote: post #160
ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

The main argument against goto comes from standard C++ side because there are so many edge cases where goto and longjmp will cause your exceptions and end-of-life semantics to go awry.

If I remember correctly, C++ flat out bans all uses of goto that could affect constructors and destructors. For example, something like this won't compile:

    int main() {
        goto g;
        std::string s;
        g: return 0;
    }
while this will compile, but destructor is guaranteed to be called:

    int main() {
        {
            std::string s;
            goto g;
            return 1;
        }
        g: return 0;
    }
Now, longjmp is another matter. That thing is basically verboten in any sane C++ environment (and consequently, C libraries that use it across API boundary are very painful to use from C++; R hosting API is a great example of that).

Re: Modern C [pdf]

#299

Post by btilly »

sqeaky wrote: post #278
FrancoDiaz wrote: post #208

Earlier quoted context omitted.

I don't hate C. I'd rather program in C than C++. There's a "uniformity" and simplicity about C that makes it beautiful. You've got structs, functions, and pointers...that's it. I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on. With C++ and other OO languages, it's much harder. Don't get me wrong, I'm not going to write my next web app in C, and there's some…

Comments like this perplex me. I am a full time C++ dev and I could just rewrite your comment woving the "++" to the other "C". Really like that I can create a class that stores all the knowledge of one concept internally and if I wrote that correctly I never need to look inside it again. Even better, if I document the contracts of using a class I can carefully optimize it and have broad performance effects with smal…

C++ has the issue that there are a lot of ways to hide magic, and a lot of hidden magic can blow up in unexpected ways if it interacts badly with other parts of the language that you do not understand.

The result is that you really need to stick to a subset of the language that has been chosen to work well together. Safely adding to that chosen subset is challenging. And it just takes one developer to create a major headache.

See, for example, https://google.github.io/styleguide/cppguide.html#Exceptions documenting why Google is not willing to allow even something as basic as exceptions to be used in C++ code.

Re: Modern C [pdf]

#300

Post by bakadana »

____nope wrote: post #297
ticviking wrote: post #279

Earlier quoted context omitted.

This is an idea that many people resist. I think they mistakenly believe that programming languages are genuinely difficult to learn, and students must start on one that is marketable.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

I always assumed that's why Python was so popular in universities. It's OOP & it's low on syntax.
Post reply on HN