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

The C++ standard for the F-35 Fighter Jet [video]

youtube.com

Post reply on HN
Print view View original

431–440 of 451 posts

Re: The C++ standard for the F-35 Fighter Jet [video]

#431

Post by pjmlp »

nmz wrote: post #385
lallysingh wrote: post #304

Earlier quoted context omitted.

No they won't. DoD is small compared to the rest of the software market. You get better quality and lower cost with COTS than with custom solutions, unless you spend a crap ton . The labor market for software's no different. Everyone likes to crap on C++ because it's (a) popular and (b) tries to make everyone happy with a ton of different paradigms built-in. But you can program nearly any system with it more scalably…

Go was built because C++ does not scale. Anybody that's ever used a source based distro knows that if you're installing/building a large C++ codebase, better forget your PC for the day because you will not be using it. Rust also applies here, but at least multiplatform support is easier, so I don't fault it for slow build times

Go was created because Rob Pike hates C++, notice Plan 9 and Inferno don't have C++ compilers, even though C++ was born on UNIX at Bell Labs.

As for compilation times, yes that is an issue, they could have switched to Java as other Google departments were doing, with some JNI if needed.

As sidenote, Kubernetes was started in Java and only switching to Go after some Go folks joined the team and advocated for the rewrite, see related FOSDEM talk.

Re: The C++ standard for the F-35 Fighter Jet [video]

#432

Post by [deleted] »

IshKebab wrote: post #272
ecshafer wrote: post #231

Earlier quoted context omitted.

I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

I agree. First of all I don't think Ada is a difficult language to learn. Hire C++ programmers and let them learn Ada. Secondly, when companies say "we can't hire enough X" what they really mean is "X are too expensive". They probably have some strict salary bands and nobody had the power to change them. In other words there are plenty of expensive good Ada and C++ programmers, but there are only cheap crap C++ progr…

[deleted]

Re: The C++ standard for the F-35 Fighter Jet [video]

#433

Post by account42 »

amluto wrote: post #105
unwind wrote: post #56

Earlier quoted context omitted.

For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void: (void) a; I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

Not if you use GCC. https://godbolt.org/z/zYdc9ej88 clang gets this right.

a) __attribute__((warn_unused_result)) is non-standard in the first place, are you looking for [[nodiscard]] - GCC does not warn on cast to void with that?

b) A return value that is explicitly marked like this is very different from an unused variable that gp suggested the cast to void idiom for. GCC does not warn on variables that are unused except for a cast to void.

Re: The C++ standard for the F-35 Fighter Jet [video]

#434

Post by account42 »

FieryMechanic wrote: post #324
bluecalm wrote: post #125

Earlier quoted context omitted.

I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them. > Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 disci…

The trick is to have warnings fail CI but not local builds.

> I work with a colleague that doesn't compile/run the code before putting up a MR.

Then erroring on unused variables will not help you anyway.

Anyway, all your issues sound like management problems. Not all projects are run that badly.

Re: The C++ standard for the F-35 Fighter Jet [video]

#435

Post by account42 »

FieryMechanic wrote: post #325
treyd wrote: post #233

Earlier quoted context omitted.

You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.

Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.

> Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler).

Not my experience. Find better managers.

Re: The C++ standard for the F-35 Fighter Jet [video]

#436

Post by account42 »

pjmlp wrote: post #265
greenavocado wrote: post #180

Earlier quoted context omitted.

For situations where you do want to handle allocation failure, GLib provides g_try_malloc and related functions that can return NULL. The key insight is making the common case automatic and the exceptional case explicit. The g_new macro is particularly nice because it is type-aware. Instead of writing g_malloc of sizeof times count and then casting, you write g_new of type and count, and it handles the sizing and cas…

You missed the part that GNOME was started due to differences with KDE licensing, and original FSF was against C++ due to religious reasons, and even if KDE/QT license had been GPL compatible, they would not adopted it. If you look around outside Linux world, everyone was going into C++, PC world with OS/2, MS-DOS and Windows, Apple, Epoch (later Symbian), BeOS,.... UNIX was playing with CORBA, OpenInventor,.... Here…

> "Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."

Ironically GCC itself uses C++ these days.

Re: The C++ standard for the F-35 Fighter Jet [video]

#437

Post by FieryMechanic »

account42 wrote: post #434
FieryMechanic wrote: post #324

Earlier quoted context omitted.

> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them. > Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 disci…

The trick is to have warnings fail CI but not local builds. > I work with a colleague that doesn't compile/run the code before putting up a MR. Then erroring on unused variables will not help you anyway. Anyway, all your issues sound like management problems. Not all projects are run that badly.

> The trick is to have warnings fail CI but not local builds

Which is annoying because the CI pipeline can take like 10 minutes to do the build and then you need to re-commit after turning the warnings on locally.

There are other issue like your code compiles differently in CI vs on your machine, which brings it own issues. Ignored warnings can cause other pieces to fail compilation or execution in other project/libraries. I had this happen in C# and VB.NET.

It is best just to turn on all warnings and errors and be done with it.

I've never heard particularly good reasons for not having it turned on all the time and that includes those mentioned in this thread.

> Then erroring on unused variables will not help you anyway.

The point I am trying to convey, which was a direct response to something the parent said:

"barbarians who commit code that complies with warnings"

IME it is very common for people to just straight up ignore warnings, and issues and sometimes they won't even check the thing compiles. I've worked as a contractor at a number of companies both large and small and this has been a constant.

> Anyway, all your issues sound like management problems. Not all projects are run that badly.

Again the point I was trying to convey is the expectations people have on here are far higher than what some of us have to deal with on a daily basis. So you have to put in loads of automated checks that I don't have to bother with when working with competent people.

Re: The C++ standard for the F-35 Fighter Jet [video]

#438

Post by account42 »

elteto wrote: post #181
alchemio wrote: post #91

Earlier quoted context omitted.

You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.

So you can’t use them then.

Of course you can, you just need to check your preconditions and limit sizes ahead of time - but you need to do that with exceptions too because modern operating systems overcommit instead of failing allocations and the OOM killer is not going to give you an exception to handle.

Re: The C++ standard for the F-35 Fighter Jet [video]

#439

Post by FieryMechanic »

account42 wrote: post #435
FieryMechanic wrote: post #325

Earlier quoted context omitted.

Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.

> Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). Not my experience. Find better managers.

>Not my experience

The point being conveyed is your experience is not representative of what commonly occurs. I have worked as a contractor in a number of different orgs both small, large, private and public and more often than not unless you force people to fix these things, they won't.

> Find better managers.

How about you and others with similar attitudes realise that the world isn't perfect and sometimes you have to work with what you got.

Do you think I haven't been looking for a new position? Most of the jobs in my area are going to be more of the same.

Re: The C++ standard for the F-35 Fighter Jet [video]

#440

Post by bluGill »

jandrewrogers wrote: post #390
bluGill wrote: post #303

Earlier quoted context omitted.

What you wrote is historically correct, but new analisys shows exceptions are faster that error codes if you actually check the error codes. Of course checking error codes is tedious and so often you don't. Also is micro benchmarks error codes are faster and only when you do more complex benchmarks do exceptions show up as faster.

The performance benefits of exceptions are not borne out in practice in my experience relative to other error handling mechanisms. It doesn't replicate. But that is not the main reason to avoid them. Exceptions have very brittle interaction with some types of low-level systems code because unwinding the stack can't be guaranteed to be safe. Trying to make this code robustly exception-safe requires a lot of extra code…

The cost depends greatly on details. If you are returning an error and handling it in the next function down, then error codes are better. However if you have to unwind several levels of stack then exceptions are faster (assuming a modern optimized implementation - in many cases the compiler is locked into an ABI that cannot be optimized...)

> unwinding the stack can't be guaranteed to be safe.

While this is true, it is a bad argument. If unwinding the stack isn't safe then you likely have lots of issues because you forgot about some code real code path that can also have the effect of skipping the area where you do the needed cleanup. In effect cleaning up to make unwinding safe will also have the effect of making your code better in the other cases too.

This argument also fails in a different way: if your stack is safe to unwind that means it is easy to test all the code paths that unwind. Testing error paths is often hard and so skipped - which means exception safe code is more likely to be correct because the code paths are run all the time.

Post reply on HN