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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

151–160 of 470 posts

Re: In Defense of C++

#151

Post by AdieuToLogic »

ryao wrote: post #125
s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

GCC was originally written in GNU C. Around GCC 4.9, its developers decided to switch to a subset of C++ to use certain features, but if you look at the codebase, you will see that much of it is still GNU C, compiled as GNU C++. There is nothing you can do in C++ that you cannot do in C due to Turing Completeness. Many common things have ways of being done in C that work equally well or even better. For example, you…

Where C macros provide functionality C++ classes and/or templates cannot is stringification of their argument(s).

For example:

  #include 

  #define SQL(statement) #statement

  int main (int ac, const char *av[])
  {
   const char *select = SQL(select * from some_table);

   std::cout

Re: In Defense of C++

#152

Post by AdieuToLogic »

vlovich123 wrote: post #145
wojciii wrote: post #142

Earlier quoted context omitted.

How is that even possible? Wasn't CI invented to solve just this problem?

You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time. Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fi…

> You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system ...

The scenario you are describing does not make sense for the commonly accepted industry definition of "build system." It would make sense if, instead, the description was "application", "product", or "system."

Many software engineers use and interpret the phrase "build system" to be something akin to make[0] or similar solution used to produce executable artifacts from source code assets.

0 - https://man.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek...

Re: In Defense of C++

#153

Post by fluoridation »

zahlman wrote: post #82
Night_Thastus wrote: post #81

Earlier quoted context omitted.

>This is the problem. Also, a proper editor can "fold" blocks for you. I can't fix that. I just work here. I've got to deal with the code I've got to deal with. And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope. >Sure, but then you have to understand the assembly that you've stepped into. Assembly? I haven't touched raw assembly since college.

> And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope. How exactly are they more helpful than following the line of the indentation that you're supposed to have as a matter of good style anyway? Do you not have formatting tools? How do you not have a tool that can find the top of a level of indentation, but do have one that can find a paired brace? >Assembly? I haven't touch…

>How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source?

I don't know what IDE GP might be using, but mixed-language debuggers for native code are pretty simple as long as you just want to step over. Adding support for Fortran to, say, Visual Studio wouldn't be a huge undertaking. The mechanism to detect where to put the cursor when you step into a function is essentially the same as for C and C++. Look at the instruction pointer, search the known functions for an address that matches, and jump to the file and line.

Re: In Defense of C++

#154

Post by jjaksic »

fouronnes3 wrote: post #8

This is a good article but it only scratches the surface, as is always the case when it comes to C++. When I made a meme about C++ [1] I was purposeful in choosing the iceberg format. To me it's not quite satisfying to say that C++ is merely complex or vast. A more fitting word would be "arcane", "monumental" or "titanic" (get it?). There's a specific feeling you get when you're trying to understand what the hell is…

Wow, I don't understand what anything means in those memes. And I'm so glad I don't!

It seems to me that the people/committees who built C++ just spent decades inventing new and creative ways for developers to shoot themselves in the foot. Like, why does the language need to offer a hundred different ways to accomplish each trivial task (and 98 of them are bad)?

Re: In Defense of C++

#155

Post by mbac32768 »

StillBored wrote: post #63
sunshowers wrote: post #22

Earlier quoted context omitted.

Exactly! This is my problem with the C++ community's culture. At no point is safety put first.

Its worse. The day I discovered that std::array is explicitly not range/bounds checked by default I really wanted to write some angry letters to the committee members. Why go through all the trouble to make a better array, and require the user to call a special .at() function to get range checking rather than the other way around? I promptly went into my standard library and reversed that decision because if i'm goin…

Good news! Contracts were approved for c++26 so they should be in compilers by like 2031 and then you can configure arrays and vectors to abort on out-of-bounds errors instead of corrupting your program.

Let no one accuse the committee of being unresponsive.

Re: In Defense of C++

#157

Post by fluoridation »

StillBored wrote: post #63
sunshowers wrote: post #22

Earlier quoted context omitted.

Exactly! This is my problem with the C++ community's culture. At no point is safety put first.

Its worse. The day I discovered that std::array is explicitly not range/bounds checked by default I really wanted to write some angry letters to the committee members. Why go through all the trouble to make a better array, and require the user to call a special .at() function to get range checking rather than the other way around? I promptly went into my standard library and reversed that decision because if i'm goin…

>Why go through all the trouble to make a better array, and require the user to call a special .at() function to get range checking rather than the other way around?

Because the point was not to make an array type that's safe by default, but rather to make an array type that behaves like an object, and can be returned, copied, etc. I mean, I agree with you, I think operator[]() should range-check by default, but you're simply misunderstanding the rationale for the class.

Re: In Defense of C++

#158

Post by fluoridation »

sunshowers wrote: post #78
bluGill wrote: post #27

Earlier quoted context omitted.

They can, but I find in practice that I never do this so it doesn't matter.

I'm glad, but my problem is with the claim that modern C++ is safer. They added new features that are very easy to misuse. Meanwhile in Rust you can freely borrow from the stack in closures, and the borrow checker ensures that you'll not screw up. That's what (psychological) safety feels like.

Lambdas are syntactic sugar over functors, and it was possible all along to define a functor that stores a local address and then return it from the scope, thus leaving a dangling pointer. They don't introduce any new places for bugs to creep in, other than confusing programmers who are used to garbage-collected languages. That C++11 is safer than C++98 is still true, as this and other convenience features make it harder to introduce bugs from boilerplate code.

Re: In Defense of C++

#159

Post by fouronnes3 »

jjaksic wrote: post #154
fouronnes3 wrote: post #8

This is a good article but it only scratches the surface, as is always the case when it comes to C++. When I made a meme about C++ [1] I was purposeful in choosing the iceberg format. To me it's not quite satisfying to say that C++ is merely complex or vast. A more fitting word would be "arcane", "monumental" or "titanic" (get it?). There's a specific feeling you get when you're trying to understand what the hell is…

Wow, I don't understand what anything means in those memes. And I'm so glad I don't! It seems to me that the people/committees who built C++ just spent decades inventing new and creative ways for developers to shoot themselves in the foot. Like, why does the language need to offer a hundred different ways to accomplish each trivial task (and 98 of them are bad)?

The road to hell is paved with 40 years of backwards compatibility requirements.

Re: In Defense of C++

#160

Post by fluoridation »

AlotOfReading wrote: post #50
nzeid wrote: post #11

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. You know, not sure I even agree with the memory leaks part. If you define a memory leak very narrowly as forgetting to free a pointer, this is correct. But in my experience working with many languages including C/C++, forgotten pointers are almost never the problem. You're gonna be…

C++'s design encourages that kind of allocation "leak" though. The article suggests using smart pointers, so let's take an example from there and mix make_shared with weak_ptr. Congrats, you've now extended the lifetime of the allocation to whatever the lifetime of your weak pointer is. Rc::Weak does the same thing in Rust, but I rarely see anyone use it.

Huh? What do you mean? The point of std::weak_ptr is that it's non-owning, so it has no effect on the lifetime of the pointed object.
Post reply on HN