Live data from Hacker News

GNU Coding Standards: Writing Robust Programs

gnu.org

61–70 of 111 posts

Re: GNU Coding Standards: Writing Robust Programs

#61
post #55
post #45

Earlier quoted context omitted.

ok then, nobody was using auto_ptr in the 90s.

Oh boy, OWL, MFC and VCL were used in the 90s, with their ComPtr smart pointer for COM/ActiveX/OLE 2.0.

I worked with C++ & MFC in mid-late 1990s, smart pointers weren't an option. Maybe if you do something against MS oddball APIs, but not in general programming, not even for mainstream MFC uses. And what was there was entirely non-idiosyncartic, it's like claiming C++ had garbage collection in 1990s because you could bolt on Boehm's.

Re: GNU Coding Standards: Writing Robust Programs

#62
post #25
post #3

> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. C++ is ok too, but please don’t make heavy use of templates. So is Java, if you compile it. Back in the early days, this sentence was more like "When you want to use a language that gets compiled and runs at high speed, the best language to use is C." . So we switched from a path where all major desktop environ…

I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway. If it's too slow, then you probably have an issue with which algorithm/data structure you chose and would have had the same issue in another language. The biggest issue I have with C today is that you…

> I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway.

Are there good examples of what you mean by this? From my own C++ experience, when dealing with c libraries and std::string types, I'll sometimes use the copying api's[0] when passing around std::string::c_str() because I find it easier than worrying about invalidating the returned reference if the string is destructed or modified.

[0]: e.g. https://curl.se/libcurl/c/CURLOPT_COPYPOSTFIELDS.html

Re: GNU Coding Standards: Writing Robust Programs

#63
post #21

Earlier quoted context omitted.

None of that was a thing in 90s and early 00s.

The average C++ codebase isn't from the 90s. On all the recent c++ polls the average language revision used is between c++14 and 17. Besides I'm pretty confident that there are more new c++ projects created daily in 2021 than monthly at the peak of the 90s c++ craze - just on GitHub, 6/7% of C++ repos means a few million recent C++ repos.

What does it have to do with what we are discussing?

Re: GNU Coding Standards: Writing Robust Programs

#64
post #25
post #3

> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. C++ is ok too, but please don’t make heavy use of templates. So is Java, if you compile it. Back in the early days, this sentence was more like "When you want to use a language that gets compiled and runs at high speed, the best language to use is C." . So we switched from a path where all major desktop environ…

I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway. If it's too slow, then you probably have an issue with which algorithm/data structure you chose and would have had the same issue in another language. The biggest issue I have with C today is that you…

If there were no problem writing secure code in C and C++ we would have a lot fewer vulnerabilities based on some form of memory corruption.

Re: GNU Coding Standards: Writing Robust Programs

#65
post #54
post #27

I hate that formatting style personally.

Me too. I've never understood it. I just went back through the clang-format documentation and looked at some of the examples for the GNU style and was reminded at how utterly unreadable the resulting code is.

The rationale for this style seems to be to make it appealing to Lisp programmers, which will find it familiar.

I also dislike it for C (as much as I appreciate GNU's contribution). As we all know, K&R is the one true style.

Re: GNU Coding Standards: Writing Robust Programs

#66
post #59

Earlier quoted context omitted.

auto_ptr (precursor to unique_ptr) was first proposed for standardisation in 1994 [0], and there was probably non standard versions of it before 94. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N055...

You ever used auto_ptr? In 1992, I was working on the Taligent project, probably the first major C++ operating system. (It failed.) I remember when the ARM came out---none of the compilers we had available could really do templates. Or namespaces.

A part of Taligent lives on with ROOT, which was very annoying.

Re: GNU Coding Standards: Writing Robust Programs

#67
post #12

Earlier quoted context omitted.

> So we switched from a path where all major desktop environments ... were adopting C++ to a surge in C programming, as FOSS adoption started to gain steam. So you say FLOSS is responsible that the late 90s/early 2000s C++ hype slowly died off? > trying to fix the security inconveniences caused by this manifesto. And you believe those projects chose C, solely because some random GNU document suggested they do? If tha…

In part yes. Had GNU/Linux not taken off, in the alternative universe from Windows, BeOS, Mac OS, OS/2, commercial UNIX (remember Motif++ and CORBA?) would kept writing the software in C++, instead of caring about creating FOSS stuff in C. GNOME vs KDE is a good example of that schism and language wars.

Good news! GNOME and KDE both have efforts to add more Rust: https://wiki.gnome.org/Projects/Rust https://community.kde.org/Rust

Re: GNU Coding Standards: Writing Robust Programs

#68
post #63

Earlier quoted context omitted.

The average C++ codebase isn't from the 90s. On all the recent c++ polls the average language revision used is between c++14 and 17. Besides I'm pretty confident that there are more new c++ projects created daily in 2021 than monthly at the peak of the 90s c++ craze - just on GitHub, 6/7% of C++ repos means a few million recent C++ repos.

What does it have to do with what we are discussing?

we are discussing the sentence "The average C++ code base has as many segfaults than the average C code base."

__s and you said "You were using C++ >= 11 in 90s/00s?" to which I answered that this was not the point, because the average C++ code base isn't from the 90s/00s.

Re: GNU Coding Standards: Writing Robust Programs

#69
post #21

Earlier quoted context omitted.

None of that was a thing in 90s and early 00s.

The average C++ codebase isn't from the 90s. On all the recent c++ polls the average language revision used is between c++14 and 17. Besides I'm pretty confident that there are more new c++ projects created daily in 2021 than monthly at the peak of the 90s c++ craze - just on GitHub, 6/7% of C++ repos means a few million recent C++ repos.

> On all the recent c++ polls the average language revision used is between c++14 and 17.

Polls of hobbyist coders, or software houses? I would be surprised if most software houses migrated to C++17 yet. Tensorflow is stuck on C++03 I think.

Re: GNU Coding Standards: Writing Robust Programs

#70
post #56

Earlier quoted context omitted.

All of which were heavy enough at the time to slow programs down enough that people chose to not use them in favor of faster, more portable C.

That is why Turbo Vision was written in C++ for MS-DOS, Mac OS transitioned from Object Pascal into C++ and Quake made use of Watcom C++.

id's engine was famously C, not C++, all the way through Quake 3.
Post reply on HN